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.
No problem. I suspect the lag is coming from the mechanics of the frame itself so there may no way to get rid of it. If ATR_STR_RAT_P, I and D are all zero so only FF is used then when driving in Acro you’re basically driving in manual mode and any lag must be from the frame itself.
Thanks, Randy. It is possible that the delay is from the frame itself. I am using two F9Ps for the GPS yaw setup with no compass on board. The GPS_RATE_MS is set at 200 (5hz) per @tridge advice here Yuri's 4.1.0-beta Update (GPS yaw - now 4.2.0-dev) - #121 by tridge. That is the heading itself takes 0.2 second to be measured. My rover is setup as a skid steer, which may add to additional delay in my particular case, although Yuri and others clearly had achieved enviable results.
GPS update rate won’t cause frame delay. The EKF will fill in gaps of even several seconds without issue. It’s a mechanical thing, almost certainly.
The EKF estimates the yaw using a mixture of gyro and the absolute heading source (compass, GPS, etc) so the slower GPS update rate should not cause a lag in the heading (or yaw rate).
1 Like
hmm… Thank you both again. Speaking of gyro (IMU), maybe I should try a different flight control. I am using Metek H743 slim currently and I also have a Kakute F7 that I can give it a try in the future (next spring). Thanks again for all the advice.
The H743 should result in superior performance.
The Kakute F7 only has 1 MB of Flash. The standard builds of AruRover for 1MB flash controllers do not have GPS Moving Baseline (GPS for Yaw). See Firmware Limitations on AutoPilot Hardware — Rover documentation (ardupilot.org). So you probably should stick with your H743. I had a Kakute F7 until I realized this limitation and switched to a Cube Orange.
1 Like