Navigation stack test: GMapping vs Hector Slam

After first failed test of Geduino navigation stack using GMapping as SLAM algorithm I was curious to make tests with Hector Slam that, as shown by RoboPeak on its youtube video, works really well.

I registered real sensor data (using rosbag) from Geduino and play it running GMapping and Hector Slam in order to compare their behaviour on same data. Those are the results:

The map generated by GMapping

The map generated by Hector Slam

I was really surprised of this result: Hector Slam performs really better than GMapping!

Those two algorithms differ from the information sources used for localization and mapping: GMapping uses odometry and laser scan; Hector Slam, instead, uses the laser scan only. Theoretically GMapping should perform better then Hector Slam expecially on environments that cause laser scan estimated pose to be ambiguous (large space or long hallway without features): in those scenario GMapping can rely on odometry for robot localization. By other hand Hector Slam does not require odometry (so its a forced choice if robot does not provide it); another big advantage is that Hector Slam can work with laser mounted not planar to ground (as required by GMapping).

You can find more info on this benchmark of slam algorithm in ROS.

Since Hector Slam works fine we can assume laser scan data is ok, so I focused on odometry test: a good guide for this purpose can be found here.

This the result of this test:

The RViz output of odometry test

The robot starts from the position shown on the picture and travel to other side of the room and gone back. As shown on the picture laser scan impressions overlap quite well: this means that odometry data is consistent.

In conclusion theory is not according with real world: GMapping should perform better than Hector Slam but tests demonstrate the opposite. I will spend some time in order to study this case and found a solution since Geduino is designed to use GMapping.

First navigation stack test and improvements

After the Geduino navigation stack was ready I started tests on it. Generally speaking it is working but some problems occurs with GMapping (that provide SLAM algorithm) localisation (see this video). It seems to be related to odometer performance and GMapping settings.

To solve this problem I'm working on two tasks:

• improve Geduino odometry update frequency;
• improve Geduino odometry precision;
• use ROS bag simulation to test and find the best GMapping configuration.

On this post I want to show what I've done about first task and how I success to double it.

Geduino is able to move thanks to its two EMG30 motor powered by MD25 controller. This controller is connected to SAMx8 that set motor speeds (according to subscribed cmd_vel topic) and publish odometry transformation and topic (based on EMG30 encoders values).

Previously all calculation was done by SAMx8 and published on ROS. This was the node chart and frames tree:

The max update frequency of odometry was 10 Hz.

Since IMx6 has higher performance than SAMx8 the idea was to move all calculation to ROS node running on IMx6 and leave to SAMx8 only the hardware handling. After the modification the controller only publish raw encoders values and subscribe speeds command. All calculation in order to provide odometry and execute cmd_vel are done in odometry ROS node.

With this new design approach I was able to reach an update frequency of 20 Hz.

Furthermore other topics are published:

• motion9 (mpu9150_msgs/StampedMotion9): it contains raw motion 9 data from MPU9150. The goal is to integrate those informations (using Kalman Filter) in order to improve odometry precision;
• md25/status (md25_msgs/StampedStatus): it provide information about MD25 board status (voltage and current). The goal is to use it for diagnostic purpose;
• power (geduino_msgs/StampedPower): it provide information about Geduino power source (voltage and power source type). The goal is to use it for diagnostic purpose (especially when powered by Li-Po battery is important to monitor the voltage).

Next steps:

• testing odometry precision and apply corrections (UMBMark test);
• improve odometry precision by Motion9 data (Kalman Filter);
• test different GMapping configurations.

On Geduino Git repositories you can find all modified source code.

Geduino has now a logo!

After long time Geduino finally has a logo! Thanks to everyone who responded to the survey for their contribution.

The new blog look was an occasion to add new contents:

• on the right side of the page you find a link to GitHub repositories of Geduino code and other open source projects used developing Geduino. All source code are distributed under GPL V3 license;
• a new page contains a step by step guide to create Geduino SD card (from Kernel and modules to ROS packages).

Coming soon on the blog:

• I'm working on a ROS library for Java that is still an alfa version. I think it can be useful to other developer and I'll spend more posts about it:
• I'll add DWG file of the Geduino hardware, including Eagle project of the power board and the shield.

Testing MD25 and EMG30

On this post I want to publish result of some tests performed on MD25 board and EMG30 motors mounted on Geduino.

The first test's goal is to find relationship between motors speed input (a number between 0 and 255 where 128 is the center) and final angular speed at the end shaft.

In order to perform this test a simple program was uploaded on SAMx8. Exploring the speed range incrementing speed by 8 this program perform following steps:
- reset MD25 encoders value;
- set speed to given value;
- wait 10 seconds;
- measure the MD25 encoders;
- set speed to 0 (i.e. 128).

The same test was performed on both motor (1 and 2). The following chart show the results for motor 1 (green line) and motor 2 (blu line). On the x axis there are speed input to MD25, on the y axis the rotation speed at the end shaft.

The behavior is really good: excluding the extremes of the range the response is linear and there are not significant errors between two motors. This is a result of the motor feedback handled by MD25 board.

Using this result we can calculate relationship between MD25 input and final speed of the robot. Motors rotation speed can be related to robot speed and robot angular speed using following formulas:

1) v = (w1 + w2) * d / 4

2) w = (w2 - w1)  d / (2 *b)

where:

v - tangent speed

w - angular speed

w1, w2 - rotation speed of motor 1 and 2

d - the wheel diameter

b - the wheel base

Calculation are done using Geduino dimensions.

Applying linear regression to this data we can found a linear relationship between the tangent and angular speed we want to drive to the robot and the right speeds value to set on MD25 to reach those speeds.

Geduino is ready!

NOTE: this an old post and, due to latest improvement, Geduino is changed from this picture.

I'm proud to announce that Geduino is ready!

With the completation of the power board and the shield all subsystems are now connected. Also the Laser Range Fined mount is build and completed. On following picture you can see the fully assembled robot (ok, this is not true: the battery is still not there: until Geduino will work in a lab power it by external is cheapy!).

System architecture

NOTE: this post is a revision of an older one to reflect last changes on Geduino

On this post the general architecture of Geduino will be explosed in order to show how each component works and communicate with other ones.

Geduino is based on UDOO board, a mini PC with quad core processor (Freescale IMx6) and a micro controller (SAMx8). UDOO provide an Arduino compatible pinout (the same as Arduino Due) that can be connected to SAMx8 (in this case it will works exactly as an Arduino Due) or to IMx6 CPU. SAMx8 and IMx6 will communicate between them using UART.

Other hardware component:

- PING))) sensors from Parallax. Ping sensors will be connected and controlled by the SAMx8 micro controller and their goal is to provide a secure and fast obstacle avoidance system;

- the RPLidar from RoboPeak, connected using UART pins to the IMx6. The RPLidar will provide laser scan data and it is the  core information source for the SLAM algorithm;

- the MD25 and EMG30 motor, connected using UART to SAMx8 micro controller. The motor will move Geduino and provide odometry information to SLAM algorithm;

- the MPU9150 from Sparkfun, connected using I2C to SAMx8 micro controller. This is a complete IMU that provide orientation information to SLAM algorithm in order to increase its accuracy.

Furthermore two other hardware board are used:

- the power board: attached to power source (LiPo battery or AC adapter) it provide stable power (5V or 12V) to all other components. In order to preserve the LiPo battery life the power board send to SAMx8 the current voltage of the battery;

- the shield board: this is a shield which pinout is Arduino Due compatible. Almost all hardware components will be connected to this shield. It include all systems (voltage level converter, configuration jumpers...) needed for hardware communication.

Last, but not the least, the 7" LCD touch screen, a standard UDOO optional that will provide a GUI to interact with Geduino.

Construction: part two

NOTE: this is a quite old post and in latest revision some construction details maybe changed

To build up the upper plate of the robot I use the same technics used for lower plate. The upper plate must have the supporting mount for LCD panel. This mount was cut from an aluminum sheet and it is composed by the rear mount and the from mask.

For aesthetics reason the front mask was decorated with a black glue paper.

Finally the two plates mounted with the LCD and UDOO connected and powered.