Hi Yuri, I agree 100% with this statement.
However, it is important to note that while the “first time drive and setup” works perfectly for our small electric bait boat craft, it is nowhere near the case when it comes to our 3,2m and 4,2m craft.
Hey Randy,
The actual turn rate is actually half of the the desired turn rate (if I’m reading it right), and if I bring it up any higher the rudder servo tries to rip the motor off the boat.
1 Like
Hi @John_Easton,
I’m sorry, you’re right that I got the two backwards.
Ok, so if we can’t increase the actual turn rate, then we need to reduce the desired turn rate. This means the cornering needs to be more gentle or the vehicle needs to slow down more in the corners.
To make the path smoother we could try this:
- reduce WP_ACCEL from 1 (m/s/s) to 0.5 or even lower. The downside is that we cannot set the desired acceleration for forward-back separate from left-right meaning that the vehicle will take longer to get up to top speed.
- increase TURN_RADIUS from 10 to maybe 15
To put a hard limit on what the lower level turn rate controller will attempt we could try this:
- reduce ATC_STR_ACC_MAX from 120 (deg/sec/sec) to perhaps 40. This should slow down how quickly the steering servo moves
- reduce ATC_STR_RAT_MAX from 120 (deg/sec) to perhaps 20 or even 10. This will reduce the maximum turn rate that the vehicle will ever attempt
The problem though with putting low limits on the low level turn rate controller is we can end up in a situation where it is so constrained that it can’t do what the upper level navigation is asking it to do and we end up with the vehicle driving in loops and other weird behaviour.
1 Like
Thank you Randy, I can’t wait to get back on the water and try these settings.
Just a note, I know this topic is all about the cornering, but for me, step one is to get the boat going dead straight wpt to wpt first.
Any ideas on this?
@John_Easton, I disagree that the first drive guide doesn’t work somewhat universally. Most of the problems you’re having are related to basic tuning. For example, the steering guide drives you to first establish an ATC_STR_RAT_FF value, which was obviously way too high in your case.
Which leads to my response to your most recent question regarding path following. You MUST tune the steering controller in order to have precise straight line path following. The control loops work as a system, not individually.
The path wandering you’re seeing is probably a combination of the too-large ATC_STR_RAT_FF term coupled with overly aggressive acceleration expectations. To dampen the oscillation, we must tame the steering controller, which will also, implicitly improve cornering.
Additionally, I think it is perfectly on-topic to discuss navigation performance as a whole rather than just cornering here. The S-Curve update replaced the navigation controller entirely, and it can only help the community to identify struggles and successes while tuning it.
2 Likes
Agree with back-to-basics on the turn rate controller. However, intuitively it would seem to me that, on a boat, the turn rate achieved by a certain rudder deflection would be a function of the boat’s speed through the water? So that the ATC_STR_RAT_FF value could be derived for a certain speed (through the water) but might not be valid for a different speed. Curious to know @John_Easton thoughts on this.
I agree that this could be problematic, and I’ve even experimented with dynamic tuning to account for such idiosyncrasies (using Lua scripting).
Randy has extensive experience with boats, so his insight is also invaluable on the subject.
@Christopher_Milner, @Yuri_Rage,
Re the change in response based on the speed through the water, we have a similar issue for Ackermann steering cars and we handle this by scaling the output to the rudder based on the vehicle speed. Boats due the same (it’s the same code) which works as long as the water speed and the vehicle speed are similar.
As a side note, linearising inputs and outputs to a PID controller is one of the first things we can/should do to improve its performance. This is why in we have motor thrust scaling and why Copters have battery voltage compensation (boats should eventually get this as well). This is also why electric motors tend to work better than gas motors.
PID controllers can handle non-linear systems mostly though via their I-term.
1 Like
Thank you for the explanation. My experiments have mostly been with hydrostatic controls where engine RPM (more accurately, pump pressure/volume) is an external factor that greatly impacts control response in a way that is unpredictable with respect to pure speed scaling.
1 Like
Chris you are 100% correct. The speed, weight/COG and weather conditions play a huge roll in how the boat steers/performs. Not many will realise this as they have never had those kind of challenges. I was hoping that after 7 years of doing this I would have learned a basic correction guide, but unfortunately I have not. I have got my smaller 3.1m craft pretty much dialled in on Rover 4.2 as long as the speed is set at no more, or less than 3.5m/s and the weather isn’t too rough. By the end of day I notice a difference in her steering as the 13 litre gas tank (mounted in the bow) is just about empty.
The other issue on Rover 4.3 is repeatability - one day she is going ‘pretty’ good, and the next she is like a drunken sailor on a scooter - same fuel, ballast, speed, weather conditions.
I suspect your perceived repeatability issues are caused by the large PID terms. When a PID controller is operating on gains that are set too high, it is particularly sensitive to disturbance. It can appear to be under control/behaving well while error remains low, but as soon as there is a spike in error (such as an accel/gyro input from a disturbance like a ripple from a wake), the high gains set up an oscillation that can appear to be random and/or wild. Despite perceived identical conditions, it doesn’t take much of a disturbance to set up an ugly oscillation with a PID controller in the state I describe here.
The previous NAVL1 controller could be forced to dampen such oscillations rather easily, and I fell into the trap of tuning NAVL1 parameters that way more than once (lengthening the period and increasing the damping term while failing to fully tune the lower level rate controllers better, thus masking some of the underlying issues).
In my experience so far with the position controller used in 4.3, it is more difficult to dampen control loop oscillation with the navigation (PSC) parameters alone, meaning that the throttle and especially the steering rate controllers must be dialed in very tightly to achieve good performance overall.
The last time Randy and I did a live setup, if I remember correctly -
PID was set to zero and the FF was increased until the desired met the achieved and then the P and I were brought up to around 30% of the P & I values and that got it pretty much spot on, except for the repeatability issue.
1 Like
FF still feeds the same controller and can result in oscillation all the same.
@rmackay9 could you take a look at this logfile? It seems that the EKF3 position is quite far off from the GPS2 position (GPS2 is positioned at x=0 and y=0 on the vehicle; GPS1 at x=1.15 meters) during the slalom from waypoints 6->7->8->9. My questions are (a) do you agree that the EKF3 position varies from GPS2 and (b) do you think this will hinder S-curve navigation in any way?
(cc @Yuri_Rage this is the issue you and I discussed)
1 Like
So are you saying the way Randy and I did the setup live was not correct?
No. Your most recent log shows large overshoots in steering rate. That’s what I’m referencing…although it seems maybe I missed some follow on discussion that shows the opposite is true.
But the achieved steering is only 50% of desired so its definitely not overshooting
I see that now. I apologize for somehow skipping ahead in the conversation without analyzing the logs myself.
Still, the large error between the output and set point can easily account for the perceived inconsistency, and I see now that the post I missed from Randy has some excellent advice on correcting it.
1 Like
I look forward to testing those settings for sure.
2 Likes
I’m not sure if the cause of the issue is the GPS or not but the two EKF lanes are producing quite different velocities. There is a moment in the log where the active EKF lane is changed and this leads to a sudden just in the velocity which I imagine would have been visible if the vehicle was moving.
2 Likes