Drivetrain.straight indefinitely

[milespearlman]

Noting that performing drivetrain.set_effort with the same effort in each wheel doesn't actually effectively go straight, it's more effective to use the drivetrain.straight function which isn't always ideal since it takes in a set distance. In the sample code below, replacing the set_effort function with the straight function would cause the robot to not drive smoothly because of the sleep function afterwards. If it's possible to implement the straight function with it going indefinitely rather than a set distance, it could be useful.

[camearle20]

I think based on what we are trying to do with the curriculum there are really 3 new methods of interest in drivetrain:

• drivetrain.set_speed(left: float, right: float): set the wheel speeds in cm/s using either the motor's PID controller or some built in one
• drivetrain.straight(speed: float): drive straight at a speed in cm/s. Can either just call set_speed internally or do something more fancy with a secondary controller. This would be non blocking and would run forever until told to stop
• The existing drivetrain.straight function which takes a distance. This could be renamed to something more intuitive like straight_for_distance or something, and the speed parameter on that currently should be an actual speed that is being controlled in cm/s, not just an effort cap

Do these changes make sense? Having these three available would make a lot of the lessons easier to write.

[camearle20]

It also may be worth having a default speed (maybe 50% of max speed) for all of these for true beginners to get started with. Doing that would really simplify the amount of code needed to just get the robot moving

[ksiegall]

I've just pushed a change related to this so i will note a few things here:

• i just renamed the "speed" parameter in straight and turn to max_effort for clarity.
• i've fixed all the weird behavior that we were seeing with the straight method (which were the result of encoder behavior being broken)
• I just added the set_speed method you are talking about, which just provides access to the speed control methods that were already in the encoded motor. Speed control needs to be tuned a little bit but other than that should be functional.
• The issue you are seeing where setting left and right efforts doesn't actually go straight is a consistent thing due to slight differences in the physical motors and voltages not necessarily correlating to exactly the same speed. The way we fix it in the straight() method rn is by either looking at the imu heading or the difference between the encoder counts for the left and right wheels and using that as the input to a second proportional loop to microadjust. This isn't necessary if you working off of a set_speed function instead of set_effort, since that already tries to keep the wheels in sync (if they are set to equal motor powers. Assuming this works as intended, having a drivetrain.set_speed(left_speed, right_speed) invalidates the need for a drivetrain.straight(speed: float). In this case, renaming drivetrain.straight would also be unnecessary
• The basic drive methods already have a default max_effort of 0.5, so they can already be called with drivetrain.straight(20) and drivetrain.turn(90), respectively

[camearle20]

I agree that the new functions would be functionally redundant if ‘set_speed’ exists, but I’m thinking of this more from an intuitive standpoint. In the curriculum we don’t introduce the concept of wheels going different speeds until over halfway through, so it would be nice from a beginners perspective to have a simpler method which just goes a speed.

[camearle20]

Also, is there a reason that the straight and turn functions can’t use the actual speed controllers in the EncodedMotor? Just curious here, I don’t think it matters either way if you nest those control loops or not.

[ksiegall]

For straight and turn, just setting a speed for a time isn't precise; You're much better off using a controller and P-controlling your way to the target.

To clarify your previous point, if we already have them doing drivetrain.set_effort(1,1) to try to go straight, how is drivetrain.set_speed(10,10) any different?

When making an older version of the DifferentialDrive class, we discussed the possibility of allowing you to pass in only 1 value into set_effort to set both motors, but we had eventually decided against it because it meant there would be a loss in clarity when explaining why it doesn't go perfectly straight. I think it is much more explicit to explain that you set the speeds for the left and right sides separately, but that's my personal bias

[camearle20]

Makes sense. I have no strong opinions either way, so I’ll just work this into the lessons. Thanks for adding set_speed though!