Heron M300: Known Issues
In progress - Updating Summer 2022
Movement In general, the M300 Heron Surface Vehicles have an issue where driving them straight has a problem where the vehicle pulls to the left. Our current working theories are:
- Motor mismatch
- Motor controller settings
- Hull mis-alignment
As our tests continue we will attempt to identify what corrections should be made -- either in hardware or software or both.
IMU/Compass Issues
The MIT modified M300 Herons come with the um6 external IMU/compasses. There seems to be an issue with the IMUs and their correct transforms. We believe the issue is that the magnetometer reading is not transmitted from the chip in the correct coordinate frame, or there is some (assumed) transform that is not accounted for in the um6 driver - and/or the sensor documentation. We observed the coordinate frame for the mag does not match the axes for roll, pitch, and yaw from the same unit. This issue would explain why many people report such bad compass performance with the um6. Compass calibration is not repeatable and doesn't much improve performance, since the calibration optimization is attempting to fit a circle to the data on a plane that is mostly perpendicular to the plane that contains all the actual mag readings.
These issues were addressed in commits to the forked repositories:
- https://github.com/painetyler/heron_robot/commit/3a802504d52c193fe3feb1224dc9f46caab2a355
- https://github.com/painetyler/um6/commit/3d082e76c2b3b78c94b6508d91f6c98143fbf950
Another option is to use heading calculated by the GPS and transmitted via the GPRMC message. See the page about correctly configuring the GPS module.
USB Plug easily broken
The current USB connectors on the M300 Heron can easily have the plug put in upside down -- this leads to the USB to be broken. For the time being we are looking into painting the correct orientation to the plug...however this is not ideal.
CPNVG Messages not published or with missing heading
Our M300 Heron uses a front seat/back seat architecture. In order to achieve a layer of abstraction from the front seat hardware, the front seat publishes a set of NMEA sentences through a port. One of those messages is the CPNVG message which includes heading information. The CPNVG message is assembled on the front seat by a nav_publisher
ROS node by the name of nmea_nav
. The source code for this node is here:
https://github.com/heron/heron_robot/blob/kinetic-devel/heron_nmea/nodes/nav_publisher
We notice a few important details:
- At low speeds (<0.2 m/s) the heading information assembled into the CPNVG message is taken from imu/compass. At higher speeds, the heading information is taken from the estimate of the velocity in the x and y direction as estimated by the gps. We find this method of calculating heading at higher speeds to be so poor it is unusable. At higher speeds we switch to using the estimate of heading that is given by the GNRMC gps message.
- This node translates the rotation of the body frame, or
base_link
, is translated into roll, pitch, and yaw. If the imu is mounted on the top of the vehicle - as we have it - this calculation is not correct, and must be rotated about the y axis by pi. We will submit a merge request soon to fix this issue.
Also, it seems that the CPNVG message is inconsistently published by the front seat. The message will be either be sent with a static 90 deg for heading and NaN's for both pitch and roll, or the CPNVG message will not be sent at all.