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.
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.