Cannot move my turtle :'(

[temsa]

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.

[baalexander]

I have done all of my robot testing using a TurtleBot, but I haven't namespaced my topics yet (see Issue #5).

First, I have been using the cmd_vel topic and geometry_msgs/Twist for movement. The web app has the exact example I use to move the TurtleBot over the web. I believe turtlesim is just a reduced verions of this (or wrapper around this).

One of the ways I like to debug --- that may help here --- is to run rostopic echo [mytopic] and see if it prints out my published message.

A few possible issues:

1. The turtle1/ namespace isn't supported by rosnodejs. Proper namespace support is still on the todo list, right now it assumes most topics are in the root namespace.

2. roscore needs reset. Until Issue Support shutting down a node. #11 is resolved, I recommend always starting runs with a fresh ROS instance via a roscore call.

3. Topic name or message input is off. Ros.org is down for me right now, but there's a chance the expected topic is turtle1/cmd_vel if it's like other parts of ROS.

Please let me know if any luck. I will start including the turtle sims in the development testing for the v0.1.x branch.

[temsa]

Here is what outputs from rxgraph when selecting the turtlesim node :

Node [/turtlesim]
Publications: 
 * /turtle1/color_sensor [turtlesim/Color]
 * /rosout [rosgraph_msgs/Log]
 * /turtle1/pose [turtlesim/Pose]

Subscriptions: 
 * /turtle1/command_velocity [unknown type]

Services: 
 * /turtle1/teleport_absolute
 * /turtlesim/get_loggers
 * /turtlesim/set_logger_level
 * /reset
 * /spawn
 * /clear
 * /turtle1/set_pen
 * /turtle1/teleport_relative
 * /kill
Pid: 4718
Connections:
 * topic: /rosout
    * to: /rosout
    * direction: outbound
    * transport: TCPROS

If I understand well, I have to use the "turtle1/" namespace, and turtlesim does not listen for "cmd_vel" generic messages, so I just cannot talk to my turtle until "1)" is resolved ?

[baalexander]

I reproduced your issue locally tonight.

I ran rostopic echo /topic1/command_velocity and nothing printed out. I tried it with geometry_msgs and std_msgs and same issue.

Then I wrapped topic.publish in a setTimeout(..., 1000) call and rostopic was able to print out the message. You should be able to send messages okay with that timeout, but I still get a Connection to socket not established error when connecting to the simulator.

I plan to spend most of the weekend implementing the new API (minus message generation) in the v0.1.x branch. Some backend design changes that will go in with this is fixing a couple timing issues that have came up related to either TCP port availability or publishing a message before the socket has connected (the issue here).

Thanks for your patience.

[temsa]

I don't know if you are used to it, I don't don't get if it is necessary in your case or not, but complex timing issues are often easier to manage using promises IMHO.