Tag Archives: tf

aMoSeRo – first robot_pose_ekf and gmapping

This surely doesn’t look amazing from a external look – but this has been a day of hard work and was very important.

The robot_pose_ekf package is working! It is neither the setup I am going to use nor is it very stable – but it proves some points.

First I needed to write my own IMU driver for ros – 9 degrees of freedom (DOF) for 30€ and a bag of problems. This is a lot cheaper (around 100€) than the often used Razor IMU of sparkfun with existing ROS code, and exactly 3DOF better than the WiiMote (with Motion+ and also about 60-70€) I have been experimenting with. There is still a lot of work left for improving the stability, the calibration of the LSM9DS0 and there has been a lot more to find out about magnetic fields and strange units that needed to be converted in other ones than I would have ever expected – but so far the /imu_data topic serves some not totally wrong data – therefore normalisation minimizes  the issues with the 3-5 scales per axis I had to deal with.

Next I needed to increase my bad odometry sources – if not by quality at least with quantity – and added a GPS sensor as /vo topic.  The CubieTruck is a abstruse while handling some easy things like using one of the possible 8 UART connections…  for today I’ve not managed to get it running with UART but a external serial usb controller. Another area that needs heavy improvement…

Finally I had to deal with the REP105 issue that I have been describing in a previous post. The gmapping algorithm needed to get adjusted parameters, coming along with some serious confusion generated by inconsistent syncing over my 4 working devices (rosBrain with roscore and slamming, rosDev – my development machine, the aMoSeRo and the seafile backup server)…

…but after that all parts worked together for the first time, including a simulated aMoSeRo moving on screen while beeing hold in different angles in the real world.

Everything is still far from done – but right on the way – and we’ve already found out how wide the road is 🙂

ROS Transformation and Odometry based on URDF Convention REP103

In order to get ROS working correctly, you need a lot things to be set up according to ROS defined conventions: for instance the ‘Standard Units of Measure and Coordinate Conventions’ (REP103), which clearly explains which units geometry_msgs.Twist should have or in what movement direction your robot need to be inside its URDF file.

For me this meant to redo my xacro (URDF-Macro) defined robot driving direction and its according tf-links. Since I’ve already gained some experience in creating robot models I tried to improve it a bit too:

I will explain the robots hardware setup in another post as soon as its possible to run it by keyboard teleop while publishing its accurate odometry. Odometry Messages aren’t simply ROS transformations like moving parts of the robot. Because the robot belongs to the physical world where for example friction exists and further wheel jamming could happen, all the calculated position data need to by verified. Qualified for this task is sensor data like Ultrasonic Sensor Ranges, motor potentiometer or stepper motor positions or Openni2 data provided by the [amazon &title=Xtion&text=Asus Xtion]. After publishing this Odometry messages to the /odom topic, the ros navigation packages can generate geometry/Twist messages to correct the position to mach the simulation again in case there has been some deviation.

More on this topic soon.

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