Hi John,
Do you have a DF log I could look at? Maybe we can try setting the deceleration to be really slow so that does what you describe - i…e come off the throttle really early.
I want to get the sailboat support into master (we’re almost there) and then I’ll come back to have another look at the vectored thrust stuff… maybe I can think up a few tests as well so we can verify that the boat behaves as we expect… maybe our model of vectored thrust is not actually a good match.
Hope you get it figured out. Again, nice job building the boat.
Will do Randy, let me know when you are ready.
@Fishton, what are your navigation parameters - L1_PERIOD, L1_DAMPING, WP_RADIUS, WP_OVERSHOOT and your turning circle?
See Randy’s recommendations above, that is what I am using.
OK, so:
NAVL1_PERIOD: 8
NAVL!_DAMPING: 0.9
WP_RADIUS: 10
NAVL1_XTRACK_I: 0.02
WP_OVERSHOOT: 1
ATC_STEER_FF: 0.8
So here’s my theory:
Your combination of L1 period and low forward speed give you a look-ahead distance of only 6.5m (at 3m/s). If the boat gets even a little off-track, it’s trying to turn back on track quite quickly.
How quickly is determined by the damping - you’re actually commanding more than your TURN_MAX_G in desired lateral acceleration because your damping is so high.
The other odd thing I noticed is how low your FF gain is - by my reckoning and experience, FF should be your turning circle, so it your case I’d estimate 10. Throughout the whole mission you’re getting low amplitude oscillations in the steering. I’m not 100% confident on this though, because you’re basically maxing your steering during the oscillations so I can’t see how MORE gain would help.
I would increase your L1_PERIOD to something around 15, and drop the damping to about 0.75 or even lower. This will increase how far it looks ahead and will make it turn back onto path more gently - hopefully more consistent with its performance.
Do you have the ability to test locally? What will exercise this is starting the mission with the boat at 45 or more degrees to the mission path - that will introduce and initial error that it will have to correct. Try that with your current settings and see if you can reproduce the weave.
The L1 parameter maths is all here - http://ardupilot.org/dev/docs/rover-L1.html - but the guts of it is this:
I’m a bit worries about your steering PID values. Have you tested it in ACRO mode (just make sure you drop the ACRO_TURN_RATE to something that’s achievable (like 20 or 30 degrees / second) for testing otherwise you’ll go mad.
Sorry if this is ground you’ve already covered with Randy.
Thank you for the time and effort you put into your reply mroberts.
It was good to read through the Li Navigation documentation again.
In the latest testing it appears the craft is doing very well most of the time while on track between waypoints, especially when they are far apart.
The problem comes in when the craft hits the waypoint then overshoots it horribly, then it’s like a game of catchup trying to get back on track correcting oversteer, but once it is back on track all is good, until it hits the next waypoint and it all starts again.
Here is an example of the flight plan in yellow and the actual trail achieved by the craft, the biggest thing to notice is that the turning circle of the craft is 25m radius / 50m diameter.
This causes the biggest problem on right or acute angle course changes.
If one to actually drive the planned route as a human, you would use one of the following options -
JohnE, if you have a log file for this test I’d really like to see it…
Hi Randy
Here is the link … https://www.dropbox.com/s/5s2iah0u2utu7ko/00000223.BIN?dl=0
@Fishton, increasing the L1 period will smooth out that oscillation - it will try to turn back onto path more gently. I think you will see a big improvement if you increase it to 15 or more.
You can get a path more like your option B by increasing your waypoint radius - the vehicle will switch to track the next waypoint once it gets to the waypoint radius. It works well for angles up to 90 degrees, but for your ends where you double back you will probably have to manually “round off” the corner. You can probably also program in option A, but it might take some trial and error - SITL would be your friend there.
Setting WP_RADIUS to your turn radius is a good rule of thumb to be able to negotiate a 90 degree corner without overshooting. That relies, however, on your runs being spaced by your turning diameter.
Have you considered “skipping” a lane on your mission plan so that you’re not turning so tightly, then going back and picking them up on the way back? Given your turning radius, the course you currently have is always going to be problematic.
That is a VERY valid point mroberts, the craft is not capable of making that turn to the next lane!
Unfortunately my sidescan mosaics have to be max 25m apart, which is half my turning circle, so I need to create two missions for each area, that is going to be tricky with ‘Corridor’ planning.
Thank for pointing that out.
Regards
John
John,
I want to help here and I’ve been noticing that you’ve been having trouble. I fly planes mostly, but I looked at your recent logs and I have some ideas. The first important concept is that there are steering and navigation controllers. Without getting good steering, it won’t matter what your navigation controller demands because your boat won’t be able to follow it. I think we’re mainly concerned with the steering control here.
The first thing I looked at was your desired and achieved yaw. They are not quite aligning as well as they could be. They also overshoot sometimes, indicating problems.
Here’s a comparatively well tuned aircraft roll graph from one of my flights. It rarely overshoots, and it moves quickly to the desired angle.
The red line on the graph of your craft is showing that the navigation controller is demanding a 270 (westbound) track and then swinging back to a 180 (southbound) track before settling on a 220 (southwestbound track). The craft is slow to achieve these headings, and often it is overshooting them. It’s actually a bit of an oscillation.
To understand why it is overshooting them, I looked at your servo 1 output. It was showing values far from trim at the moment that the desired and actual yaw met. Normally when your craft is straight, I see a consistent 1500 pwm output, and that is excellent. Here however, the PWM was about 1800 when it should have been 1500.
To see why the motor is still turned when the actual and desired yaw are equal, I looked at your PID.S graphs. It’s obvious that you have I-term buildup that is causing the servo motor to be far too sluggish to do the right thing.
As a reference, here is my aircraft’s roll PID chart that gives you an example of how PID’s should be. The I-term remains pretty constant because my aircraft isn’t very well in trim, but the P-value dominates when there are large roll errors (changes).
#1 recommendation: Turn down your ATC_STR_RAT_I gain. Try 0.05 instead of 0.5. This should help with the overshoot in the path just after turns.
#2 recommendation: Turn down your ATC_STR_RAT_IMAX to 0.15 instead of 1. It is obvious that your boat is fairly well in trim (better than 15% of the steering throw). This will also help prevent That I-term buildup
#3 recommendation: Turn up your TURN_MAX_G. Try .7 instead of .1. That will decrease the chance that the navigation controller is suppressed by this parameter. It’s likely that your boat can handle fairly high acceleration turns well because of its side floats and thrust that is below the waterline. Boats typically can achieve quite high acceleration turns.
#4 recommendation: Turn your NAVL1_DAMPING back down to 0.7. Having that high may cause oscillations as well, but it’s hard to tell until you get your steering to hit the desired
#5 recommendation: Turn up your ATC_STR_RAT_P value to 1.4 instead of 1.0. This should help your motor turn tighter. It is currently not maxing out when I look at the CH1 output graph. The PID values should be dominated by P-gain as shown in my roll graph above. The P-gain should do the work of turning the motor when the heading is not as desired.
#6 recommendation: Turn down ATC_STR_RAT_FILT a bit. Maybe try 1 instead of 5. I don’t know exactly how this affects the outputs, but be cautious when testing this.
AFTER you run a few test missions, and see that your desired and actual yaw are matching up well (after turns) then play with NAV_L1_PERIOD. Note that immediately after a waypoint is finished, the yaw demand will be a lot and the boat obviously can’t whip around immediately. You should, however, see your steering servo nearly max out until it achieves that desired heading. Note that the desired heading is usually up to 45 degrees from the waypoint path. It will rarely approach the new run at a steeper angle.
Thanks for the analysis Nate,
One thing though is I don’t agree with the advice for #5 (Turn up ATC_STR_RAT_P). In rover the PID values should be dominated by the feed forward, not by the P gain. The P and I values should always be lower than the FF gain.
Randy,
I agree if your rover has positive traction. Boats, however, do not. I think either method might be effective, but in my opinion, more weighting on the PIDs would be more applicable here. Just an opinion, and we’ll see what works!
-Nathan
The other thing I noticed was that the FF Gain may also be causing an issue. It continues to hold some FF gain even after the target yaw has been met. That seems very odd and problematic.
And now after looking at the STER data, I understand where FF gain is coming into this mix. It’s coming from the desired lateral acceleration (Currently 1 m/s).
The I-term buildup is because the FF gain is not high enough. The desired turn rate is not being met due to the FF gain not being high enough. So increase your ATC_STR_RAT_FF. Increase it by 35%
Nate,
The L1 controller’s output is a lateral acceleration in both plane and rover so that’s what we use. It’s converted into a desired turn rate (which is a pretty simple calc using the vehicle’s velocity) and then passed into the turn rate controller. Rover also has a heading controller which is a simple P controller which converts the heading error into a desired turn rate which is passed down into the turn rate controller… but that’s not used in Auto. It’s used during pivot turns on skid-steering vehicles though.
Hi Nathan,
Thank you so much for your input here, I get so excited to receive such valuable information and I am aware of the time and effort that goes into a reply such as yours, for this I am very grateful.
As time goes on I am starting to realise more and more how unique my craft is from a steering perspective and how hard the poor navigation controller is having to work. i.e. Trying to get the controller to achieve something that the craft itself is not capable of.
While my trim might be pretty close to spot on, I need to get to the bottom of why my starboard turning circle is 40m and port 30m, and how to get them to be both 35m for example. i.e. compensating for the screw of the propeller.
Unfortunately the steering is sluggish as the servo is turning the entire outboard motor which weighs nearly 18kg plus the friction on the steering column. I have tried the ‘fixed motor and rudder’ thing and unfortunately does not work on this hull design as it opens a whole new can of worms.
From Randy’s side, I think if the controller somehow knew what the upcoming Angle of Attack (acute, right, obtuse) was to the next waypoint and corrected the speed accordingly, not only in throttle, but time leading up to the waypoint allowing the craft to slow down in time and REMAIN slow until it is back on track, then increase the throttle back up to WAYPOINT_SPEED.
Yeah. Sorry about the confusion. I see what is going on now. For planes, bank is directly related to lateral acceleration, so that makes sense.
That should be done using Servo1_min and servo1_max. If your turns are tighter in one direction, either increase the servo travel range in the opposite direction, or reduce the range in the direction that is so tight.
