Starting to work on a project I’ve dubbed Wayfarer. My community has a large spread of concrete hike and bike paths that wander through neighborhoods and forested areas. My goal is a robot that can autonomously navigate these pathways.
The chassis is a Wild Thumper, the same as I used in the NASA Sample Return Robot (SRR) challenge. The current plan is to use an Up Board (quad core 64 bit Intel® Atom™ x5-Z8350 Processor 1.92 GHz as the main brain. This came in a Intel RealSense Kit with an R200 RealSense. Originally was going to use multiple Raspberry Pi 3s but the Up is much nicer.
I offload motor control to a Pololu Simple Motor Controller (SMC) and a Pololu Maestro servo / analog in / digital out controller. I’ve completed porting the Windows code for them from the SRR to Linux. Switched to Linux so I can work with ROS. Also competed in the Space Robotics Challenge so have a fair amount of ROS experience at higher levels. As you can see I’m now looking at lower levels for controlling the base.
A long way to go on this but I’m retired so can spend a lot of time on it. The first task is to get base level ROS support for the Pololu controllers. My thought is to write a ‘driver’ for both controllers that accepts messages to control the motors / maestro outputs and publishes the state of the controlled devices.
The unknown is what messages to use for this.
Above the motor controller presumably a twist message will arrive at a higher controller that gets translated into a motor command message for each motor. My thought is that each motor is controlled by a separate node. Since there might be multiple motors the controller nodes could accept a trajectory_msgs/JointTrajectory Message with the name of each motor. The SMC can control velocity and acceleration so can use that from this message.
Similarly, the servos can be positioned with the same message using speed, acceleration, and position.
If the maestro is used for digital output a joint message is heavy. But it should still be a name and value array. Don’t see anything standard that works. Any thoughts? Same thing for reporting on digital inputs.
Also, the SMC has analog and RC inputs plus a lot of status information (voltage, temp, errors). Maybe the latter should be done through a service rather than published?
Okay, a lot of thinking on the fly here. Time to stop and think. Appreciate any comments or suggestions on how to proceed.