adasta's profile - activity

Can packages and stacks share the same name? Will having a stack called foo and a package called foo cause problems?

My use case is that I have a stack called foo which contains package foo and package bar.

The local ROS tools are behaving, but I am not sure if this subtly breaks something.

How do you pass arguments to a rosjava node?

In the examples, org.ros.RosRun is used to instantiate the node. Only a NodeConfiguration is passed to this new node and the NodeConfiguration does not contain the command line arguments.

It sounds like you are exceeding the bandwidth and the packets are getting jumbled.

As a quick sanity check, figure out how much data you are actually sending per second.

The odometry message has a geometry_msg/PoseWithCovariance and a geometry_msg/TwistWithCovarience field. The covariance is a float64[36]. This means to send just the covariances you 2* 836=576 bytes. It is another 268=208 bytes to send the Twist and Pose. Total= 784 per message. Multiply that by the rate to get the bandwidth used.

TFs are also another source of huge data transfer.

You cant send that much data back and forth between the computer and the arduino. You need to throttle it.

Cheers, Adam

Hi Dan,

spinOnce should never block. It just checks to see if new serial data has come in and fires callback messages if it has received a full message. It is supposed to work just like spinOnce in roscpp. All it handles is com and callbacks.

Under what situations are you seeing it block?

It can do ROS_INFO, but not with the same kind of syntax.

See http://www.ros.org/wiki/rosserial/Overview/Logging

You also need to be using rosserial from source in order to use this.

Hi Peter,

I think that the problem is that the electric release is actually an older version of rosserial. We broke that API a little while ago and updated the documentation on the website to reflect newest code. Could you try pulling rosserial from the repo and using it?

Just do :

hg clone https://kforge.ros.org/rosserial/hg rosserial

Hi Brice,

You found a pretty tricky bug! I guess we had never tried to run rosserial_python from within the package of a custom message. Python automatically adds the working directory of a python executable to the python sys.path. As a result, when rosserial_python went to check if it had the package in its sys.path, it found the current working directory. I just updated the code to check for the src directory of the package instead of just the package name. It should work now.

Just pull the latest repo.

In that same program, could you add a hello world publisher just to make sure that everything else is working correctly?

You could be saturating the serial communication.

rosserial runs at 57600 baud. If it is a larger message, like geometry_msg/Twist for example, you would need a minimum of 67840 baud to send messages that fast. ( (8 x 3 x 2 bytes per message + 5 bytes message overhead ) x 160 x 8 bits per byte)

You have two options if this is the case. Limit the messages like you are doing. The only reason the joy stick is sending that many messages is because it sends a message everytime the joystick angle changes. It is very sensitive.

The other option is to increase the Arduino's baud rate.To modify what baud rate your rosserial uses, you need to update both the Arduino and the python serial_node. In the Arduino program, this means that you must set rate before you initialize the node. You set the baud rate by accessing the hardware object and setting its internal baud rate.

nh.getHardware()->setBaud(115200); //or what ever baud you want

Next, when you launch the serial node, you must set a private baud param to the specified baud rate.

<node name="rosserial_node" type="serial_node.py" pkg="rosserial_python">
    <param name="baud" value="115200"/>
</node>

Another possible problem could be that you are not calling nh.spin() enough. The Arduino's Serial circular buffer is only 80 bytes. If you happen to be sending data very fast and calling nh.spin() very slowly, then it will cause these kinds of problems.

Hi Patrick.

I am unfamiliar with ardupilot, however it shouldnt give you errors like that. If you provide a self contained example of where you are getting the error, I can help.

Collada files have color built in to the mesh definition while STL files do not. I think the default for RVIZ is to simply use what is specified in the file.

Collada is a pretty reasonable XML format. Since you probably one have one color, there will probably just be one tag to change in order to set the color.

This is not a recommended practice. You can have a unary stack where a package is also a stack. Most of the tools are robust to it, however there are several edge cases which this will break. Most obvious is roscd, as well as indexing and documentation will be broken as packages and stacks share a namespace. Getting REP 109 to work was hard. The package and stack are obviously at different scopes, they should be able to be named differently.

In general, you cannot do that.

Rviz is not set up to do that. Part of the reason is that RVIZ is written in C++ and cannot do that kind of runtime introspection. It needs to have the full message class compiled into its binary in order to be able to receive, deserialize, and manipulate the object.