Stop.COAST_SMART

[FLL-Team-24277]

If I understand correctly, this would be a use case for COAST_SMART: Drive some distance, Stop with COAST_SMART, make a turn in place (say + 45), again using COAST_SMART and then driving some more to the final destination, and ending with COAST or BRAKE. The idea being that while I am driving the first leg, when I stop, I may not be pointed exactly on the heading that the robot was on at the start of that drive. Assuming that drive was the first thing the robot does, so the gyro would be reset to 0. Perhaps when I end, the actual heading of the robot was 2 degrees. Ideally it would be zero, but there are always inaccuracies. So when I go to do the next maneuver, turn +45, if everything was perfect, the robot would need to turn 45 degrees. But since the robot ended up at +2, and I used COAST_SMART, the robot will know that it only needs to turn 43 degrees. And since the turn in place also used COAST_SMART, if that turn overshoots by 3 degrees, the second drive command will know that it needs to correct by coming left 3 degrees and staying steady at +45.

Did I understand that correctly?

If so, what are the limitations of COAST_SMART? What happens if I drive using COAST_SMART, then instead of turning or doing something else with the drivebase, I do a wait()? Or something with the medium motors? Or set some variables and do some math? Does the next python command have to be another drivebase command for COAST_SMART to work? Or does that not matter? What about resetting the gyro heading in between movements? Or the motor encoders? Does it still know the accumulated error?

And can you explain this in a bit more detail, maybe with an example: "This will apply only if the current angle is less than twice the configured position tolerance." Because if my current angle is 45 degrees, and the position tolerance is 11 degrees, well that won't work because 45 is more than twice the position tolerance. And how do negative angles figure into the this? Because if I was at -45 degrees, then that would be less that twice to position tolerance.

Any other tips or tricks to using COAST_SMART like a boss? How about tweaking the position tolerance?

[laurensvalk]

It's probably a bit easier to see what this does by using a single motor.

from pybricks.parameters import Direction, Port, Stop
from pybricks.pupdevices import Motor

motor = Motor(Port.A, Direction.CLOCKWISE)

while True:
    # Try this out to compare hold, normal coast/brake and smart/coast/brake
    motor.run_angle(500, 90, Stop.COAST)

With hold, we know that we always stay close to the target. So, we make it "smart" and use run_target instead. So it will really be doing run_target(500, 90), then 180, 270, and so on. So if it ended at 87 first, for example, it will still go to 180. Not 177.

When Stop.COAST is used, the motor generally has no way of knowing what happens between moves. The user could spin it all the way around. So we really do +90 compared to the current position. If it was at 87, it may go to 177 now. Or 175, etc. This builds up over time.

What Stop.COAST_SMART aims to do is replicate the "smart" behavior of hold. It can reasonably do that if the motor hasn't been moved by the user "much". It is considered close enough if it is still within twice the position tolerance. If that is the case, it will figure out what the target is (180, 270, and so on), and go there with run_target.

I'll add some more notes about drivebases later.

[FLL-Team-24277]

Thanks, this is helpful. Since we are just talking about a single motor here, and this is using the built-in encoders, I would expect that the program you shared would work for a VERY long time (battery charge not withstanding), and would continue to run perfectly. I want to test this and see if my hypothesis is right!

I anxiously await the drivebase explanation, since the drivebase would have to use the gyro. At least I think so.....

[laurensvalk]

Since we are just talking about a single motor here, and this is using the built-in encoders, I would expect that the program you shared would work for a VERY long time (battery charge not withstanding), and would continue to run perfectly. I want to test this and see if my hypothesis is right!

You'll see the difference within a few rotations.

After thinking about it some more, I realized there is perhaps a better way to describe it. By looking at why it exists, instead of intricate details of how it works. Starting again with the single motor.

You should really just be using run_target
run_target just goes where you tell it to go. It doesn't matter where it came from.

run_angle will start from the current position and turn by the given amount. And it will do some extra magic if we can "reasonably guess what the user wanted". Specifically, Stop.HOLD and Stop.COAST_SMART and Stop.BRAKE_SMART will use run_target behind the scenes by keeping track of where the user "probably wanted to go".

You could do everything with run_target. But run_angle mainly exists because people expect it to exist. For younger audiences, doing incremental motions can be more intuitive (I don't know if that's scientifically true, since you could argue this entire problem did not exist if everything just dealt with target angles 😄).

I personally wouldn't even have added the smart modes to Pybricks, but a few other big projects that use our motor drivers depend on it. This is because some of those projects don't expose a method like run_target to the user. If run_angle is all there is, people still expect doing 4 x 90 incremental movements to end up exactly at 360, so this makes it work.

Any other tips or tricks to using COAST_SMART like a boss?

Avoid it, and use run_target 😄 The "smart" modes are going to (try to) use run_target behind the scenes anyway, so you might as well be fully in control and transparently see what your code is doing.

Extending to drive bases

turn and straight are much like run_angle. Arguably, these method does seem quite useful for drivebase, where absolute distances and headings aren't always available.

To make something like run_target work for drivebases, you can do:

remaining_angle = my_target - hub.imu.heading()
robot.turn(remaining_angle)

Notice that the stop mode doesn't matter here, at least not in terms of keeping track of any angles.

Instead you can use the stop mode that works best for you in terms of stopping smoothly, slipping, and so on.

This is probably why people have requested that the above is made available as a dedicated method, see https://github.com/orgs/pybricks/discussions/1595. You can already make it a one-liner by just doing robot.turn(my_target - hub.imu.heading()) though.

[FLL-Team-24277]

Thanks! I see how this works for turns, but how would it work for driving? I'd rather not have to make some very small turn and then start driving.

I can imagine needing to send my robot out on a mission where the first leg of the drive is 42 degrees. In the past, we relied on the driver to place to robot down perfectly (and very quickly) at 42 degrees (using markings on the mat for alignment) and then pressing a hub button to launch it. There are at least three things that can go wrong here: 1) The driver may place the robot on the mat at the wrong angle; 2) Backlash may affect how the robot is launched (but since this happens after launch, it may not be a big deal); and 3) the driver can bump the robot when pressing the button. If instead, the robot knew what heading it is supposed to drive on, that would correct for all of these errors. Using a run_target() on the Drivebase would allow us to just place the robot in position "pretty close" and not have to worry about perfection.

Accumulated gyro drift would be a concern, but we frequently square the robot up on a wall, so we could always reset the gyro whenever we do that.

[laurensvalk]

Driving is a bit like doing two run_angle() moves at the same time. One for heading. One for distance. (So not one for the left motor and one for the right.)

With straight, it will convert to degrees internally and run by that amount. It will run 0 degrees for heading.

With turn it's similar, just the opposite.

The same considerations for stopping, holding and coasting apply.

In the past, we relied on the driver to place to robot down perfectly (and very quickly) at 42 degrees

Since the gyro is not a compass, you'd still want to know some kind of starting point. Putting it on a marker works, but putting is against a flat wall is usually quicker.

Taking a step back, is there a concern with the default hold mode? This might be the most practical to use between most moves?

[FLL-Team-24277]

Is there a concern with the default hold mode??? Well, I guess I would say that I am concerend that we aren't making the most of it.

Last year we only used Stop.BRAKE and Stop.None (Stop.None was a late-add in the season and BOY was it helpful!). I remember doing some testing early in the season last year and for whatever reason we decided that Stop.BRAKE would be most useful for us. The season is over and we are getting ready to start programming for our base class for next year and I want to make sure we are doing it right.

I don't know how familiar you are with FLL, but one thing that we do (and really, ALL teams do) is when the robot comes back from doing a mission, we quickly reconfigure the robot, get it in place and relaunch it. Most of the time, we do try to launch from square on the wall, but sometimes we do not for speed reasons. We don't want to waste time with a turn.

So, imagine this use case. The robot is driving back to base, say on heading 210. We need to turn the robot around (by hand) to 42 degrees, and then relaunch it (after reconfiguring it). So, is it possible for the robot to know that instead of placing it at 42 degrees, that it is actually sitting at 44 degrees and as soon as I press the button and relaunch the robot, it will correct itself to 42 degrees and complete that drive? Is this something already built in, or would I have to program that? Or is that just a bad idea (gyro drift comes to mind)?

By the way, this may also play into the use case: This whole transition I described can take somewhere between 2 and 10 seconds. So when the robot is drivivng back, we grab it as soon as it is legal and start getting ready for the next launch. So, we could be agressively turning the robot by hand while the robot thinks it is still driving (usually in the air, but I think you get the picture). We time it so the drive ends soon after getting into base, but I do wonder if that period where the robots thinks it is still driving but it actually isn't will impact our improved/proposed relaunch capability.

I'm going to start doing some testing this week, but hearing from you how it is supposed to work, or how it could work, is very helpful!

[zoligyenge]

Any chance of adding COAST_SMART into block coding?