I can confirm that I am not able to change the ATC_STR_RAT_FF beyond 0.5
and ATC_STR_RAT_P cannot be set to zero from Mission planner. I attempted to write
ATC_STR_RAT_FF = 3 and ATC_STR_RAT_P = 0 and reloaded the page and noticed that the values remain at 0.5 for FF and 0.1 for P.
I switched to QGroundControl and I can change those values successfully.
ATC_STR_RAT_FF was then set to 3 in QGroundControl
and ATC_STR_RAT_P was set to 0.
I then switched back to Mission Planner and I can see those changes when the parameter tree was loaded.
I then tried to change the ATC_STR_RAT_FF value to 2.5 in Mission planner, clicked write param and then refreshed the param tree. Again Mission planner did not allow me to write the param. It basically retain the ATC_STR_RAT_FF = 3 that I did previously with QGroundcontrol.
I had some more success today tuning the steering rate controller. I had to use the work around that I mentioned above to modify the ATC_STR_RAT_FF in QGround Control then switching to MP to monitor the result until I got something acceptable.
Currently using 1.35 as the value with a tiny pinch of I.
I did this test indoors under a GPS repeater. I’m assuming the actual turn rate value is calculated by looking at the compass read out ?
I will test again outside when I get the chance.
Randy, Do you know what could cause the jagged signals on the steering rate? IS GPS used to calculate steering rate?
I tried playing with the NAV1 params
lowering the Nav1 period resulted in the rover weaving at a faster frequency as it traversed from Waypoint to waypoint. Increasing the Nav1 period resulted in lowering the weaving frequency. but it also meant that the rover deviated from the path with a larger amplitude. So to summarise
lower Nav1 period = higher oscillation freq, but the rover’s position is closer to the path
higher Nav1 period = lower oscillation freq, but the position’s position deviated alot more from the path.
I played around with the Nav1 period to make it go all the way up to 50.
my current turn max g is 0.2 but I think it needs to be more like 0.02 …is this possible in ardurover ?
Sorry, I missed your message. I’ve been checking the Rover-3.2 forum but forgot about this one.
I’ve just tested the latest beta Mission Planner and it looks like MichaelOborne has updated it to include the FF with new ranges. I should add though, that even before updating to the latest beta, I’ve successfully set the ATC_STR_RAT_FF to large numbers using the MP’s full parameter tree page which doesn’t do any range checking.
Re the jagged turn-rate. The actual turning rate (i…e STER.TurnRate) comes from the EKF which uses a combination of gyros and the compass (No GPS required). It might help to set ATC_STR_RAT_D to zero although I don’t think the controllers are the cause of the jagged response. I suspect it’s in the frame somehow.
It looks like the 2nd log (16.BIN) is from an Octa-quad but 100.BIN is from a rover so I’ve had a quick look at that log… no navigation in this earlier log though so I can’t comment much about the large desired lateral acceleration you’re seeing. If you’ve got another log I can have a peek.
Is ACRO_TURN_RATE used in AUTO mode? does it limit TURN RATE in AUTO mode? It seems not in rc3.
So, TURN_MAX_G is used in PIVOT TURN? Lowering this parameter we could decrease PIVOT TURNS SPEED?
ACRO_TURN_RATE is not used in Auto mode, only in ACRO mode. I have a patch that adds a parameter to set the vehicle’s maximum turn rate but it needs more testing so I did not include it in Rover-3.2.
Yes, TURN_MAX_G is used during pivot turns in Steering, Auto, RTL, SmartRTL and Guided modes. Reducing this should reduce the aggressiveness of pivot turns.
For 3.3 I hope to improve the way pivot turns work. The current method is quite rough really.
Sorry, you’re right, I was looking at the wrong log somehow.
In this 106.BIN log, the turn-rate control looks quite good except for the pivot turns which are, as mentioned above and in a few other places, not great because of the ham fisted way we do the pivots. The current method jams the TURN_MAX_G value into the controllers which often leads to overshoot.
You could try turning off the pivot turns (set PIVOT_TURN_ANGLE to zero) and then tune it as best you can and then re-enable the pivot turns. At some point we will improve the pivot control but I can’t make a promise of exactly when that will happen.
Reducing the TURN_MAX_G value to 0.02 should also be possible and might help a bit.
Is there a way I can fine tune the EKF params so that it is better suited to the Reach RTK GPS I am using?
I’m assuming the current param are tailored towards standard GPS.
Eventually, I want to blend the onboard GPS on the Navio board with the Reach RTK GPS but first I would like to tune the EKF to get a good position solution with the RTK GPS. What params can I tweak?
If I get a good RTK fix I would like the EKF to put more weighting on the GPS positions.
I’m assuming blending the 2 GPSs (NEO-M8N (Navio2 - standard GPS) and the NEO-M8T (Reach RTK) ) will not be a problem?
Do you mean tuning the NAV1 params in auto mode with pivot turn off or something else?
Yes. I think this could be a good idea in this situation to separate the known issues with the pivot turns (which we cannot fix without code changes) and tuning the vehicle. I.e. pivots turns are messy, let’s turn those off and get the vehicle tuned as best as we can.
Re EKF tuning, in general it’s not needed. Even for cases of using RTK GPSs I’ve never heard that re-tuning the EKF is necessary. We have some information on our EKF page here. I’m not the EKF expert but it seems like modifying the _NSE parameters changes the weighting between sensors.
The problem with not pivot turn is that, in my case, I could get 1m/sec top speed with my ASV. So I use 0.5m/seg as cruise speed, that gives a little power to make turns. So, there is no way to make a turn with a little radius. Going forward and turn at the same time need a lot of space. The river where I test, measure 10mts from coast to coast, my ASV can’t make a 180º turn in that space. The only solution I think of is lowering cruise speed. But there is a river flow I need to beat… pivot turn is a must for this kind of robots, I think.
I will try it next week and will see what happens
I was not able to set the turn_max_g setting to 0.02 and getting the result that I want.
there are 2 issues.
MP does not allow me to set any value less than 0.2.
I tried the Qgroundcontrol trick as I have done previously. When I set the value to 0.02 it gave a warning . but proceeded to make the change anyways. I switched back to MP to confrim that 0.02 was the new turn max g setting .
When I ran the mission i noticed that now the commanded lateral acceleration is ± 10 instead of ±2 …did this mean that the controller had assumed the turn max g was set to 0 instead of 0.02?
Can you confirm if this is a bug?
Also tried turning off the pivot turn but didn’t spend too much time on it … the course location where I was doing the testing was too small and the platform was too large for me to get any sensible result as the platform was overcorrecting at every turn. Need to find a large space to test this.
