Tag Archives: ROS

First experiences with the ROS Unified Robot Description Format

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:

ScreenshotAmosero_1 ScreenshotAmosero

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

urdf_to_graphiz path/to/file.urdf

after that open it e.g. by

evince file.urdf

looks like that:ScreenshotAmosero_2

Arduino Micro /Leonardo and rosserial Hello World possible link problem?

Yesterday I’ve had to learn something the hard way. Please have a look at the following code of the rosserial “hello world” arduino example:

/*
 * rosserial Publisher Example
 * Prints "hello world!"
 */

#include <ros.h>
#include <std_msgs/String.h>

ros::NodeHandle  nh;

std_msgs::String str_msg;
ros::Publisher chatter("chatter", &str_msg);

char hello[13] = "hello world!";

void setup()
{
  nh.initNode();
  nh.advertise(chatter);
}

void loop()
{
  str_msg.data = hello;
  chatter.publish( &str_msg );
  nh.spinOnce();
  delay(1000);
}

Nothing special, right? So compiling it – uploading everything on the arduino works like a charm.

But starting it  rosrun rosserial_python serial_node.py /dev/ttyACM0 crashes with:

rosrun rosserial_python serial_node.py /dev/ttyACM0
[INFO] [WallTime: 1400737593.278250] ROS Serial Python Node
[INFO] [WallTime: 1400737595.610358] Connecting to /dev/ttyACM0 at 57600 baud
/home/yourUser/catkin_ws/src/rosserial/rosserial_python/src/rosserial_python/SerialClient.py:317: SyntaxWarning: The publisher should be created with an explicit keyword argument 'queue_size'. Please see http://wiki.ros.org/rospy/Overview/Publishers%20and%20Subscribers for more information.
  self.pub_diagnostics = rospy.Publisher('/diagnostics', diagnostic_msgs.msg.DiagnosticArray)
[ERROR] [WallTime: 1400737595.826375] Error opening serial: could not open port /dev/ttyACM0: [Errno 13] Permission denied: '/dev/ttyACM0'

which can be easily explained by normal users missing permission to access the /dev/ttyACM0. So I advice running it as root, which leads you to customize roots .bashrc including the source /home/yourUser/yourWorkspacePath/devel/setup.bash and the environment variables like ROS_HOSTNAME and ROS_MASTER.

So after that, running it again with root permissions, you’ll get another error message:

[INFO] [WallTime: 1400737809.741920] ROS Serial Python Node
[INFO] [WallTime: 1400737810.415142] Connecting to /dev/ttyACM0 at 57600 baud
/home/yourUser/catkin_ws/src/rosserial/rosserial_python/src/rosserial_python/SerialClient.py:317: SyntaxWarning: The publisher should be created with an explicit keyword argument 'queue_size'. Please see http://wiki.ros.org/rospy/Overview/Publishers%20and%20Subscribers for more information.
  self.pub_diagnostics = rospy.Publisher('/diagnostics', diagnostic_msgs.msg.DiagnosticArray)
[ERROR] [WallTime: 1400737827.716961] Unable to sync with device; possible link problem or link software version mismatch such as hydro rosserial_python with groovy Arduino

So – rosserial tries to connect to your /dev/ttyACM0 using 57600 baud and fails. The error message is kind of misleading – of course there is some syncing issue, and it has nothing to do with your ROS version… …but with your arduino!

Since the arduino micro / leonardo uses USB for and its build in serial-controller both for programming and communicating, rosserial needs the information to access the device not in the for arduino usual serial way but with USB. So simply adding

#define USE_USBCON

before the rest of the code, will tell ROS to do so.

 

 

Ultrasonic Sensor HC-SR04 as a ROS Range publisher

I’ve taken a HC-SR04 like shown below and connected it to the CubieTruck as a rosserial publisher.

IMG_20140512_114741

 

Instead a of a simple std_msgs::String str_msg;  I’ve implemented a sensor_msgs::Range range_msg; which after starting the arduino in ros with rosrun rosserial_python serial_node.py /dev/ttyACM0  shows up in rostopic echo /ultrasound like this:

---
header: 
  seq: 136
  stamp: 
    secs: 1400706588
    nsecs: 709593997
  frame_id: ultrasound
radiation_type: 0
field_of_view: 0.10000000149
min_range: 0.0
max_range: 4.0
range: 1.18762886524
---

So with that, its possible to visualize everything using rqt_plot:

ScreenshotROSUltraSound

which is pretty nice for my first arduino micro ros project and less than an two hours of work 🙂

For further information see here

 

Rasberry Pi Robot with ROS, Xtion and working base_controller teleop

Before I dismantle my little [amazon &title=Raspberry Pi&text=Raspberry Pi] Robot #1 , I wanted to have a little video of its base_controller working together with the turtlebot teleop. It uses the geometry/Twist messages to transmit moving information like a lot of ROS Robots do.

Youtube Video

As you see there is a little acceleration control implemented which makes the robot start smoothly and stop after gently after no key is pressed anymore. In case of emergency its possible to hit e.g. the space bar for a instant full stop.

This robot isn’t very fast – but the next one will be. So this was a successful ROS-learning robot which I can recommend to everyone who wants to know how ROS Robots work.
Its a bit hard to get all of the source compiled on the small arm cpu, and there are nearly no precompiled packages – but it takes away all the fear from compiling errors in the future 🙂

 

Raspberry Pi Robot with ROS, Xtion, OpenNi2 and rviz providing 3d point cloud data

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

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:

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].

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

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.

So todays lesson learned is:

Robots are distributed systems – by every measure.

So I’ll need more power.. again…

Raspberry Pi Robot #1

I’ve completed a new version today. It is a bit smaller and heavier, but already running ros hydro (I will write a small tutorial soon how to achieve that) with OpenNI2 and the ros-package openni2-camera. With that its possible to stream data to another computer visualizing the depth image of the [amazon &title=Asus Xtion&text=Asus Xtion] in rviz. I had some trouble solving and compiling all drivers, dependencies like ros-packages and libs like openCV (see Howto).

When the camera node is running the Raspberry is faced at with a processing load of 100%. The used network bandwidth is about 200-300 kb/s.

I suppose the raspberry Pi needs to be replaced by something stronger soon.

But for my first week in robotics, it’s something 🙂