Mac's profile - activity

Hello answers,

Is anybody working on a general way of interfacing ROS with LCM or APRIL? There are some tools there I'd like to use. Doing it myself won't be too painful, but I figured I'd ask before I got too far in.

I'm writing a small caching node, that takes in messages (which include an index) and provides a service that (given the index) returns the appropriate message.

I'm caching because storing all of these messages in memory is too expensive; my cache keeps a recent subset in memory, and writes the rest out to disk (and then does on-demand loading, should that be necessary).

I was doing this with a datatype that's easily serialized by hand, and uniquely-named files. I'm now adding more data to my cache type, and this will no longer work.

So: is there a straightforward way to say "Here's a message and a filename, dump the binary blob to that file"? Or is the correct way to generate a new bagfile (again, uniquely named) for each message I want to cache?

(Storing every message in one bagfile won't work, unless bags provide constant-time indexing, which I don't believe they do).

I have a script that wraps rosbag play (because I need to set some rosparams first). However, if I run my script before my master finishes coming up, my calls to rosparam set fail, and my parameters don't get set (the call to play blocks until the master is up).

Is there a convenient way to block until a master comes up? I could write a miniature node that does it, but I thought I'd ask.

Another possibility: arguably, this is a bug in rosparam; it should either (a) block until it has a master or (b) at least provide a non-zero return code when it dies with "Unable to communicate with master", so I can spinblock it myself.

Thoughts?

Hello folks,

Background:

I'm playing around with openni_camera_unstable, hoping to get a two-pass pointcloud-generation system going (in the first pass, I record the image and depth data; in the second, I generate the registered pointclouds; limited hardware on my robot makes this handy).

Question:

If I fire up unstable's openni.launch, I get nice pointclouds exactly like I would expect. What I'd like to do is figure out what topics I need to bag in order to be able to run the point-cloud projection nodelet in a second pass. rosnode list shows /camera/points_xyzrgb_depth_rgb, which is the nodelet doing this work, but rosnode info on that node just lists a bunch of bond topics. The node actually publishing the point clouds is the manager (which I suppose makes sense, as I understand that to be the actual owning process of the various nodelets).

So: how do I figure out which topics my nodelet is subscribing to? (Alternatively, which topics do I need to accomplish what I'm after?)

Thanks!

Hello folks,

I have a Kinect mounted on a Create (not a turtlebot, but you get the idea), and I was hoping to build some 3D maps of my lab with that platform and the RGDB-6D-SLAM package. Sadly (even with the newly-released version) it doesn't work very well; even when driving (slowly!) a loop of only six or so meters, I get serious object doubling and (later) a catastrophic matching failure that throws one half of the map entirely out-of-plane; it's not even topologically correct.

My question is this: what's the correct next step? Fidgeting with RGBD-SLAM parameters? On a loop this tiny, I predict that gmapping + pointcloud_to_laserscan would have no trouble; it seems to me that graph techniques with full 3D and RGB should be able to do better.

I'm happy to provide the offending bagfile to anybody who would like to try this for themselves.

Thoughts?

[Edit]

I figured I'd put the bagfiles up:

1. First bag (435MB)
2. Second bag (1GB) (Higher frame rate)
3. Third bag (1GB) (Higher frame rate, different camera angle)

I'm curious to see what people think; it would be really handy to get this working. @felix, any thoughts?

Thanks!

I've been building (2D) maps using GMapping, and visualizing the results in rviz. So far, so good. However, the tf frames that are available (/odom -> /base_link, most importantly) represent the original, dead-reckoning, uncorrected odometry.

So far as I can tell, GMapping and Karto don't publish an extra, "corrected odometry" frame that I could use to visualize the current best hypothesis about the robot's pose.

Have I missed something, or do I need to put in a feature request?

We just used gimp. It's just a bitmap, so we drew some extra black on there with the paintbrush.

Short version:

Yes, you can pass that ConstPtr to a call to publish(), and it will work.

Long answer: Can you explain the problem you're trying to solve in a bit more detail? I'm envisioning a sort of round-robin message dispatch, and that seems painful.

I'm surprised to hear that the built-ins aren't good enough; I've had good luck with them (of course, I don't know the details of your problem). If they really are being quite bad, it might be worth trying a different Kinect; maybe it got stepped on. (Not that I've ever done that, ahem.)

Huh. If you haven't, it might be good to file a bug against cvblobslib, just to let them know that OpenCV changed out from under them.

If you turn on the built-in calibration (which, as I recall, is the default), you'll get pretty good registration performance. Do you have the built-in calibration turned on? (Or are you in a case where the built-in calibration isn't good enough?)