Follow on tiller / power steering control

[matze]

Has anybody built a virtual tiller / follow on tiller with pypilot. So you can steer the boat manually using a potentiometer.

(I mean is something like this: https://www.raymarine.com/en-us/our-prod...ontrollers)

[seandepagnier]

I am working on supporting configurable analog inputs into the pypilot hat. The hardware already supports it, so it will be possible to run potentiometers, or hall sensors for this type of thing. Will require calibrating the potentiometer.

Alternately an esp32 could do this, but with a wireless link could have more lag (even though it uses UDP to reduce lag) I will have to try and find out.

[nousian]

I am working on supporting configurable analog inputs into the pypilot hat.  The hardware already supports it, so it will be possible to run potentiometers, or hall sensors for this type of thing.  Will require calibrating the potentiometer.

Alternately an esp32 could do this, but with a wireless link could have more lag (even though it uses UDP to reduce lag)  I will have to try and find out.

Any update on this? This would be super useful for both everyday use and for emergency steering as well. I don't think lag matters here that much, as normally it is only used as secondary steering.

I am currently in a process of replacing my failed Simrad AP computer, and with this I could get rid of that altogether, as one of my steering positions only has FU steering option.

[nousian]

I am working on supporting configurable analog inputs into the pypilot hat.  The hardware already supports it, so it will be possible to run potentiometers, or hall sensors for this type of thing.  Will require calibrating the potentiometer.

Alternately an esp32 could do this, but with a wireless link could have more lag (even though it uses UDP to reduce lag)  I will have to try and find out.

And speaking of FU-mode, I think also NFU with say pushbuttons would be very handy as well, in emergency. 

I have it currently this wired direct locally to my AP steering pump, but would be nicer to have it though the autopilot and available remotely.

[seandepagnier]

Are you inquiring about analog inputs? Right now the pypilot hat is capable of several analog inputs which would be intended for manual control or throttle input, it is just not yet finalized/implemented. This wont happen until I am able to integrate multiple motor controller support as well as other features, so it could be a while.

[nousian]

Are you inquiring about analog inputs?    Right now the pypilot hat is capable of several analog inputs which would be intended for manual control or throttle input, it is just not yet finalized/implemented.    This wont happen until I am able to integrate multiple motor controller support as well as other features, so it could be a while.

I would more be interested in FU / NFU mode itself - the analog inputs of course could be nice and useful feature, but personally I would not use them as my control station is situated far away from the pilot and outside - and if using a wireless remote this is no go anyway.

I currently have a NMEA 2000 FU lever and an ESP32 reading it via the NMEA 2000 bus. For my use case it would be sufficient if I could send a "magic" UDP / TCP command from ESP32 to pypilot to directly control the rudder. Something along the lines pypilot_client does, but modified like this, and preferably sent direct from esp32 - I don't mind though if this has to go via some other hop, if necessary:

ap.mode = follow_up
ap.enabled = True
ap.rudder_command = - 15.5

or

ap.mode = non_follow_up
ap.enabled = True
ap.rudder_command = - 2.5

In fact, I can already do this by controlling the solenoids of my bigger constant running steering pump from ESP32 and GPIO, but would be nice and I think super useful in general to be able to do this though pypilot, so I could also use it with my smaller and less power consuming secondary reversible autopilot pump hooked to pypilot.

[seandepagnier]

Currently you would need to put the pilot in standby, and give the servo a position command:
follow up
ap.enabled = False
servo.position_command = -15.5

non follow up (if I understand correctly relative movement in speed from -1 to 1 )
ap.enabled = False
servo.command = -0.5

When centered it could enable the pilot again.
ap.enabled = True

Not sure having a separate ap.mode would be good, since it should revert to the previous mode which could be one of several things. In any case, let me know what you think.

[nousian]

Currently you would need to put the pilot in standby,  and give the servo a position command:
follow up
ap.enabled = False
servo.position_command = -15.5

non follow up (if I understand correctly relative movement in speed from -1 to 1 )
ap.enabled = False
servo.command = -0.5

When centered it could enable the pilot again.
ap.enabled = True

Not sure having a separate ap.mode would be good, since it should revert to the previous mode which could be one of several things.  In any case,  let me know what you think.

This sounds completely 100% fine, it does not need to be a new AP mode at all. It just usually is in other autopilots, but I guess there is no real reason other than convention.

So servo.position_command is absolute degrees, with maximum speed available? Will it "honor" the rudder stops somehow, if I "overcommand", or should I check for limits before sending the command?

Same for servo.command, if I command +1.0 its full speed, will it stop automatically at rudder stop, or should I poll the rudder angle and stop by servo.command = 0.0?

Can I combine these somehow, command a both the absolute rudder position and speed to get there? Not really needed I guess, but out of curiosity.

But anyhow, this should be fine to start experimenting with.

[seandepagnier]

it will not move past the rudder limits in either case.

Absolute position control is not really fully developed because it just isn't used that much. So right now the only way you could limit the speed would be to adjust the servo.min_speed and servo.max_speed parameters. Adjusting the PID constants of the position control loop will also affect it (it will slow down as it approaches the angle)

It could certainly be modified/improved. I will look into potentially supporting this type of joystick/virtual tiller control. If I can build a useful product for this I would improve the code as well.

[nousian]

it will not move past the rudder limits in either case.

Super, one less thing to worry about.

Absolute position control is not really fully developed because it just isn't used that much. So right now the only way you could limit the speed would be to adjust the servo.min_speed and servo.max_speed parameters. Adjusting the PID constants of the position control loop will also affect it (it will slow down as it approaches the angle)

So interim solution could just shoot with speed control command at high/max speed if more than say 10 deg away from target and then wait till rudder is nearing the target and then switch to an absolute position command when rudder is say 10 deg away from target?

It could certainly be modified/improved. I will look into potentially supporting this type of joystick/virtual tiller control. If I can build a useful product for this I would improve the code as well.

Maybe a small improvement could be adding a parameter like targer_absolute_steering_speed or similar?

And a useful product could be a rotary potentiometer/encoder, that could be used not only for FU-steering, but normal AP modes as well, as well as navigating menus - like many autopilots use such a wheel for?