Recovery Behavior + ROS 1 vs 2 Meeting 6/16

[rbridges12]

• We're gonna stick with ROS 1 for reasons mentioned in the ROS 1 vs ROS 2 discussion thread
• easiest Mac dev environment for ROS 1 will probably be a UTM virtual machine, this can work on both M1 and intel macs and still be quite fast because we won't have to do any emulation
• for recovery watchdogs, we could either use machine learning or data science to detect when we are stuck, or we could manually write checks for specific stuck conditions
• for CIRC at least, we are doing the manual route because it will be much easier to develop, test, and debug, as well as being more reliable without having much data from situations where we’re actually stuck
• getting stuck generally means that what we're telling the rover to do isn't actually happening, this can be detected with our velocity commands, encoders, and localization
• since getting stuck often involves our wheels slipping, we can't really trust encoders to detect stuck state
• we will take the average displacement vector of the GPS over 10-20 seconds and compare that to velocity commands during that time period, and if we detect a significant enough discrepancy then we will trigger a recovery action
• recovery action will involve backing up, similar to what was done at URC
• initial code will be written by Ankith and then tested on the rover by Riley
• will be tested by turning off some of the Odrives, causing velocity commands from nav to have no effect on moving the rover, possibly also could test in a sandy environment where we can't get any traction
• need to get a feature in the sim that allows us to do a very simple test of this, where it effectively doesn't move the rover in response to velocity commands from nav. this will be useful for writing the initial code and getting it ready to test IRL