scout controller design [updates]
The scout robotics controller is the central component of the scout robot system. It contains the central computer, the actuation controllers and control protocol, and the motor controllers themselves. This is controller hardware version 1.0.0, it is likely to change especially if we cannot get the ODrives working properly. If we can get the ODrives working properly. This may be the final version of the controller.
The basic idea is that our central controller needs to do a few things. First, take inputs from our sensors and process them. Second, take inputs from human control commands and human-machine interfaces and process them. Third, based on sensor inputs and HMI inputs determine how the robot must move to achieve the desired task. And finally, once it's determined how the robot needs to move to achieve the task, actually move the robot such that the task can be completed by sending actuation commands to the motor controllers, and therefore the motors.
We decided to go with a distributed computing system to achieve this. One of the systems would deal fully with inputs to the system (human commands, sensor inputs, etc). And another system would deal with actuation and outputs to the platform. Wether we chose Odrives or different motor controllers, either way the controller would deal with reading the encoder and determining the PID velocity control needed to ensure control of the motors. The computer controlling the actuation may also have access to encoder data to figure out the position of the encoders. All other environment-reading sensors would be connected to the first computer, the sensing and planning computer.
sensing and planning node
For the "Sensing and Planning Node" of the scout robot controller, we started with using a Nvidia Jetson TX1 we had lying around. We used the version with the carrier board. This computer was flashed with Nvidia's standard Jetson Jetpack software the latest version and ROS Melodic was installed on the system. Jetpack 4.3 also included things like Nvidia CUDA, however we did NOT install the CUDA package.
The Nvidia Jetson will be used to take sensor inputs from connected joysticks, LiDAR, and etc, and process them using ROS to determine the path and directions of robot travel. The end goal of the system is to take all the sensor inputs and desired actions, and output a robot desired forward and rotational velocity at every time-step. We have yet to figure out how it exactly will do this. But for now all sensors will be connected to the Jetson, likely via USB.
the control node
The "Controller Node" would take an input from the Jetson TX1 over USB Serial or some similar protocol and actually send actuation commands to the robot's individual motors. The Controller Node is also responsible for maintaining the stability of the system, for example if the robot is learning too far to one side then the Controller Node will correct for this. This means the Jetson may also need to publish IMU data depending on if the IMU or similar sensors are connected to the Control Node or the Sensing and Planning Node.
For the Control Node, we decided to simply go with an Arduino Mega over USB Serial. The reason for the Mega is the large number of ports and relatively-high amount of processing power. This will lead to quick calculations and control of the twelve motors needed for the scout system. The Mega will communicate with the Jetson over a custom ROS node we will write that uses Serial, Firmata, or similar. It has yet to be decided as the software hasn't been touched yet.
The preferred motor controller, the OODrive, for the scout system will connect to the Arduino Mega and communicate via Serial tx/rx custom Software Serial written by the ODrive team. The ODrive is a motor controller that converts any brushless motor into a robotic actuator where we can control its position and velocity. The ODrives are really good at controlling the motor, they don't need much signal smoothing, everything is in-built. This is why they're the preferred controller. We will start with the ODrives and see where we get. Worst case we will go back to the SparkMAX motor controllers built for the NEO Motor actuators we are using at least in this test platform.
More details for the controller we are calling the "Octopus" will be posted later. Including power diagrams and control schematics. More detailed explanations and documentation on what we are exactly doing will also be posted.