Drive Subsystem Module

[superdan-t]

Main Objective

Create the software module responsible for processing drive commands and writing motor speed to the ODrives. This task does not include interfacing with the ODrives (yet) since another member is currently developing our ODrive and CAN bus controller.

Design Info

• There are 6 wheels to set the speed for independently. There are 3 on each side of the rover
• Motors on the same side should have the same speed for now

Requirements

• Create a module for the drive operation. Put the code in an object like DriveController(). Place the hpp/cpp file for the module in src/subsystem_computer/. The new subsystems program has no main file yet, but you will likely need a temporary for testing.
• Calculate the output speed for the 6 motors from various inputs like forward speed and turning angle
  • Provide a function to set the forward velocity in meters per second. The speed output to the ODrives must be a float in revolutions per minute, so translate m/s to rpm using a hard-coded wheel size (radius, diameter, etc., whatever is most convenient). Use a constexpr member variable for wheel size so we can update as needed. (I'll get the actual size later, say r=15cm for now).
  • Provide a function to set the steering angle in degrees. The rover turns like a tank: reduce the speed on one side to turn that way while maintaining forward velocity on the other. Scale linearly between these values: -90° is sharp left, 0° is straight, 90° is sharp right, where 90° turns cause one side's speed to equal 0.
  • Provide a function to set the speed as a fraction of the maximum. Use whatever type is easiest for the input: it could be an int8_t where -128 is maximum in reverse and 127 is maximum forward. You can also use a float where 1.0 is the max forward and -1.0 is the max backward. The maximum velocity is something we'll have to determine by testing, so use anything for now.
• Provide getters for the design constants (max velocity, wheel size, etc.)
• Provide a halt function that sets all speeds to 0.
• Limit the maximum acceleration rate to prevent overcurrent errors from the ODrive. This will require testing to determine the actual max value. The actual motor speed should approach the target motor speed at the maximum acceleration rate. Create a function like DriveController::update_drive_subsystem() to be called every main loop that applies these changes. Use std::chrono for timing (you can save times using high_resolution_clock and then check how much has elapsed since the last call with chrono).
  • Make sure the behavior correctly handles an edge case where the function isn't called for a while. Hypothetical example: Max acceleration rate is 2 rpm/second, but the subsystem freezes elsewhere for 2 seconds (this shouldn't happen, but we must handle it). The rover could've accelerated 4 rpm in this time, but because update wasn't called, it didn't accelerate at all. Now, we can't add that 4 rpm immediately because it exceeds 2 rpm/second.
  • Note that there is no deceleration limit so the rover can stop as fast as possible
• In the update function, halt the rover if the inputs haven't been updated in the last second
• Timeline: Final pull request by November 30th (2.5 weeks). We should integrate this with CAN bus and the ODrives and test the full system before winter break. Try to get the function that calculates and sets actual motor speed done earlier so we can start interfacing with the ODrives concurrently.

  Design Suggestions

• Save the speed inputs (forward velocity, steering angle, nearest obstacle) as member variables. Create one function that updates the target motor speeds based on those variables. Whenever a function changes the inputs, call this function to recalculate the target speeds. In the update_drive_subsystem() function, continue accelerating the actual speed to the target speed.

Future Considerations

• Eventually we will figure out how to read actual speed, current, temperature, fault states, etc. from the ODrives. When this is figured out, we can improve the acceleration rate limiter.
• We want to support "in-place" turns where one side drives forward and the other in reverse. We have not worked out how this will actually work from a controller perspective. Suggestions are welcome

[Levi-Lesches]

• We want to support "in-place" turns where one side drives forward and the other in reverse. We have not worked out how this will actually work from a controller perspective. Suggestions are welcome

From what I know about controllers:

• diagonal stick => forward/backward + turn => one side goes half-speed, the other goes full-speed
• horizontal stick => turn in-place => one side doesn't move, the other goes full-speed
  • it could also be that one side goes backwards, the other side goes forwards. I think that's it

[superdan-t]

• We want to support "in-place" turns where one side drives forward and the other in reverse. We have not worked out how this will actually work from a controller perspective. Suggestions are welcome

From what I know about controllers:

• diagonal stick => forward/backward + turn => one side goes half-speed, the other goes full-speed

• horizontal stick => turn in-place => one side doesn't move, the other goes full-speed

  • it could also be that one side goes backwards, the other side goes forwards. I think that's it

Thinking about this makes me realize that in-place turn will probably require a separate interface in this drive module (where we can set the left and right target speeds separately).

We'll have to experiment with the controller to see what we like most. Ideally, we will be able to reconfigure the bindings at runtime using our GUI once the product is more advanced.

I was thinking the primary drive mode would use right trigger for throttle/forward speed, left trigger for reverse speed, and left joystick for steering. The drive team lead suggested the rover should do an in-place turn if we are turning the joystick but applying no throttle.

[superdan-t]

Just cleaning up the old issues. I should've closed this back with #15