baalexander / rosnodejs Goto Github PK

Using a message wich contains an uncaspulated standard message, the message is searced only in the packages directory and not in the standard one.

For example sensor_msgs/Image conains a field Header.
We look for the field Header in the sensor_msgs packages, but not also in the std_msgs.

ros@ros:~/Desktop/igvc_viz$ nodejs app.js

events.js:72
throw er; // Unhandled 'error' event
^
Error: ENOENT, lstat '/opt/ros/jade/stacks'

when running the package in nodejs.

Hi,
i was wondering why this repository was deprecated.
Is this mostly an issue about time or change of responsibilities or is there something fundamentally 'wrong' about this implementation?
I am aware of the other work being done like the rosbridge etc, but i am also very interested in running a real JS based implementation on the robot target itself, and i think especially in combination with something like the Tessel 2 this can be really powerful.

I'm not entirely happy with the relation between Publisher/Subscriber and the TCPROS client/server. For starters, it needs to be confirmed there's no cyclical references.

This issue is part of a more meta issue of a TCPROS.js refactoring.

To make testing easier, a Makefile should be added to perform make test.

However, there's two sets of tests: the tests in test/ and the How To examples in `example/'. Should these both be included in the testing?

Two things to think about:

1. The How To tests depend on ROS being installed. The tests/ may not (should not?) depend on a ROS installation and can therefore be run on continuous integration environments like Travis CI.
2. The How To examples will likely need an alternative reporter to generate HTML documentation. This could be a different target for the Makefile.

ROS Fuerte was released. Need to confirm compatibility with XML-RPC, TCPROS, package finding, and more.

I keep going back and forth on this one. Right now, there's four separate groups of functionality in this one repository: web, node, web server, and message generator. These could be split up into four NPM modules with separate repositories for each.

Proposed modules:

• roswebjs - Contains the JavaScript used on the browser and is extended by the Node.js implementation. This module would contain no other ROS dependencies.
• rosnodejs - The ROS JavaScript Client Library. Allows using JavaScript directly on the robot. This extends the roswebjs models (currently from ros.js.
• rosserverjs - This is a small web server that would act as the intermediary between roswebjs and rosnodejs.
• rosmsgjs (or rosmsgsjs) - Generates JavaScript implementations for a package's message definitions. Like std_msgs.js or geometry_msgs.js.

The pros of leaving everything in one package is it's easier to make changes across the different areas (like ros.js in roswebjs and rosnodejs) and it's easier to manage one repository (watching, forking, keeping track of issues).

The pros of splitting up into separate packages are a more modular design, smaller modules, and easier to only include the functionality needed. For example, a web server can simply require('rosserverjs').

(If this is open sourced before I make a decision, I'd love to hear some feedback).

Node name remapping is a basic feature Nodes (and the client library the Node is written in) should provide.

JavaScript does not support 64-bit signed and unsigned integers natively. There's two options to support them:

1. Use a datastore for precision storing of the 64-bit integers. This could be the default array returned by ctype's r/wsint64 and r/wuint64 functions or something like node-int64.
2. Coerce the value into the JavaScript number (a double precision float).

This will be used in messages and reading/writing to buffers.

After listening to a few persons feedback, seeing how people are using it, and dealing with a few of the bugs that have risen, I think there's some architectural shifts that will make rosnodejs more useful and stable going forward.

1. Do not share code between the browser and rosnodejs. I think Backbone still makes sense for the browser, but in practice, a competing event system like Backbone's in rosnodejs just makes things worse. The may end up with ros.js and others being forked into a roswebjs package. I still plan for the APIs to be very similar.

2. Make publisher and subscriber more event based. Think HTTP.server or net.Socket. On the browser, this would mean Backbone models wrapped around socket.io events. Not sure for the server yet.

3. Decouple TCPROS. While the current implementation of TCPROS work, I would like to see improvements all around. I think modeling it after net.Socket could be a good start. More event based should help with the decoupling from publisher and subscriber.

4. No more message pre-generation. As mentioned in https://github.com/baalexander/rosmsgjs/issues/6, the generation of message files may not be needed. The server could generate the models on load time and the browser could populate a generic Ros.Message with JSON.

I'm aiming for most of the ideas and any others to be included in the first release meant for wider consumption: v0.1.0. Please let me know if any ideas. The work is being done on the public branch 0.1.0-wip.

Array field types need to be supported for subscribing and publishing. Not just primitive arrays like unint32[], but also message type arrays, like std_msgs/String[].

Right now, a node can only be shutdown using rosnodejs by killing the process. There should probably be a clean way to shutdown a node as well as query the state of being shutdown (see rospy's is_shutdown()) and handling a shutdown (handling a 'shutdown' event?).

The roslaunch tool should be able to run one or more rosnodejs' nodes.

Currently, the web app needs to assign ros.io to the io library provided by socket.io, like so:

<script src="/socket.io/socket.io.js"></script>
<script src="ros.js"></script>
<script>
ros.io = io;
// robot logic...
</script>

It would be great if the ros.js file assigned ros.io to the io library automatically.

This is related to the rosserverjs project.

See Issue #9 for implementing start and stop functions.

After multiple discussions (#37 and RethinkRobotics-opensource/rosnodejs#7), I will be transferring the rosnodejs NPM package to the RethinkRobotics-opensource/rosjs project.

@chris-smith or @IanTheEngineer can you let me know when you're ready for me to transfer and to whom?

Currently, Node names are simply resolved to root if they are not currently namespaced. More intelligent namespace resolving must be added based on the Node's address.

A general Namespace module is probably a good idea as namespace resolving happens across the project.

The original code is in #20

var ros = require('rosnodejs'),
    Velocity = ros.message('turtlesim/Velocity');  // if no callback is passed as a second argument, then run it in synchronous mode

// first argument can be an object like current api, but if a string, it will just be the name
ros.createNode('turtlenode' , function(err) {
  //'this' is a reference to the created node
  if(err)
    return console.error(err);

  //Velocity is still an object which is able to auto-instantiate if not an instance of the Velocity object yet.
  // we may want to add an optional callback below as a third argument, to know when it has been sent, but generally we just won't care at all, we could even listen for the event we just created instead

  this.emit('turtle1/command_velocity',  Velocity({ linear: 1.0, angular: 1.0 }));
})
.on('error', console.error)

// not in the code above, but would be powerful too
//creates the topic /turtlenode/hello and registers a callback for it
.on('turtlenode/hello', function(name) {console.log('hello, ', name)})

It would be nice to start and stop roscore, even if only for testing. Something like ros.start() or ros.startCore(). These would be optional as rosnodejs should continue to run with ros already running.

Should match the python's TF library, including TransformBroadcaster and others. Should work in the browser and the robot. This may be worth putting in a new project rostfjs.

Need to investigate if a publisher can publish to more than one subscriber.

A subscriber sends a requestTopic call to the publisher, which it does handle correctly for one subscriber. But if multiple subscribers call, does it keep track of each? Topic may need to have an array of protocols instead of a single protocol.

See rospy's interface for an example.

This could go under the root ros namespace in ros.js. Something like:

ros.ParameterServer = Backbone.Model.extend({ })

ParameterServer could override the default set and get implementations. It may make sense for ParameterServer to used statically, but the advantage of extending Model is others could bind to param changes (the ParameterServer would act like a cache for the ROS parameter server).

The MD5 sum calculated in messages.js returns incorrect values. For example, std_msgs/String returns 5b89344b4d080ca499c0648063c40738 instead of 992ce8a1687cec8c8bd883ec73ca41d1.

md5 sum test cases should also be added to messages_test.js.

Since integrating with Bootstrap, it would be nice to use the Bootstrap variables when customizing the CSS. Using less wil also enable customizing row spans in CSS without marking up the HTML.

This is a big issue and will likely require smaller, more specific issues going forward.

There's two ways to communicate between nodes in ROS: The publisher/subscriber way passing messages for topics and the RPC way, using service request and service responses. Currently, there is no support for services.

The implementation from a request/response perspective should resemble other RCP implementations, something along the lines of service.request('add_two_numbers', [array, of, parameters], callback) where the callback returns the service response.

tcpros.js will need to be updated and refactored for service supports. But tcpros.js really needs to be refactored anyways. Core service related models should be added to ros.js as well. Most documentation only references publishers and subscribers, so service copy will need to be added too.

Hi,

using the thc ros stacks, I've been faced to a problem.
Being a subscriber , once a conneciton with another node is establised, the first message contains the connection header. Others packets does'nt contains this header.

In the implementation, we check for the header for every packet.
This sometimes lead to serious problems.

(In our implementation, i'm not sur if we are realy using the header, because we got all the needed information before).

I guess it's not a bug and I simply need some help.

I've created a project "turtlenode" using rosnodejs, which aims at moving the turtle_sim turtle.

I've generated the turtlesim messages, and I'm trying to use "/turtle1/command_velocity " to send a new speed.

here's the code :

var ros = require('rosnodejs'),
    Velocity = require('./turtlesim').Velocity;

ros.createNode({ name: 'turtlenode' }, function(err, node) {

  if(err)
    return console.error(err);

  node.createPublisher({topic: 'turtle1/command_velocity', Message: Velocity}, function(err, topic) {

    if(err)
      return console.error(err);

    topic.publish( new Velocity({ linear: 1.0, angular: 1.0 }), function(err){

      if(err)
        return console.error(err);

      console.log('sent');
    } )
  })
})

'sent' is logged, no error is returned, but the process is stuck, and when I look at my graph with 'rxgraph', turtlenode seems registered to the topic (albeit I have to check "all topics" to see it) , but it is double circled in red, and clicking on it in rxgraph indicates that rxgraph could not connect to it using "localhost:9000".
I do not know what it means yet, but it seems not good.

rxconsole doesn't log any message while running turtlenode either.

Hi @baalexander ,

Currently with 0.1.1, and using the code from the example, I can run a publisher, a subscriber and send a message from the subscriber to the publisher.

I didn't success (and I didn't see anything in the code but I could have missed it) to have a publisher with several subscribers, or lauching a subscriber then stop it, then relaunched it...

Do you have any plan in this way and more globally to make rosnodejs more flexible.
Would you accept pull request going in in that direction ?

Otherwhise,

What is your next developpement step if you have one ?

Using TCPROS, a Connection Header can be sent as part of the message buffer or, when using repeat messages, as its own buffer.

To check if the buffer is a connection header or message, the getMessageFromBuffer in tcpros.js converts the buffer to a String and checks for required properties sent by the publisher, like type. This is inefficient and needs a better way to detect if a connection header buffer. This could happen in subscriber.js as state isn't really assumed in tcpros.js.

Being a subscriber receiving a big mesage, ie a sensor_msgs/image with a big image, receiving the message failed.

The fact is that we try to parse the message but we have only a part of the message.
We got only part of the message because du to the TCP behavior, the ros message is splitted in different tcp packets.

We need to bufferized the packet until the size of the received data is equal to the length of the message.

Right now, scans for available ports start at 9000. There may be a need for this to be configurable. The configuration option could be a global thing in environment.js or maybe a configuration option on Node and TCPROS.