It’s still not easy finding the right combination and arrangement of all robot parts. Like mentioned in the previous post, SketchUp is a nice tool for easy 3D visualization using real physical dimensions. So I spend some time again:

virtual disassembling

NEMA17 probably getting replaced by RB-35s

concept phase II – ISO

concept phase II – ISO Xray

concept phase II – front

concept phase II – xray

concept phase II – top

concept phase II – top wireframe

concept phase II – back

concept phase II – back Xray

concept phase II – bottom Xray with dimensions

concept phase II – front wireframe with dimensions

So tomorrow I am trying to by the planned box and the new motors, hopefully posting real world photos soon.

The Unified Robot Description Format is a nice way to describe robots in ROS. It is a xml formatted file which contains robot related information like links – geometry figures such as boxes, cylinders or sketch-up models(!), Joints – the information how the links are connected to each other, e.g. if they are fixed or continuous and in which state they are (using tf, the ROS transformation package) – and a lot of more stuff I didn’t figure out after a day with .urdf.
There also is some macro language called xacro, which seams to be pretty amazing, reducing xml code length, enable the usage of variables in it (like for scaling a whole bot) and much more.

it may look simple, but this little robot took a complete evening. He has 2 movable wheels in the front, custom colors and hopefully will drive around in simulation soon:

It’s possible to generate a graphiz dot graph and a pdf from the urdf using following command:

Today I achieved the following setup by dividing my openni2_launch files into two separate launchers beeing executed on two different machines: one for processing (nodelet_managing) running at a powerful server and one for streaming the [amazon &title=Xtion&text=Asus Xtion]-Image data from the [amazon &title=CubieTruck&text=CubieTruck] to the /camera -topic namespace. After that I could visualize, what my laptop wasn’t able to do before: a 3D DepthCloud with RGB-Data coloring in rviz. It has a native resolution of 640*480 and looks like that:

I can’t say how efficient the load is balanced right now – because I am currently still optimizing.

That’s one small step for a man, one giant leap for a small raspberry powered ROS robot.

Okay – maybe thats a bit too big – but I am in a good mood. I compiled the latest openni2_camera ros driver on the little arm cpu of the [amazon asin=B00LPESRUK&text=[amazon &title=Raspberry Pi&text=Raspberry Pi]]. Before that, I used the driver provided by kalectro (see source), which is an older fork but prepared for raspberry.

As a result of that, I’ve got some new features like the IR-Image stream I visualized with rviz :

Raspberry Pi Robot with ROS

or the handy little parameter with which it is possible to skip some frames which reduces the load a bit:

1

2

set param name="camera/driver/data_skip"value="300"

rosrun openni2_camera openni2_camera_node

Now, running roscore on my laptop – I had some sensor_msg/Images I needed to convert into 3d depth data. After some little issues with faulty XML-launch files, I finally got openni2_launch up and running, which is a handy little launchfile using rgb_launch providing every data format you’ll can get out of the [amazon &title=Xtion&text=Asus Xtion].

Shell

1

roslaunch openni2_camera openni2.launch

Now I’ve had a /camera/depth/points topic, with a pointcloud2 datatype. Which is really nice because rviz can visualize it:

Raspberry Pi Robot with ROS – Xtion

Houston, we’ve had a problem.

Yes, there were times when it was possible to land on the moon by the power of a daily life calculator – but todays robots need more than that 🙂 So my aged Intel Centrino Core 2 Duo ASUS-F3J with 1,7Ghz each core isn’t able to do more than I reached today. It pops to 100% processing and after some time it collapses totally.