Firmware Summary
Problems and Solutions
Hub Motor Interface
Since the current hub motor driver circuit is not implemented in the PCB, the CAN bus is easily affected by interference. As a result, it was not possible to transmit data at 1 MHz, so it was reduced to 500 kHz
The speed reading from the motor can be write and read with a resolution of only 0.36621 rpm/bit, resulting in the speed commanded to the motor and the obtained value to be within ±0.36621 rpm, which is a large value in the 0 - 15 rpm operating range
Reading position and speed values from a polling function has the chance to cause the MCU to get stuck in an infinite loop, so it has to write a timeout when the called value does not return
When the robot ramps up, it causes the driver to display a red fault indicator on the driver and causes all motor operations to be suspended
IMU Interface
When reading the value of the IMU for less than 1 minute, the IMU will not be able to send data back to the board, and the runtime will increase from 7 ms to 200 ms. This will cause the board to freeze and cause other processes to fail as well. Causing the need to replace the IMU
Wheel Velocity Estimation
Position were used to estimate the speed of each wheel since the resolution was 0.0878 degree/pulse. However, because the estimated speed was much less than the speed commanded to the motor, cutting position off temporary is needed
Microcontroller-ROS2 Interface
Since the standard ROS2 messages nav_msgs/Odometry, sensor_msgs/Imu, and geometry_msgs/Twist are very large messages, both in variable bit size and in the number of data in the array, result in the maximum transmission frequency of 10 Hz. Creating a custom message in xicro interfaces includes xicro_interfaces/Odometry, xicro_interfaces/Imu and xicro_interfaces/DiffDriveTwist To extract only the information necessary for the mobile robot and to remove the constant covariance matrix from all messages, it is possible to send information up to ROS2 at a frequency of 100 Hz
Gripper
A gripper has a problem in the mechanical part, the gripper goes to the wrong position according to the experiment ‘Testing an appropriate force with other object’. Therefore a present load from DYNAMIXEL may change after a mechanical part has been fixed
Suggestion for Future Development
Hub Motor Interface
If the runtime of reading from the motor is required to be less than before The hub motor driver circuit can be improved to withstand more noise by making a PCB and using a shield cable to support transmission with a frequency of 1 MHz instead of 500 kHz
Write a function for fault diagnosis when Overload, Under-voltage, Over-voltage, Encoder falling, Over-current, Overheat from Heart-beat message occur and handle appropriately
Maybe change motor driver
Wheel Odometry
For a more accurate estimation of the robot’s position, the Wheel velocity estimation can be improved by changing the Q, R matrices to achieve a more actual velocity. Or may consider returning to use the position value together as well
Wheel odometry equation may be improved.
Conduct an experiment to find a pose covariance matrix
Gripper
After fixing in the mechanical part, all of the experiments will have to be retaken for checking a change of present load