This forum uses cookies
This forum makes use of cookies to store your login information if you are registered, and your last visit if you are not. Cookies are small text documents stored on your computer; the cookies set by this forum can only be used on this website and pose no security risk. Cookies on this forum also track the specific topics you have read and when you last read them. Please confirm whether you accept or reject these cookies being set.

A cookie will be stored in your browser regardless of choice to prevent you being asked this question again. You will be able to change your cookie settings at any time using the link in the footer.

Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
PyPilot doing remarkably well on long trip
#1
Just sharing some experiences.

Had a long sail this weekend with a pypilot almost 100% working to satisfaction! As a reminder, this is a raymarine tiller pilot conversion, with tinypilot on pizero/w and motorcontroller built into the tiller pilot casing, and a home-grown UI built under the original buttons; 28 feet steel monohull.

Previous experiences had me busy with the self-built motor electronics and electrical connectors failing me. Having sorted that, I had some problems with the pypilot only sometimes suddenly veering off to the opposite side, although I had the polarity sorted out all right. It turned out that I had the max_current set too low, so it was stuck in fwd_fault and could not get out of that situation until having done a 360 the wrong way around. With the main about to gybe within seconds and the situation only occurring occasionally, this took me some time to defuse. I have now increased the max_current, changed 'fwd_fault' to 'port_fault', and 'rev_fault' to 'stbd_fault', and have my UI signal an overcurrent situation with a persistent alarm beep. However, as I've relied so far on overcurrent to detect end-of-travel, it now seems to be time to go finicking again to get end-of-travel switches finally installed, otherwise I'll wreck my lineair actuator at some point.

Finding the right gains was still a daunting task. For now, I have only used the 'basic' pilot. I found it easiest to set all parameters first to zero except for the P, tune P for quick response, then increase D to dampen the swing and then increase P a bit more to keep the response up. I settled on P=0.0086, D=0.085 this time. Next time I'll do the same process with PR, to see how that goes. 

This should be done after recalibrating the compass, because with the IMU built into the tiller pilot, that hangs back and down when disengaged, and pypilot automatically calibrating the compass, you could wind up with a totally messed up calibration when you swing the tiller pilot into place. Only in that position should the tiller pilot calibrate. For now I keep the calibration locked - and I am happy with that feature! Recalibrating is only one 360 away I have found, so it's not a biggy if you don't have your sails up yet.

Then, both compass and gps mode worked like a charm. At first I was skeptical about the default gps (track) mechanism being based on RMB/XTE with only one P-parameter (in the latest image called apb.xte.gain). However this seems more than enough to keep on track in the circumstances I was in. This was 3-4 Bft, and I've seen close hauled, beam reach and broad reach, the latter both with gull-winged genoa and with spinnaker. Also on the motor, doing up the sails for instance, the compass mode works just fine. I must say the waves were benign. But all-and-all, that's a pretty good basis to go by investigating and optimising further!

I had tweaked my nmea.py a bit to provide audible alarms at waypoint arrivals, that must be confirmed before heading is changed. But I had no audible alarms yet when the route runs out! This happened once or twice, but it won't happen three times, so I'm back to tweaking a bit more.

There are a couple of things I don't understand yet, but I'm planning to rig up some signalk monitor script to figure that out first, as it might as well be caused by my own wrongdoing.

I have checked the signalk scope plots of heading_error_int in relation to heading_error, but the value increases too slowly so I will refrain from using the I-parameter for now. If I understand correctly, the I-gain is only needed when the boat cannot reach a certain heading after trying for some time, and that is only the case when the sails are not properly trimmed. I'd rather not have my autopilot try to fix that problem for me. I had earlier made an error to think it would require the I-gain to counter cross-currents. But that's not this I-gain. On the sail I did have current across a few times, but then I was on gps mode so the crosstrack error was kept properly in bounds by the abovementioned XTE mechanism. Still, I can envision that at some point there might be a apb.xte.I.gain see the light.

Wind mode I've have tried only briefly with the actuator disconnected, but I could not explain the sudden steering move so I decided to leave it for another time.

Anyway thanks for reading, hope someone picked up something useful from it.
Reply
#2
Some more experienes with the pypilot. Enjoy. https://photos.app.goo.gl/44FFppxgPuZgV5T96
Reply
#3
Thanks for sharing and
save sailing
Andreas
Reply
#4
Fantastic adventures,

Safe Journeys.
Reply
#5
Thanks for the feedback.

Yes, some rams are really bad with overcurrent only since they can get stuck. That's why pypilot increases the max_current past what you set it too for the other direction to hopefully "unstuck" the ram when it is in this fault state. Of course end of travel switches or rudder feedback completely avoids this issue. You could also maybe put springs or padding to help soften the end stops which may or may not help.

As for the 'I' gain, yes I realize it's not very effective. It doesn't reset the integrator when making course changes, and it probably should. The current potential of the I gain is limited to what it is because it will be all wound up after you tack. The real purpose of this gain for example, if you are following a route, but the track ends up parallel to the route rather than on top of it, the I gain corrects for this.

As for audible alarm at waypoint changes. I generally do this from opencpn rather than the autopilot. The autopilot route plugin is meant to also support confirming waypoints. Also this plugin supports "route position bearing" mode which is a big improvement over the xte (nested control loops) which is inherently less accurate especially if the route has a significant turn at a waypoint, say 60 degrees or more.
Reply
#6
That first post was from november 2019. I have since implemented end of travel switches and waypoint alarms in ray.py.. I just added a youtube movie yesterday to the thread. I would love to use the autopilot route plugin but i have found some issues (see github). Sorry for the confusion; now I realise why posting in old threads is not always a good idea.
Reply
#7
oops... sorry I forgot to read the date
Reply
#8
(2021-04-16, 08:23 AM)ironman Wrote: Some more experienes with the pypilot. Enjoy. https://photos.app.goo.gl/44FFppxgPuZgV5T96

Hi Ironmam
can you share the gain and servo settings you use while the video ? Or mayby show you pyipilot.conf file.

Thanks
Andreas
Reply
#9
Yes currently p=0.00050, d=0.025 under sail, when I put the engine on I set dd=0.025 otherwise 0. ff=1.0
Reply
#10
(2021-04-18, 11:32 PM)ironman Wrote: Yes currently p=0.00050, d=0.025 under sail, when I put the engine on I set dd=0.025 otherwise 0. ff=1.0

Thanks a lot, 
I will compare to mine. You tiller moves nice, fast and smooth in the video :-)

I assume that your servo-gain=1 and servo-period=0,4 are unchanged ?
Save sailing
Andreas
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)