FYI, Steering Mode - Turn Radius is TURN_RADIUS in parameter list. Mine is 0.53
I tried driving in ACRO mode and it drives fine, just seems like the stick setting hold for a second or so after releasing. There is also a little shaking for a couple seconds when entering ACRO mode, then it settles down.
Don’t really understand what ACRO mode is. The guide says “In Acro mode the user’s steering stick controls the vehicle’s turn rate and the throttle stick controls the vehicle’s speed.” but then contradictorily a couple sentences later it says “Once the input returns to neutral, the vehicle will attempt to hold heading, compensating for external influences, ie. “heading hold”.”
Well my rover does the first, it does what the sticks say, and doesn’t seem to do any heading hold. It seems like ACRO mode has the additional restriction of requiring GPS lock with the only benefit being Object Avoidance.
For a skid-steering rover it won’t matter what you put into the Turn Radius parameter (aka TURN_RADIUS), it won’t be used on a skid-steering vehicle.
If Acro mode doesn’t work then I would expect more complex modes (like Auto) also won’t work well. If you post a log file of the vehicle executing an auto mode of a square missing with sides at least 5m long then I’m happy to have a peek and give advice.
In Acro mode the pilot controls the turn rate with the steering stick. So with the stick centered it should not turn at all (aka “heading hold”). The difference here vs manual mode is that in Manual mode, if the pilot attempts to drive in a straight line, it may not accomplish that. For example if the vehicle is driving on a slope it will very likely turn slightly down the slope. Or if the steering mechanism is not perfectly straight it will slowly turn left or right. In Acro mode the turn rate controller is active so the vehicle should drive nearly perfectly straight (when the pilot leaves the steering input in the center).
Acro mode will use the GPS (or more accurately the EKF’s velocity estimate) in order to control the speed of the vehicle (using the pilot’s throttle input as the desired speed). So you should find that if the pilot holds the throttle stick above zero and doesn’t move it around that the vehicle maintains a steady ground speed. It should do this regardless of the surface (e.g asphalt vs ground) or ground slope (e.g. uphill, downhill).
This mode should feel similar to Manual mode but a little less responsive but also require fewer corrections from the pilot.
It does, but the “somehow” is that it follows RC throttle. Like Randy said, a stable RC throttle should produce a constant velocity (vs manual mode where it would just be a constant, fixed output).
Ok, to clarify further, where it says “Once the input returns to neutral, the vehicle will attempt to hold heading, compensating for external influences, ie. “heading hold”." I took it to mean that with both steering AND throttle at neutral that the rover would continue moving.
I’ve got the new 10" Ninebot motors installed, Odrive is tuned, and now working on Ardurover tuning. Ran the Quiktune script and have some oscillation at standstill when in Acro mode:
I tried to manually edit the Steering P and I parameters in Basic Config, and it seems to have no effect. Was trying to reduce them to see if it would stop the oscillation.
Found out why my manual edits weren’t having any effect. Previously I had set SCR_ENABLE = 0 and RTUN_ENABLE = 0 and rebooted, but it seems the “Reboot Pixhawk” button in the Ctrl-F menu either has no effect, or is inconsistent. Now I set them both = 0 and rebooted by pulling power, and was able to manually edit the tuning parameters.
I have to set ATC_STR_RAT_P = 0 (Steering Rate P in Basic Tuning) in order to stop the oscillations at standstill. I’m inclined to not worry about it, as I know there is some springyness in the drive axle attachment, as the height adjuster latches only on the left side, and in normal operation it shouldn’t be an issue.
Working now on the pivot turns, they are very poor as it will often sit still and not have enough power to rotate, then will wildly oversteer before getting back on course.
Reading the Turn rate tuning, ATC_STR_RAT_MAX and ACRO_TURN_RATE need to be set before running the Quiktune script. They are both = 180, so should be good. Could probably reduce them as it spins in place pretty quickly in Manual mode, maybe even 360 degrees/sec.
Still not sure why Acro has such weak steering power.
I went back to basics to get this sorted. Ran the Motor Test under Mission Planner>Setup>Optional Hardware>Motor Test, to make sure both motors are spinning the correct direction, and I don’t have any double-reversed controls. Then setup a mission with a right angle triangle repeated several times so I could see how pivot turns are doing. Set Steering Rate PID all = 0 gradually moved Steering Rate FF all the way up to 3 to get good power to initiate the turn. Gradually moved P up to 0.2, then ended up with I = 0.2 also. Pivots were better but overshooting quite a bit still. Moved D up to 0.2 and better.
Looked into the Pivot turn settings, and instead of setting ATC_STR_ACC_MAX to “Close to the vehicles performance limit”, I dropped it down from 180 to 90 deg/s.
I had also assumed that WP_PIVOT_RATE should be close to vehicles performance limit, but that was way wrong, set it down from 80 to 20 deg/s.
Pivot turns now have MUCH less overshoot, Bumped up ATC_STR_ANG_P from 2 to 3, and Pivots are now quite nice.
So here are my current Steering Rate Parameters:
P = 0.2
I = 0.2
D = 0.2
IMAX = 1
FF = 3
Those parameters have nothing to do with the ability to make ATC* changes that should take effect immediately without reboot (or even arm/disarm).
The reboot button only works when disarmed.
Sharing raw parameters without a log is of little value when it comes to tuning. If you’d like tuning help, please share a .bin log of your Rover while in motion in ACRO and/or AUTO modes.
@Yuri_Rage Thanks, that makes sense about requiring disarm before reboot.
I set the Steering Rate D down to zero, wasn’t needed after reducing the WP_PIVOT_RATE. Ran a Quiktune again, and it left the Steering Rate FF quite a bit higher this time, still not high enough to actually initiate a turn half the time. I have to switch to Manual and give it a bump, then back to Auto.
Current Steering Rate Params:
P = 0.397
I = 0.397
D = 0
IMAX = 1.0
FF = 0.794
Here is a link to .bin file of the Lawnbot running an AUTO mission of triangle with 3 pivot turns, repeated 3 times.
Bumped the Steering FF up to 1.5, pivot turns Usually have enough drive to turn & complete now.
I’m realizing there is a motor problem, as sometimes when I switch to Manual mode, there isn’t enough torque either. Also occasionally get EKF3 Stopped/Started aiding, looking like Left motor encoder dropping out. This Odrive 3.6 only has 0.1" friction headers for the encoder input, think I’m getting poor connections. Gonna see if I can get some better quality header pins.
Replaced the encoder input pins. Previous pins were not a true square pin, new ones are square and seem to be giving reliable connection.
Also found the Odrive was sending much less current to the motors than I realized. My current Odrive current limit was set to 20A for each motor, but Ardupilot was showing a total of 10A Max for BOTH motors on pivot turns.
So… education on motor controllers. Individual motor phase current can be much higher than actual bus current draw due to motor inductance. Bottom line, I was safe to increase Odrive current limit for each motor
odrv0.axis0.motor.config.current_lim = 30
and
odrv0.axis1.motor.config.current_lim = 30
from 20A to 30A and still have bus current far below my battery cutoff current of 28A.
Pivot turns are now working nicely. Ran Quiktune again and it gave acceptable Steering rate parameters of P = 0.14, I = 0.14 and FF = 0.28. Bumping FF up to 0.4 gave better response on pivot turns.
My final Steering Rate Params:
P = 0.2
I = 0.2
D = 0
IMAX = 1.0
FF = 0.4
Ran an actual mowing mission (1st since 2022!), on the first test without blades running, it got stuck on one corner and I had to switch to manual to bump it out then resumed Auto and completed. Still looking into that.
Tuned Navigation parameters and ended with
PSC_VEL_P = 1.5
PSC_VEL_I = 0.3
PSC_VEL_D = 0.15
Couldn’t seem to get it any better, still got a little wander off track and not sure how to improve it.
Here is a track with actual blades running and cutting:
Turned the compass back on and calibrated it while the mower engine and blades were running. Ran the same mission as above and maybe tracking better?? Anyway, having the compass on got rid of the EKF errors when CubeOrange first boots up, so that’s nice.
Remember this is a 21" (0.5M) mower, and this pattern is about 60’/19M square, so it’s missing a few strips but overall doing productive mowing. If I keep up on mowing 1-2 times a week, the strips will be barely noticable.
