Entry - vehicle is on a beam reach so may tack or gybe at the WP depending on the true wind direction at the decision point. In this case it tacks.
Tack - there is sufficient speed to execute the tack.
Exit tack - post tack the vehicle bears away onto the heading for the new WP
Luff - instead of continuing to bear away to the rhumb line between the waypoints the vehicle luffs
Bear away - the vehicle slows and then bears away to to the rhumb line
Exit - the vehicle is now in trim for the next leg and on the rhumb line
The behaviour that is confusing me is at 4. the luff after the tack. There is no major change in the apparent wind that would indicate a sensor issue. The sign of the true wind changes (because it is reading [-180, 180] and the wind is from nearly due south.
The bear away to the rhumb line is expected L1 controller behaviour - while the vehicle could head directly to the WP, the L1 controller pulls it back to the line connecting the WPs. it’s not the most efficient course but that’s not the issue here.
I would expect the vehicle at 3. to continue to bear away instead of luffing. At the end of the same log there is a set of data in manual mode for upwind performance. From that I estimate that the no-go angle should be closer to 70 - 75 deg for this vehicle rather than the 55 deg I had configured during the field test. I am not sure whether this is the cause of the issue or not (not convinced that it would be on a beam reach leg). I have not yet had a chance to rerun with new parameters on the vehicle and don’t have the sail stall characteristics configured in gazebo to replicate this behaviour in simulation - that might be the next step.
Just a thought: if the turn rate out of a tack was greater than the ACRO_TURN_RATE (or one of the other limits), would the controller attempt to counter steer to reduce the turn rate - even if that meant initiating a tack?
My guess is that the true wind changes enough that it thinks it should be tacking. Once you hit the tacking threshold it doesn’t consider the target location it just holds a constant angle to the true wind. I guess it thought it had met the threshold but once it had gone straight for a bit the true wind came back it carried on.
There are a few things that could cause this. Some lag in the wind direction readings, or a error in the EKF yaw estimate. Because its all based on the true wind its a combination of the estimated vehicle heading and the apparent wind direction from the windvane. Its reasonably likely the EKF got a bit confused during the high rate turn, you could plot the GPS heading, mag heading and EKFs. I have seen that a metal boom shooting over top of the compass can cause errors. There is only about 2cm clerance on the mini 40.
Things to try would be compass cal ( or the MAVPoxy magfit ) or lowering the filter frequency for wind direction.
Yeah it would do this, I don’t think it would be so dramatic tho.
I think we should add a flag to the SAIL log to show if were using the L1 controller or heading control for upwind.
I think I can rule out the ACRO_TURN_RATE. The param is set to 90 and during the the tack it never exceeds 65 deg/s.
I’ve been running with the wind speed and direction filtering off on AP as the CV7 has on-board filters. There is not an (easy) option to adjust the filter frequency on the sensor or extract the raw data.
Might be time to play with the MAVExplorer tools now as you suggest! I think it’s time to learn how to use the replay tool in MAVProxy…
The CV7 filters might not be helping, in AP we filter the true wind angle, so its still correct no mater your heading. It can only filter the apparent wind angle so fast turns result in a lag as the filter catches up with the change.
You could be right. The CV7 can be reprogrammed with different filter periods (Setup CV7, ultrasonic wind sensor), but the shortest (and default) period is 2s. That may be significant for a fast moving vehicle.
To try and replicate this in simulation I’ll need to complete the wind sensor integration for Gazebo to which I can add filtering. I’ll also ask LCJ Capteurs if filtering can be disabled completely on the CV7. How does this compare to other commercial sensors (thinking of the Calypso and your mini-40)?
Just a thought. Is it so that the vehicle is heeling up on two wheels just before point 3 and due to the triangular shape the yaw angle is changing fast which makes the steering to compensate.
At the university where I work, I have had a few student groups build ardupilot-based sailboats in the last couple of years. I started modifying an old RC sailboat of my own so I can better understand the process too.
In order to support my students (especially since we’re remote this year) I’ve started writing up parts of the build. I thought I’d post these here too, I’m interested in your feedback.
@iampete I’ve got the wing sail version of the land yacht pretty well tuned in simulation now. The gains for the heel controller need to be larger compared to those used on a conventional sail. The steering controller also turns out to be critical at high speed when on the wind with one wheel lifted - if not properly damped the steering starts to oscillate as the upwind wheel lifts which causes then causes the heel controller to become unstable.
MOT_SPD_SCA_BASE is needed at higher speeds with the wing - with this kicking in at about 5 m/s the vehicle is stable in a straight line and through gybes at winds up to 10 m/s with the full rig (apparent wind is around 20 m/s on some points).
The remaining issue is high speed tacks, here the centripetal force and wing lift are both contributing and the heel controller is not able to prevent the vehicle capsizing through tacks in winds over 5.5 m/s. I’ve decreased the PIVOT_TURN_RATE to widen the tack radius which does increase the upper wind range a little, but really something dynamic is needed.
I was wondering whether we could add a lateral acceleration limiter into the wing elevator controller - so the rig is de-powered if the acceleration exceeds a threshold.
You can see in the tuning plot that the elevator is centred by the heel controller but the vehicle is already past the point of no return. The lateral acceleration is apparent earlier and if the elevator was centred (or even given reverse lift!) at that point the vehicle would not capsize.
I think the code should power the wind back the other way to try and right the vehicle, if your PIDs are big enough. Yeah I think a turn G-force limit is the way to go. We should be able to calculate the G force from the speed and turn radius and get the turn radius from the steering geom, I guess. Or we could close the loop using feedback form the IMU, might be too late at that point tho.
It seems to work in that the vehicle can now enter a tack on two wheels and at higher wind speed. The TURN_G_MAX has to be quite low (0.2) and I still get the occasional capsize. Think we may still need elevator control as well so will look into setting up a PID controller with two PV inputs.
Might be useful for your mini-40 so you can do foiling tacks!
At the moment the PID offset is constrained to [0, 100] so the most the controller can do is bring the elevator back to centre. I might see if this can be changed without breaking anything to see the effect of reversing the elevator.
Nice, looks good. I think its worth moving it up and applying it to all rovers, will be useful for all think. Also as it is you only get it when in ‘tacking’ mode. So it won’t help for gybes, or the last tack into a waypoint.
You could remove the constrain from the PID and constrain on the input to the mainsail, so you sill have the full value for the wing sail.
Driving the wing elevator through zero deflection turns out to be a little trickier.
Here’s the problem: at the moment when the sail tacks the sign of wingsail_out is switched. This is mostly what we want with a wing sail - the sail is set to the same abs. deflection on the new tack as the previous one with the AOA of the main wing reversed.
However when the sail is driven in ‘reverse’ (i.e. lift directed to the windward side of the vehicle) the tack switches the direction of the elevator and we get a sudden shift of the lift back to the old leeward side of the vehicle as it passes head to wind. If the lift was providing a restoring force to counter centripetal acceleration this suddenly increases the force directed away from the turn centre and capsizes the vehicle.
What I think should happen is that if the elevator is driven in reverse, its position remains continuous through the tack, and the PID controller subsequently pulls it back past zero onto the ‘correct’ side once the lateral acceleration loads have subsided.
I have moved the wing sail to use the PID to sheet in, rather than only to sheet out. It now targets the roll limit depending on tack. I suspect you will need higher PIDs, you can them limit the reversing speed with ATC_SAIL_FLTT.
I have not tested at all, there is a high likelihood that it is does not work at all or the output is backwards.
@iampete thanks! - was in the process of doing a similar thing - giving the wing it’s own controller, but you got there before me. I’ll run it up and see how it behaves.
) or lowering the filter frequency for wind direction.
