Open joncamp opened 1 year ago
Currently the robotic version consists of three main components:
The Xavier serves as the computational core. It runs a version of Ubuntu provided by Nvidia. This version of Ubuntu may or may not be compatible with the desired version of ROS2 (currently Foxy), so we utilize a docker container to host the requisite versions of components to satisfy the ROS2 requirements. This abstraction prevents version conflicts at the base hardware level.
The Xavier is connected to the Auto pHAT via the 40-pin Raspberry Pi style connector. The Auto pHAT has many functions, but at this time the only function being used is the servo controller. The servo for steering is connected to channel 0, while the breaking servos are connected to channels 1 and 2. The code uses the ROS2 Qwiic Servo library for connecting to the servos and cmdvel_to_servo to translate _cmdvel messages into servo movements. Note: On the Xavier the I2C bus which is used for the 40-pin connector is connected to I2C bus 8, whereas on the Nano it is I2C bus 1. Code may have to be updated to handle connecting to the different bus.
The Teensy is connected via USB to the Xavier and runs micro-ROS. The xavier runs an agent which listens over serial over USB, and the Teensy is running microros.ino to connect to the various downstream components. The micro-ROS code on the teensy listens for _cmdvel, /microROS/haptic, _/microROS/hapticamplitude and _/microROS/hapticduration messages. It publishes /microROS/heartbeat, /microROS/torque, _/microROS/odometryleft and _/microROS/odometryright messages.
The current robotic version does not have any of the RCVR. Thumbstick, or servo connections. All other connections are as shown.
The Wizard version of Glide features a Teensy as noted above running serial-test.ino. This version also utilizes a remote-control receiver and has the teensy controlling the servos.
As noted above - the tasks for aligning the two platforms are as follows on the robotic version:
Steps (1), (2) and (3) are just wiring adjustments.
Step (4) will involve updating the code which listens to _cmdvel to control the servos based on the signals received. Since we only receive linear values in the x dimension those get mapped to the breaking servos, and we only receive steering values in the z dimension. The steering and breaking may need to be tuned to get the expected behavior.
It is also important to ensure that, depending on how we implement step (6), the system should be able to function regardless of whether a computational device is connected via USB and communicating as a micro-ROS agent.
Step (5) is partially complete in the dev2_1 branch. A basic follow-up to ensure there are no errant unused nodes is necessary.
Step (6) will require a basic design discussion. One approach is to have a hard switch to allow the teensy to switch from robotic control to pure wizard control. Another option is to have it as an override (ie: if button on controller is pressed then it will override whatever the navigation system is doing. The downside with both of these options is that the ROS2 stack doesn't know what is going on with the remote control. Another alternative is to use a _cmdvel mux setup such that the remote control will publish through the ros2 system (perhaps as a teleop_twist_joy) and then get multiplexed together with the motion requests from NAV2. The benefit is that the remote control information gets propagated through the ROS2 stack, which is more consistent with how other robotic systems operate.
Step (7) again is a simple wiring step. It allows a single USB cable to provide connectivity from the computational device to all of the devices on the Glide.
Once steps 1-7 are complete we should be able to use either the on-board Xavier or another computing device (perhaps a laptop). The same firmware can also be used on both the robotic and wizard versions of the Glide (since they are now effectively the same).