DriveBase.curve in Reverse

[UnusualJustin]

I'm currently coaching an FLL team in AL that is just getting started using Pybricks. So far, we've been exploring the capabilities and experimenting with converting some of our existing Scratch programs to Pybricks.

Something that came up recently was the desire to have our robot follow a curve in reverse. We discovered that we could do this if we provided a negative value for the radius parameter. Is this intentional or just a happy accident? It's not documented as a capability as far as I can tell and it's not the most intuitive way to accomplish the action (IMO). If it's not intentional, perhaps offering an optional parameter or an additional method to drive in reverse explicitly. If it is intentional, a comment in the docs could prove helpful to others.

[laurensvalk]

I’m traveling so my answer is a bit short, but you can use a negative angle to ‘reverse’.

Try drawing a picture of a robot traversing a circle, and draw a pizza slice in it. The angle parameter is the angle of the slice, and the robot traverses along the crust.

A negative angle makes it traverse the circle in the other way, just like using a negative angle in a normal turn command. So it is going to traverse along the pizza slice crust the other way, thus ‘in reverse’.

For the negative radius the situation is similar, but we should add a diagram to the docs indeed. You can avoid this though - using the negative angle is more intuitive.

[UnusualJustin]

Thanks for your reply. I may not have explained the behavior clearly.

I believe what you're describing is illustrated in the top to circles on my diagram. What I was curious about is the bottom two scenarios - where the robot is driving in reverse.

To summarize my observations:

• positive radius, positive angle: forward / clockwise
• positive radius, negative angle: forward / counterclockwise
• negative radius, positive angle: backward / counterclockwise
• negative radius, negative angle: backward / clockwise

[JDwyer009]

I have to agree with @UnusualJustin here.

So, having started to write a test program for all the methods in the DriveBase class, (as part of
Make drivebase turns counterclockwise for positive turn_rate when reversing #1191) I have to agree that the .curve() method is not as intuitive as it could be.

The method itself works really well and surprisingly accurate with the SPIKE platform. It is currently set up as follows:
.curve(radius, angle, then=Stop.HOLD, wait=True)

So as it currently exists, for driving the midpoint of the robot's wheelbase one full loop around a 24cm/240mm circle, the code works as follows:

drive_base.curve(240, 360)   # Drives fwd Clockwise
drive_base.curve(240, -360)  # Drives fwd Counterclockwise
drive_base.curve(-240, 360)   # Drives Bkwd Clockwise
drive_base.curve(-240, -360)  # Drives Bkwd Counterclockwise

The non-intuitive part is using a negative value for the radius of the circle. My suggestion is to include a boolean to determine whether the robot is driving clockwise or counter-clockwise and just make the angle dictate whether the robot travelling in a fwd or backward direction.

Hence the method becomes .curve(radius, angle, clockwise=True, then=Stop.HOLD, wait=True)

drive_base.curve(240, 360, True)   # Drives fwd Clockwise
drive_base.curve(240, 360, False)  # Drives fwd Counterclockwise
drive_base.curve(240, -360, True)  # Drives Bkwd Clockwise
drive_base.curve(240, -360, False) # Drives Bkwd Counterclockwise

What do you think?

[dlech]

I'm having a hard time visualizing what CW/CCW mean in this context, especially when it comes to going in reverse.

curve() is currently described in the docs as:

Drives an arc along a circle of a given radius, by a given angle.

It doesn't say anything about how negative values affect anything, so my natural inclination is that it should work like this:

• If the radius is positive, it curves to the right (drives along green line), or if negative, it curves to the left (drives along red line).
• If the angle is positive, it drives forward or if negative, it drives backwards.

Is this how it works now? Or is this what is being proposed how it should work? Or did I just make up a 3rd interpretation?

[JDwyer009]

@dlech Thanks for the diagram.

Your explanation above is how .curve() works. And I believe it is intuitively how most people would expect it to work.

However, .drive() works differently.
From the starting position:
1) driving Fwd in a clockwise direction means you move forward on the green line;
2) But, driving Rev in a clockwise direction means you reverse along the red line (not the green line as per .curve())

You and I are both expecting that by reversing the direction, we still remain on the same turning trajectory, as we do when reversing a turning car. More specifically if when steering a car clockwise and then put it in reverse, you are now going in reverse AND CCW.

I can post a video demonstrating the inconsistency if that would help.

[dlech]

Your explanation above is how .curve() works. And I believe it is intuitively how most people would expect it to work.

I guess I'm a bit confused by this comment because two days ago, you said:

I have to agree that the .curve() method is not as intuitive as it could be.

Perhaps you wrote curve but meant drive in your previous comment?

[JDwyer009]

Yes, my issue is with the .drive() and not .curve(). Two days ago, I thought they both behaved the same. But after doing some testing I now realise they appear to behave differently. Apologies for any confusion at my end.

[laurensvalk]

That's a third interpretation @dlech 😄

I'm working on a few other projects right now, but I'll try to update the docs next week to clarify.

I see there can be different intuititions, and I don't know that one is objectively better than the other.

One important addition that may also help remember things intuitively -- the curve is just a more general version of the turn command.

So with a radius of 0 you just get the same as a turn.

(That's a general design principle: no special cases for 0. Anything close to zero should work just like zero. Transitioning from - 1 though 0 to 1 should never give big jumps)

[JDwyer009]

I can see the competing interests you are dealing with in terms of efficiency in code vs clarity of instructions vs ease of use.

Are the .curve() and .drive() methods meant to behave differently? .curve() seems to be more intuitive.

Whilst the +ve and -ve radius is logical around a circle, it is not intuitively obvious that a negative angle creates the CCW movement. However, adding a quick code sample like the following into the method explanation in the docs will help people's understanding.

drive_base.curve(120, 360)   # Drives Clockwise Fwd
drive_base.curve(-120, 360)   # Drives CounterClockwise in Rev
drive_base.curve(120, -360)  # Drives Counterclockwise Fwd
drive_base.curve(-120, -360)  # Drives Clockwise in Rev

So I can understand why you might choose to stay with the two parameters for the .curve method.

However, I'm still stuck with the .drive() method being intuitively wrong. Try a simple remote control program and get the robot to move in reverse and it is completely the opposite to steering a vehicle in the real world.

Trying to explain the difference between the two functions:

The first two lines of the .curve() code above has the robot complete a clockwise circle, then the second line reverses the robot over the same circle. This seems correct to me.
In contrast, the .drive() code below behaves differently. While 'Action 1' similarly drives the robot fwd clockwise for a one circle, 'Action 2' which simply reverses the speed as with the .curve() example but this time rather than retracing the circle in reverse, completes the second half of a figure of 8 in reverse, which is different.

drive_base.drive(200, 90)   # Action 1: Drives fwd Clockwise
wait(4000)
drive_base.drive(-200, 90)   # Action 2: Drives Rev Clockwise
wait(4000)
drive_base.stop()

I suspect these might actually switched around on .drive():

"Angle sign determines CW/CCW (just like the drive method turn rate)
radius sign determines FWD/REV (just like the drive method drive speed)"

[JDwyer009]

Just in case there is a lack of clarity in my responses above. Here is a simple program that best demonstrates an inconsistency between the .curve() and .drive() methods.

from pybricks.pupdevices import Motor
from pybricks.parameters import Direction, Port
from pybricks.robotics import DriveBase
from pybricks.tools import wait

# Initialize the drive base. 
motorL = Motor(Port.C, Direction.COUNTERCLOCKWISE) 
motorR = Motor(Port.D) 
drive_base = DriveBase(motorL, motorR, wheel_diameter=56, axle_track=97) 

drive_base.curve(120, 360)   # Drives Clockwise Fwd
drive_base.curve(-120, 360)   # Drives CounterClockwise in Rev

drive_base.drive(200, 90)   # Drives Clockwise Fwd
wait(4000)
drive_base.drive(-200, 90)   # Drives Clockwise in Rev
wait(4000)
drive_base.stop()

Changing the radius from +ve to -ve in the .curve() method toggles both the direction (Rev) and the turn direction (CCW). This robot behavior seems the most intuitive and logical to me.

If the .drive() function was changed to have the same behavior as the .curve(), it would resolve my perceived problem on issue Make drivebase turns counterclockwise for positive turn_rate when reversing #1191.