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
Thank you for joining the discussions, Kenny. The reason that I initially chose Kakute F7 was actually from watching your videos. On the prior Ardurover versions, prior to 4.1.1 or 4.1.0 stable, I was able to use Kakute F7 to get to GPS heading, which was before I put the rover together.
With the recent ardurover firmware update, Kakute F7 no longer has the GPS_DRV_OPTIONS. Thus I went with H743. Even though I have access to GPS_DRV_OPTIONS with H743, I am still not able to set GPS_DRV_OPTIONS to 1. If I do so, the F9P baud rate will drop to ~230k instead of the ~460k I set for the GPS yaw. Right now, I seem to be able to get steady GPS yaw with GPS_DRV_OPTIONS=0. I haven’t not spent much effort on the GPS yaw part itself.
Do you have GPS_DRV_OPTIONS=0 on your setup or do you have GPS_DRV_OPTIONS=1?
230400 (on UART1) is correct with those settings. Let the auto configuration do its magic.
As Yuri just stated, you should let the Autoconfig do everything unless you have a reason that the baud rates it chooses do not work with your hardware for some reason. I have GPS_AUTO_CONFIG=1, so that ArduRover sets everything up. And I have GPS_DRV_OPTIONS=1, so that ArduRover knows I have a hardwired connection between UART2 on the MB GPS and UART2 on the Rover GPS.
When you state “GPS_DRV_OPTIONS” in your previous post, do you mean “GPS_AUTO_CONFIG”? The reason I ask is that whether you have GPS_DRV_OPTIONS at 0 or 1, ArduRover is going to set the baud to 230400 on UART1 on both GPSes. If you have GPS_DRV_OPTIONS=1, it will also set the baud rate for UART2 on both GPSes to 460800 for the RTCM3 from MB to Rover.
As you probably saw in my videos, I am sending RTCM3 from the fixed base to the moving base UART2 directly via an Adafruit Feather LoRa module. So, basically I have UART2 on the MB doing double duty - receiving RTMC3 from the fixed base and sending RTCM3 to the Rover GPS. That means I have to use a baud rate that will work for both duties. I mistakenly thought that the Feather could not run at 460800, so I was unable to let ArduRover do the setup (or I had to compile my own version of the code). Well, I had to wipe the egg off my face when I realized that the Feather could work at 460800! So, I can, after all, let ArduRover do it’s magic and set everything up. Oh Happy Day!
Thanks, Kenny. I do mean to refer to the GPS_DRV_OPTIONS, the option enabling GPS1 and GPS2 (i.e. moving base and rover) to communicate RTCM via their UART2 ports.
On the older version of Ardurover firmware and with the Kakute F7, I was able to set the GPS baud rate to 460800 and get the GPS YAW working with GPS_AUTO_CONFIG=1 and GPS_DRV_OPTIONS=1.
However, when the final Ardurover version 4.1.0 and 4.1.1 were released, the Kakute F7 rover firmware no longer has GPS_DRV_OPTIONS parameter available through Mission Planner. So I switched to Matek H743.
On the Matek H743, I still have GPS_AUTO_CONFIG=1; but I had to set GPS_DRV_OPTIONS to 0 in order to get GPS Yaw working. When I set GPS_DRV_OPTIONS to 1, only one of the two GPS was recognized by the flight control and showed up on Mission Planner Message window, saying being detected at 230400 baud rate. The other GPS was not recognized. When I changed GPS_DRV_OPTIONS to 0, GPS YAW appears working as it should and stable. I believe my UART2 connections on the F9P was connected correctly to each other as I was able to get GPS YAW working on Kakute F7 with older firmware, before switching to use the latest firmware on Matek H743.
Separately, I did some tuning today; and had the rover repeatedly running a straight line mission as Randy suggested. I only focused on keeping the NAVL1 at a low value of 14.5 while tuning the ATC_STR_RAT_FF, and P and I. It appears that the rover can go straight line (~30 meters) though it takes some times, oscillating five times, over ~20 to 35 meters distance to converge back to the track. Looking only the graph below, it appears that I might be able reduce the P to improve the stability and perhaps slightly increase I. My ATC_STR_RAT_FF is 0.35, P=0.03 and I=0.03.
While this shows some promising sign, it doesn’t explain why my rover’s steering PIDAchieved is about 1 second lagged behind PIDDesired. I am planning to add a co-processor in between the flight control and ESC, and write some codes to inspect whether there is similar lag between the flight control’s RC out and ESC reported motor RPM.
Well, the snow on the ground has spelt the end of my further tuning this year until next spring comes. Glad to see Kenny’s new video and I am jealous of the warm weather in the south.
2 Likes
We are converting a part of the barn next to our house into a living space (a barndominium?). Maybe a new source of income is a winter Ardurover getaway!
2 Likes