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