ipso's profile - activity

Have you tried Google? Something like "ros quaternion to euler"? We do expect a little effort of your own here ..

uint32_t ros::Publisher::getNumSubscribers() const

Returns the number of subscribers that are currently connected to this Publisher.

@daveayyyy: I haven't used this myself. @mstacho needed some options, so I listed some.

As per the title: how does the size of interactive markers get calculated in RViz? In particular the markers for revolute joints and the large interactive marker in the planning_components_visualiser or planning_scene_warehouse_viewer instances of RViz.

Some of my robots get large diameter markers (for their joints), while others seem to have significantly smaller markers. I haven't been able to find any real pattern to this, or relation to something like min/max joint angles or speeds, but my sampling space could just be too small.

Whenever I use roslaunch to launch a launchfile (ha :)), the output of top (or htop) shows three roslaunch processes. One that is the parent of all nodes, and two more that have no children.

I could probably try to read the source of roslaunch, but does anyone here have any idea what those extra two are doing there? I've never seen more than 2, so it does not seem related to the number of nodes in the graph.

Short version: how to keep one (cpu bound) node from starving all other nodes without explicit sleep()?

I have a system in which one node (in particular) is a cpu hog and also publishes a lot of messages. This node is a source node, with the rest of the nodes waiting and only acting on messages they receive (from the cpu hog, or other nodes).

What I'd like to do is give this source node a lower priority, so that it only gets the cpu if the other nodes are idle (or at least, not very busy). The idea is that the source will still publish ('as fast as possible'), but without getting in the way of the processing nodes.

AFAIK, nice should do this on Linux, and can be used as a launch-prefix to run a node at a specific nice level, but it "doesn't seem to work" in my case. I've verified the nice level with ps axl | grep -i nodename, and it is at 19 (with PRIO at 39), but the other nodes (at NI 0 and PRIO 20) are still starved of cpu and are loosing many messsages (note that higher PRIO values are less likely to be given cpu time).

I'm wondering if nice is the proper way to achieve the described behaviour, or should I use something else?

PS: there is no sleep(..) anywhere in the source node, it's essentially an infinite 'busy' while. Sleeping 'solves' the described issue, but there is no explicit need for periodicity and also seems to incur overhead (ie less messages published than possible). For obvious reasons a request-reply (even if a pub-sub acknowledge) system is undesirable.

Is it possible to integrate a while(true){ros::spinOnce(); ..} loop into a nodelet? I've based mine on the velodyne_driver nodelet, which runs a separate thread which polls the device object.

That while loop never sleeps though, and as the camera driver is a publisher, it doesn't have any callbacks to process, so there is no ros::spinOnce() either. I was wondering if that could be added there (to be able to handle callbacks) or if that would clash with the nodelet's manager?

EDIT: I know the manager handles the spin logic, it actually calls spinOnce() after a 1e6 us usleep (which is equal to what ros::spin() does). What I'm really after is a way to reduce that sleep time. I'm guessing that is not possible without changing and recompiling the nodelet manager, but hoping I'm wrong.

EDIT2: ^ all wrong. See @Lorenz's answer.

Not too much info on these (or any of the variants) on the wiki: what is the proper way to initialize these? I've tried:

const unsigned int data_sz = 10;
std_msgs::UInt8MultiArray m;

m.layout.dim.push_back(std_msgs::MultiArrayDimension());
m.layout.dim[0].size = data_sz;
m.layout.dim[0].stride = 1;
m.layout.dim[0].label = "bla";

// only needed if you don't want to use push_back
m.data.resize(data_sz);

for an array with 10, 1 byte elements, but I keep getting segfaults at the subscriber callback when accessing the data member (FIXED: see edit).

I couldn't find any examples anywhere, apart from http://alexsleat.co.uk/tag/multiarray/, but those snippets do not initialize any dimensions.

Is it programmers responsibility to keep the dimension objects in sync with the actual size of the data member, or is ROS doing some magic behind the scenes at serialization?

edit: as @Lorenz commented: reserve -> resize. I've left the bit about the segfaults in the question, even though that was fixed.

I'm trying to print / publish some statistics / diagnostic info at the time of nodelet unloading / exit. According to this answer on ros-users by Josh Faust the destructor of the nodelet should be used for this.

The problem I'm experiencing is that the text is sometimes printed, sometimes not at all and sometimes I get:

...
[my_nodelet_mgr-2] killing on exit
pure virtual method called
terminate called without an active exception
[rosout-1] killing on exit
[master] killing on exit
...

The nodelet class basically wraps another class with one publisher and one subscriber that does all the work, which is instantiated in MyNodelet::onInit(). Nothing sophisticated. ~MyNodelet() then prints the statistics using the NODELET_* / ROS_* macros after retrieving them from the worker class.

Is the nodelet destructor the proper place to be doing things like this (lacking a nodelet::onExit() or similar)? Any other ideas on how I could implement something like this?

how-to-catch-nodelet-shutdown-signal is related, but it explicitly deals with threading, which I'm not doing.

PS: Could it be that rosout doesn't get the chance to flush it buffers (or something similar)? Even a single NODELET_INFO(..) is printed only some of the time.

Are there best practices regarding debugging crashes of nodelets and / or the manager? I'm trying to load ~30 nodelets into one manager and experience seemingly random crashes. Is there a(n implicit) limit to the number of nodelets?

A sampling of output on the console:

...
[FATAL] [1338308399.389687172]: Service call failed!
[FATAL] [1338308399.389832093]: Service call failed!
[my_nodelet_mgr-2] process has died [pid 23322, exit code -11].
log files: /home/user/.ros/log/1ebdc96e-a9aa-11e1-abdc-d8d385994de6/my_nodelet_mgr-2*.log
[MyNode06-4] process has died [pid 23327, exit code 255].
log files: /home/user/.ros/log/1ebdc96e-a9aa-11e1-abdc-d8d385994de6/MyNode06-4*.log
[MyNode03-11] process has died [pid 23420, exit code 255].
log files: /home/user/.ros/log/1ebdc96e-a9aa-11e1-abdc-d8d385994de6/MyNode03-11*.log
...

Sometimes only ~4 service calls 'fail', sometimes they all seem to fail (always exit code 255, except the manager, which gets a -11).

The log mentioned for the nodelet manager does not exist, but master.log shows a lot of

[Errno 111] Connection refused

and

Fault: <Fault -1: 'publisherUpdate: unknown method name'>

lines.

I must admit I'm rather new to nodelets and their infrastructure, so any guidance would be appreciated.