Wobbly Path has to be one of the biggest issues when setting up a new boat - took me 4 years to get my AIMy craft to run accurately, then she still has some bad days.
The parameter setup needs to be simplified.
Yes, I am still new to Ardurover and have been challenged to tune it to what I saw other people have achieved. I am almost blindly guessing the ATC_STR_FF and other turning parameters; but no luck so far. I had to set the PIVOT_TURN_ANGLE and WP_PIVOT_ANGLE at a very low value, such as 15 and 30, in order to get the turning somewhat close to what it should be. The problem is then the rover stops at every turn and attempts to turn twice for a say 60 degree turn with each complete full turn as each pivot turn is capped at 15 degree. So suggestions from the more experienced users will be appreciated.
If your Rover is undershooting pivot turns (turning twice as you say), you probably need to increase ATC_STR_ANG_P.
As for rate tuning non-pivot turns:
Zero the ATC_STR_RAT P, I, and D terms. Tune ATC_STR_RAT_FF using the graph on the Data screen as suggested in the documentation, and do not touch the I or D terms until you are convinced you cannot further refine FF. Then maybe add a small fraction of I to compensate for long term error.
1 Like
Thank you very much, Yuri. I have seen a lot of your videos and Kenny’s videos. They are inspirational!
Thank you for the suggestion of increasing ATC_STR_ANG_P. I will give it a try if weather permits.
Also thank you for the suggestion on zeroing out the initial PID terms. I did try that, and estimated the max capable turn rate first (the gz value on the Tuning graph of the Mission Planner main screen). I have two unexplained results or issues:
-
The gz value shows that my rover can only turn at around 25 degrees per second, which is much lower than I expected as it seems that my rover can easily complete a 360-degree turn in less than 6 seconds. This is really just for curiosity and is not big deal at all.
-
The bigger issue I am trying to solve is to make the rover to turn “confidently” and without overshooting. I did set the ACRO_TURN_RATE and the ATC_STR_RAT_MAX to around 25 degree determined from the above. Then I zeroed out ATC_STR_RAT_P, I, and D and started ATC_STR_RAT_FF with a low value then gradually increased it. I got two additional unexpected results:
a. When I set ATC_STR_RAT_FF to 0.8, which was close to the PID.Tar (as shown the 2nd picture of my previous post), the rover overshoots violently, sometimes overshooting 360 degrees, before correcting itself.
b. When I set the FF to a much lower value at 0.2, as shown on the 3rd picture of my prior post, the rover hesitates and undershoots the pivot turns, having to complete two small pivot turns before getting a say 60 degree turn. The FF value in this case is much lower than the PID.Tar, which is very counter intuitive.
In both of those cases, PID.Act appears to lagged the PID.Tar and the PID.Act overshoots then over corrects compared with the PID.Tar. I have tried multiple FF values, but no luck so far.
Is there a way to make an educated guess of the ATC_STR_RAT_FF value based on the physical characteristics of the rover? If there is, I will appreciate some guidance here.
I have tried the following and got ATC_STR_RAT_FF to be ~0.35; but it didn’t do the trick for me. Given the ATC_STR_RAT_FF can be greater than 1, I am not sure the method below is correct either.
I also read another post here, Documentation of how to calculate ATC_STR_RAT_FF for Rover · Issue #8323 · ArduPilot/ardupilot · GitHub, unfortunately I am at a lost in reading the AR_AttitudeControl source code without much knowledge of the architecture of the Ardupilot source code.
Thank you very much again for the tips. Any additional advice will be very much appreciated.
Don’t neglect any parameter labeled ATC_STR. Have a play with the accel and max rate values. It sounds like perhaps your accel value is set too high, which could cause some frustrating results elsewhere. Unfortunately, if you change the acceleration and max rate characteristics, you’ll almost certainly have to re-tune the rate controller to match.
I don’t have a particularly scientific answer for you. I tune by trial and (lots of) error. But I do go slowly, changing one or maybe two things at a time, and either taking notes or saving backups all along the way. It helps to study PID and feed forward control and have an idea of what the terms mean and how they relate to the loop’s input, output, and one another. I’ve been meaning to dive into the very threads that you linked in an effort to be a bit more measured in my approach.
1 Like
Thank you, Yuri.
I increased ATC_STR_ANG_P and even at values above the upper bound of 10 while keeping ATC_STR_RAT_FF at 0.2. I have also tried to increase ATC_STR_RAT_FF and while lowering ATC_STR_ANG_P. The turning still isn’t satisfactorily. The rover either undershoots or overshoots and/or starts to zig zagging along straight lines.
Looking at my PIDS.Act vs. PIDS.Tar, it appears that I might have too high of error filter rate. I lowered ATC_STR_RAT_FLTE to 1 and ATC_STR_RAT_FLTT to 0.5, similar to what I understand of the NAVL1_PERIOD parameter, but no luck so far. The Ardurover 4.1.1 version no long has the ATC_STR_RAT_FILT parameter as in the prior versions. I wonder if anyone has experienced with ATC_STR_RAT_FLTT.
Now that the snow has arrived in upper Midwest, I will probably have to wait till next spring for additional tuning. If Randy @rmackay9 and/or other experts on the board would offer other suggestions based on my log files, I will definitely appreciate it.
Separately, I have three other rookie questions:
- Is there a way to slow down the graph on the Tuning window? The time scale of the Tuning screening is 1 second. Considering the noise and how slow my rover turns (~25 degrees/second per the gz value), the graph on the Tuning pane became very noisy. I had to make the rover executing missions then review the DataFlash Logs to perform tuning, which is quite inefficient.
- How to increase the purple trail showing where the rover has been? On my Mission Planner, the purple trail was relative short, only capturing one or two actual turns before it disappears.
- Can the SITL (Software in the Loop) simulate how the rover would turn? I don’t imagine it is possible, but that would make it much easier to tune the parameters.
Thank you in advance.
You are tuning competing parameters simultaneously. Tune ATC_STR_RAT_FF in ACRO mode first, then dial in the pivot turns in AUTO mode by changing ATC_STR_ANG_P. If you make any changes to the min/max rate and acceleration parameters, you likely also have to go back and retune the control loop (FF, P, I, D) parameters as a result.
Also, keep NAVL1_PERIOD somewhat lengthy for now (the default is 15-20). Once the steering rate controller is a little more dialed in, you can address the NAVL1 controller.
For Rovers, I have always left the filter parameters at their defaults with no issue. Perhaps that is naïve of me, but it’s been successful.
As for your other questions:
- I don’t think you can slow the rate of the graph. If that’s possible, I’m unaware of the setting.
- Config screen, Planner, increase “Track Length”
- SITL tends to be somewhat idealistic in nature unless you really deep dive, and I’m certainly not the one to explain how to program a physics model. I doubt a Winter’s worth of coding in SITL would produce Springtime results on your physical Rover…but if you succeed at that, it’s a story I will definitely follow!
2 Likes
Thank you very much for the advice and tips, Yuri. I can’t wait for the s-curve that may solve all these challenges.
2 Likes
On the subject of NAVL1, I don’t know if this is a “pro tip” or just my crazy method, but once I get things tuned with the default PERIOD setting, I will dial it down to an unrealistically short value (2-5) and try to tame the likely wild oscillating behavior in AUTO. Once I feel that I can’t get any better with a super short period, I slowly increase the period again until the behavior is best (aiming for about 5-8).
1 Like
I was able to tune the rover a bit more today. I found two issues:
-
I didn’t set my INS_POS* correctly. I previously set them to relative to the center of the rover and have changed them to be relative to the center of the rear axle of the skid steer rover.
-
My rover’s steering reaction time appears to have about one second lag relative to the AdruoPilot’s command. See the pictures below. The delay could be due to the motor response lag or due to incorrectly setting other Ardupilot parameters. From the STER.TurnRate graphy, my rover is capable of turning at ~100 degree/second, which is in line with observations when using remote control under ACRO/Manual mode. Looking at the throttle and throttle response, it looks fine to me even though there is a small lag in deceleration, making me wonder if I have set a too aggressive of ATC_DECEL_MAX at 5, vs. the ATC_ACCEL_MAX parameter of 0.2.
I will appreciate suggestions if anyone has experienced similar issues or has answers to questions below:
-
Is there a way to compensate the mechanical response lag? Meaning is there a way to allow Ardupilot software to recognize that there is an about 1 second lag in the physical world after Ardupilot issuing the steering command? The electrical motors on my rover is driven by ESC getting PPM signals directly from the flight control.
-
I have tried to increase ATC_STR_RAT_FF parameter, the rover overshoots even more. I have also tried reducing the ATC_STR_MAX_RAT to 25, as reported by the “gz” (Gyro Z-axis) value per the tuning instructionhttps://ardupilot.org/rover/docs/rover-tuning-steering-rate.html. However, the low ATC_STR_MAX_RAT value causes the rover to undershoot/hesitates in making turns.
Many thanks.
Go back to basics. Tune the FF parameter (to a probably lower value) in ACRO using the graph. Then tune ATC_STR_ANG_P in AUTO to avoid overshoots.
Decrease your accel values to account for lag.
1 Like
Thank you, Yuri. I was honing in on the ATC_DECEL_MAX param from my third picture above. It took me a while to figure out what you mean by increasing the ATC_ACCEL_MAX value. Got it. Thank you. I will give it a try tomorrow.
I have done some thinking-out-of-the-box experiment today and have some findings maybe of interest.
I did the following:
- Changed TURN_RADIUS to 0 from 1, which was what I previously had. The skid steer turning is much tighter under ACRO mode.
- Changed ATC_STR_ACC_MAX to 0 – removing the limit. Per @rmackay9 post here Rover: ensure ATC_* and PIVOT* params don't cause overshoot during pivot turns · Issue #8788 · ArduPilot/ardupilot · GitHub, it appears that I need higher ATC_STR_ACC_MAX to prevent my rover to overshoot, even though this is counter intuitive, as I had tried but with less success with lower ATC_STR_ACC_MAX values say at below 90.
- Changed MOT_STR_THR_MIX to 1 – prioritize steering over speed, also per Randy’s post here: Pidachieved opposite to piddesired? - #14 by rmackay9
- Changed MOT_SLEWRATE to 50 – reducing current drawn at acceleration as per some discussions on this board.
- Increased STR_RAT_MAX to 90, despite gz saying only ~25 degree/second. From my data logs, it appears my rover often overshoots to ~100 degrees/second.
- Played with different ATC_STR_RAT_FF values and set P and I to ~20% per Randy’s post here How to solve ROVER meandering? - #6 by rmackay9
It appears that my rover performed a bit better at turns now, steering more confidently compared with what I had before, even though as of now, my rover still doesn’t make perfect turns and not following straight line.
I have tried going back to the basic, starting from default parameters and then tune the speed controller before the tuning the turn rate, but I still wasn’t able to figure out how to compensate my rover’s phase shift issue when it comes to tuning the steering as shown below, confirmed by my dataflash logs. The (steering) pidachieved is about 1 second lagged compared with the piddesired. Some website suggested feedforward controller could accommodate this type of phase shift; but I don’t know enough the working of Ardurover to guestimate the mysterious ATC_STR_RAT_FF value.
I wonder if board members have experienced this kind of delay in response issues, and how you might have solved this. (My rear wheel drive, skid-steer rover is driven by ESC directly connected to the flight control. So I shouldn’t have issue with mechanical lags for example due to servo linkage.) Any advice will be appreciated.
Hi @humble800,
I don’t have a lot of advice immediately but the TURN_RADIUS shouldn’t affect Acro mode as far as I know.
In general the ATC_STR_RAT_FF is the most important steering parameter. I often set ATC_STR_RAT_P and ATC_STR_RAT_I to zero and then tune just ATC_STR_RAT_FF first looking at those tuning graph’s desired and achieved values. Then I just simply set ATC_STR_RAT_P and I to about 20% of the FF and if often works well.
After getting this steering turn rate controller tuned then the pivot turns and straight line performance are mostly separate. I think if you can set up an autonomous mission with just two waypoints very far apart and a do-jump at the end so the vehicle just goes back and forth that could be good for tuning. If the steering turn rate controller is tuned well and the vehicle still meanders along the straight path then it is the NAVL1_ parameters that need tuning. in general you might need to increase the NAVL1_PERIOD to reduce navigation aggressiveness or increase the NAVL1_DAMPING to increase the push-back against turning.
Another alternative to a back-and-forth mission is to use Guided and input a point far away but straight ahead of the vehicle. One problem that happens is a bad pivot turn can introduce errors which can take the L1 navigation controller a while to get over.
Thank you very much for the suggestions, Randy. I have indeed tried to tune it by the book. The main challenge I have is the response delay and guessing the ATC_STR_RAT_FF value.
I have two questions:
-
Is there any estimate of ATC_STR_RAT_FF base on the wheel rpm, wheel size, and the width of the axle?
-
What ardupilot parameters I may set to accommodate the response lag as shown on my pidachieved vs. piddesired tuning chart above?
Thanks again.
Your feed forward term looks like it may be roughly correct based on the graphs. Use acceleration rate limiting rather than disabling it to account for the lag that you see (it will tend to “clamp” the desired value and should allow the achieved value to get closer).
1 Like
Thank you, Yuri. Happy Black Friday. I initially had ATC_STR_ACC_MAX at 180 then at something below 180, say at 90, 45, etc. The experience I had was that the rover undershoots at sharp angle or overshoots at obtuse angle. It gave me a sense that the rover doesn’t accelerate and/or slow the turn rate fast enough. So I removed ATC_STR_ACC_MAX limit by setting it to 0. It appears to overshoot or undershoot less than before. It is indeed counter intuitive to me.
From your videos, you are driving a large mower with servos. Do you observe similar “response lag” on your tuning screen comparing the pidachieved with piddesired?
It’s there but slight, and my means of avoiding it is exactly what I just described.
The servos I use are quite strong with a pretty fast response and quite a bit of leverage on the control arms. They are capable of driving the mower quite violently, and I actually tune, in part, to limit their effectiveness.
1 Like
We don’t have any advice on calculating the FF from tire size, etc. I’m not sure we could realistically come up with that because there are so many parts that affect the response (e.g. battery voltage, ESC, motor, tires)… it’s worth thinking about though, thanks for the suggestion.
In general I think that with a laggy response the P and I gains in the steering control will need to be lower than they would be with the same frame but with a quicker response. The L1 navigation damping may also need to be higher.
Thank you, Randy and thank you,Yuri. If the weather permits, I will tune down the P and I and see how it goes. I will also try different values for the ATC_STR_ACC_MAX as Yuri suggested. So far I seem to have gotten the best result with ATC_STR_ACC_MAX = 0;
Before today, I have tried both large and small ATC_STR_RAT_FF, with P, I, and D held at 0. Strangely, I consistently observed the un-explainable response lag in pidachieved compared with the piddesired.