cornell-cup / c1c0-movement Goto Github PK

We've had a pretty consistent problem over the past year or so where C1C0 doesn't really drive straight, and I think I've diagnosed the problem - to summarize, despite the two motors having closed-loop feedback controllers built in to their drivers, they currently are treated as the only system in the universe and have no information about the other motor. What's necessary is to provide feedback from each motor to the microcontroller sending PWM signals to each driver, and adjust the signals using some robust controller design. There are many ways to approach this, and it could be quite the undertaking.

Currently, locomotion.py sends messages to the locomotion Arduino but lacks any code for receiving messages from the Arduino. Using pySerial and R2Protocol, add functionality for receiving messages. Messages are sent from the Arduino using R2Protocol, and the Python-side R2Protocol can decode such messages - all that's needed is code for reading the correct amount of bytes from a serial line.

In HeadLocomotion.ino, messages are never actually sent to the Jetson despite the functionality existing - we need to add code for sending messages as part of the same response for actuating motors to keep the Jetson updated on the microcontroller's status.

A program for the Jetson to send commands to the arms is necessary. This will be extremely similar to locomotion.py (or whatever the final version of that program is). The program should act as a server to accept input from other processes through sockets, and handle xbox controller input (this is a pretty aggressive project on its own, really). It will send commands based on that input to the arms microcontroller using R2Protocol-encoded messages, just as locomotion.py does currently. It should also be able to receive R2Protocol-encoded messages from the microcontroller.

Just as the locomotion microcontroller accepts input and actuates the motors in HeadLocomotion.ino, we need a similar program to run on the arms Arduino. The program will be very similar to the final version of HeadLocomotion.ino - it should accept R2Protocol-encoded messages from the Jetson (probably consisting of an angular amount to move), actuate motors to the correct place using rotary encoder feedback, and be able to send update messages (again, with R2Protocol) to the Jetson.

locomotion.py will need to accept input from other processes using sockets, as described in the new scheduler plan. This functionality may be added to locomotion.py, or, given how messy locomotion.py currently is, consider writing a fresh program based on locomotion.py which manages xbox and socket input.