Autopilot response to waves

[Tehani]

Originally Posted by seandepagnier

The motor controller in pypilot does measure the current in amps.
This is a very noisy measurement of pressure and only available when the motor is being driven but it is some sense of feedback. With machine learning, over time, the intention is the pilot can being to give a more and more accurate prediction of force at any time. Just as rudder feedback is more desirable than estimation, or working in relative movements, in practice the improvement is fairly small in many actual use cases.

An actual force sensor would be desirable. How to you suggest this could be implemented? It is essential that any sensor does not add much play or act like a spring to the linkage.

The concept of "dead zone" is a flawed one in my opinion. It works in space domain, where pypilot's "period" works in the time domain.

Yes, the fuzzy pilot implements these states. The correction is calculated by an interpolation of the current state in the table. For example, if the current "sea state" from accelerometers is computed as 3.4, it will uses the 3, and 4 values of seastate in the multidimensional table to compute the correction. The feedback (adjustment) in this case only updates the sea state 3 index.

The table includes dimensions for heading error and yaw rate, so it essentially implements a non-linear PD filter from these two alone, but I have 5 other dimensions such as apparent wind angle, wind speed, boat speed etc.

Yes this is one way of implementing the logic. It is not the only way and not always the best way. I have multiple pilot implementations that provide alternatives. For example, following gps relative to wind sensor will follow wind shifts more closely while maintaining an overall gps course and ignoring compass completely being immune to local magnetic distortions. There are many possible operating modes.

This is a very interesting problem I have not explored.

This part is working and optimized.

For the jibe problem you mostly need an accurate apparent wind measurement and yaw rate I believe. In my boats I set up so accidental jibe does not damage things...

Sean,

The problem with the motor current reading is not so much the noise as how useless it is to see the force on the blade when the motor is not turning. You must analyze that force to see if you should start the motor, and not the other way around.

I have found two types of sensors that might work well, one for mechanical arm drives, and one for hydraulics. Here are the links:
https://www.aliexpress.com/item/4000...c00m6kRgX&mp=1
https://www.aliexpress.com/item/3278...c00m6kRgX&mp=1

The treatment of the "dead zone" in the domain of space necessarily involves a temporary response. I consider it dangerous to intentionally delay the response because it can affect the derivative and proportional components of the PID. (I process the dead zone at the end, just before handling the PWM, and it's easy for the derivative component to go over the threshold with a yaw).

I am processing the "fuzzi" section in such a way that the parameters vary proportionally between maximum and minimum for each setting. For example, I analyze the average accelerations, and the maximum variations of the angles of heel and pitch to adjust the speed and power of the engine and action of the counter rudder. I also include the STW speed to vary the rudder gain and that dead zone -damping- (if the speed is low, the dead zone widens).

It does not seem correct to use the GPS and wind data directly, because they are very unstable and you have to average. GPS delivers very poor heading and speed data at low speed, and you know how weather vanes work ...
This necessary averaging makes the boat not respond well to sudden changes in the waves. Therefore, it is better to keep HDG steering all the time, and only apply corrections at longer intervals. It is also necessary to make automatic transitions between operating modes, in case the navigator, GPS or wind equipment fails.
It is indifferent that the HDG sensor gives an angle with distortions or wrong declinations, acting in this way, because we only worry about the variations of that angle.

Jose Luis

[seandepagnier]

Originally Posted by Tehani

Sean,

The problem with the motor current reading is not so much the noise as how useless it is to see the force on the blade when the motor is not turning. You must analyze that force to see if you should start the motor, and not the other way around.

On a very responsive boat in tough conditions, with a very low friction drive it matters most, but in practice on many setups it can be inferred.

For example, measuring current when running can be used to determine weather helm.

Of course a sensor is "better" but considering the marginal improvements of rudder feedback sensors (in many but not all cases) it would be interesting to know if a force sensor is worthwhile.

I have found two types of sensors that might work well, one for mechanical arm drives, and one for hydraulics. Here are the links:
https://www.aliexpress.com/item/4000...c00m6kRgX&mp=1
https://www.aliexpress.com/item/3278...c00m6kRgX&mp=1

This looks interesting.
[quote]
The treatment of the "dead zone" in the domain of space necessarily involves a temporary response. I consider it

You may intuitively think this, but in practice you will end up with something consuming more power as it twitches more often. Neither option is actually optimal, but time is better generally in practice compared to space. I suppose I could implement a pilot to try the other way for comparison purposes, but seriously doubt the result would be better.

I am processing the "fuzzi" section in such a way that the parameters vary proportionally between maximum and minimum for each setting. For example, I analyze the average accelerations, and the maximum variations of the angles of

Would be great to hear about your results with a fuzzy pilot.

heel and pitch to adjust the speed and power of the engine and action of the counter rudder. I also include the STW speed to vary the rudder gain and that dead zone -damping- (if the speed is low, the dead zone widens).

I don't think you can easily do this in a way that will be easily usable across many boats. It will be difficult to tune something like this. As far as "dead zone" again in space vs time, consider the motor acceleration from stop to moving. This is why time is better and gives especially lower power consumption. Anyway, as your deadzone in space, it cannot adjust within this zone which also leads to less accurate steering.

It does not seem correct to use the GPS and wind data directly, because they

Keep in mind the gyros are still being used so the heading is very stable.

At speed, using only gps and gyros can give a very stable heading. Using only gyros and wind sensor can also give a good reading.

This is just one optional mode, and very useful if you sail near magnetic distortions and don't want compass to disturb effects, or want to follow wind shifts, It can be worse if you are traveling at various speeds, sometimes often very slow, or have poor wind sensor readings.

If the wind is used under gps, it will follow wind shifts while maintaining a course. Depending on if you are sailing near hills this can be useful.

Consider wind vane steering and how well it works following wind shifts without a compass or gps. This can be very useful at times especially with very dynamic wind.

So the idea that always fo

are very unstable and you have to average. GPS delivers very poor heading and speed data at low speed, and you know how weather vanes work ...
This necessary averaging makes the boat not respond well to sudden changes in the waves. Therefore, it is better to keep HDG steering all the time, and only

Again, it is not always better, but sometimes it is. The basic pilot does this, but alternate implementations use other types of logic.

Human pilots sometimes use a compass sometimes do not. They can do quite well just feeling the wind in many cases.

I am hoping the machine learning pilot can take any available sensors and ignore what ends up not being useful. A video feed in daytime could help the pilot learn faster and then if later a few sensors fail, it will be better able to utilize what it has

apply corrections at longer intervals. It is also necessary to make automatic transitions between operating modes, in case the navigator, GPS or wind equipment fails.
It is indifferent that the HDG sensor gives an angle with distortions or wrong declinations, acting in this way, because we only worry about the variations of that angle.

Jose Luis

Until you sail under a low enough metal bridge or over a wreck and your magnetic heading is distorted and the boat turns because of it.

[Tehani]

Originally Posted by seandepagnier

On a very responsive boat in tough conditions, with a very low friction drive it matters most, but in practice on many setups it can be inferred.

For example, measuring current when running can be used to determine weather helm.

We can also think that the force that the water exerts on the blade is proportional to Rudder angle * STW ^ 2, but I am not referring to the force in steady state, but to the detection of the waves coming from the stern. In this case, there is an instantaneous decrease in pressure on the blade, which is impossible to detect both by this calculation and by measuring the current of a motor that may be stopped at that moment. As I said before, the heeling variation occurs later, at the crest, and is reduced if the rudder has been acted before.

This looks interesting.

When we sail in boats with a tiller rudder, we can observe that humans try to control the pressure on the blade, and not its angle. The angle we apply is the consequence. It is more difficult to appreciate it in wheel rudders. Of course, the analysis of that force also tells us if we have the sails well trimmed.
I am convinced that the use of these force and pressure sensors can turn the autopilot "almost" into a human being.

You may intuitively think this, but in practice you will end up with something consuming more power as it twitches more often. Neither option is actually optimal, but time is better generally in practice compared to space. I suppose I could implement a pilot to try the other way for comparison purposes, but seriously doubt the result would be better

I don't think you can easily do this in a way that will be easily usable across many boats. It will be difficult to tune something like this. As far as "dead zone" again in space vs time, consider the motor acceleration from stop to moving. This is why time is better and gives especially lower power consumption. Anyway, as your deadzone in space, it cannot adjust within this zone which also leads to less accurate steering.

With space-based dead zone processing, I have verified its effect over time, effectively reducing engine consumption. In other words, the blade does not move within variable margins of error depending on the state of the sea. The cumulative effect of the integral is very effective here to correct the course at intervals of time that depend on this "dumping" parameter, and the natural rocking of the waves usually corrects before the pilot has to act. You will surely recognize it. As I have said before, the dead zone is dynamically reduced in rough seas.

Would be great to hear about your results with a fuzzy pilot.

Me too, I hope soon. If you want, I can pass you the electronic schematics and my hardware libraries. It is a compact autopilot without arduino or rasp of 30Amp and with communications of all kinds. It is based on an STM32F4. This has advantages because it is possible to make it more robust using analog and window watchdog techniques, and all control of the processor and hardware is in your hands. I think your algorithms could be tested on this platform as well. (Thinking of you, I included a socket for your beloved MPU9255 ...). I have 4 finished prototypes, and also 6 units of Ublox-M8n GNSS + 9 axis Gyro in dome box, with WiFi, USB, N2k, Seatalk and N0183 interfaces. (Sorry, this goes with BNO055 ...)
If you like the idea, we talk in private.

Keep in mind the gyros are still being used so the heading is very stable.

At speed, using only gps and gyros can give a very stable heading. Using only gyros and wind sensor can also give a good reading.

This is just one optional mode, and very useful if you sail near magnetic distortions and don't want compass to disturb effects, or want to follow wind shifts, It can be worse if you are traveling at various speeds, sometimes often very slow, or have poor wind sensor readings.

If the wind is used under gps, it will follow wind shifts while maintaining a course. Depending on if you are sailing near hills this can be useful.

Consider wind vane steering and how well it works following wind shifts without a compass or gps. This can be very useful at times especially with very dynamic wind.

So the idea that always fo

Again, it is not always better, but sometimes it is. The basic pilot does this, but alternate implementations use other types of logic.

Human pilots sometimes use a compass sometimes do not. They can do quite well just feeling the wind in many cases.

Until you sail under a low enough metal bridge or over a wreck and your magnetic heading is distorted and the boat turns because of it.

I have not had good experiences with the gyro, because it is very noisy. I've tried setting dead zone thresholds on the readout, but it's still quite unstable.
As you have convinced me about the convenience of using it directly, I will stop using the yaw variations of the Kalman filter output because the magnetometer output is also involved in that data. I'll keep ingesting the gyro processing, thank you.

Jose Luis

[seandepagnier]

Originally Posted by Tehani

We can also think that the force that the water exerts on the blade is proportional to Rudder angle * STW ^ 2,

yes, but balanced rudders or ones with hydraulic steering etc have different characteristics.

but I am not referring to the force in steady state, but to the detection of the waves coming from the stern. In this case, there is an instantaneous decrease in pressure on the blade, which is impossible to detect both by this calculation and by measuring the current of a motor that may be stopped at that moment. As I said before, the heeling variation occurs later, at the crest, and is reduced if the rudder has been acted before.

Yes, but the same signal is detectable on gyros and accels. It is always nice to have overlapping sensors but the cases where a force sensor on the rudder are critical are probably fairly limited. In any case: yes it can be useful in certain cases.

With space-based dead zone processing, I have verified its effect over time, effectively reducing engine consumption. In other words, the blade does not move within variable margins of error depending on the state of the sea. The

So your pilot is working? What is it called where is the repository?

You can believe what you want, but using a "deadzone" is in my opinion the wrong way to implement this though the difference at times may be slight.

I do not intend to use either method for the machine learning pilot. It will be able to come up with whatever works best.. in theory anyway.

recognize it. As I have said before, the dead zone is dynamically reduced in rough seas.

How do you know how much to adjust it by? This is a problem that is difficult to get right. It will inevitably not always work well unless you have lots of parameters to adjust. If you stay in time instead of space, you don't need to adjust it for seastate.

Me too, I hope soon. If you want, I can pass you the electronic schematics and my hardware libraries.

Please just post a link to the repository.

It is a compact autopilot without arduino or rasp of 30Amp and with communications of all kinds. It is based on an STM32F4. This has advantages because it is possible to make it more robust using analog and window watchdog techniques, and all control of the processor and hardware is in your hands.

The only real advantage to this is slightly lower power consumption. The raspberry is realtime enough to work as a pilot, and much more capable. I don't know how something like this would be able to run machine learning algorithms without a lot of difficulty.

In any case, it is interesting but I would suggest the esp32 platform.

I think your algorithms could be tested on this platform as well. (Thinking of you, I included a socket for your beloved MPU9255 ...). I have 4 finished

I use icm20948 now.

prototypes, and also 6 units of Ublox-M8n GNSS + 9 axis Gyro in dome box, with WiFi, USB, N2k, Seatalk and N0183 interfaces. (Sorry, this goes with BNO055 ...)
If you like the idea, we talk in private.

I think the BNO055 is not a great sensor. It is expensive and the sensors have more noise than the cheaper inversense ones.

I have not had good experiences with the gyro, because it is very noisy. I've tried setting dead zone thresholds on the readout, but it's still quite unstable.

I would try other sensors

As you have convinced me about the convenience of using it directly, I will stop using the yaw variations of the Kalman filter output because the

You must still use a kalman filter. The difference is you are using the kalman filter to compute pitch and roll (not depending on the compass) then using this vector to rotate out the gyros. This gives you the vertical gyro which you can use in the pilot.

[rgleason]

What about using a smaller pendulum paddle (set straight ahead) off the stern as a good positive force sensor?

[Tehani]

I do not wish to tire the followers of this thread further by following the discussion on highly technical terms. With this entry I will finish.

All rudder blades, whatever they are, exert a variable force with speed over the water. We can speak of a K (constant) that determines the type of blade and its dimensions. (K * Angle * STW ^ 2).

I think we could explain that term "dead zone" a bit: The question is not to move the rudder within a range of heading error, in order for the same swell to maintain that heading. If we constantly activate the motor of the autopilot to correct those small and constant errors, we will consume a lot of energy in a rather useless way. Sean proposes to apply corrections from time to time, and I accumulate the mean error with his sign (port - starboard), and this also has a temporal response when the accumulated exceeds a certain limit.
The adjustment of this dead zone can be to the user's liking, as all manufacturers do, but the allowable adjustment margin must always be based on tests during the design of the AP, following patterns for each type of boat. Autotuning also starts from experimentation.

We will not see a commercial AP that has to load an operating system and software from an SD to boot. Since their origins, all the APs that have been sold have been based on embedded systems with the software resident on their internal ROM or flash, and also on a single PCB. In this way the operation is much safer (There are no contacts or SD connector exposed to the marine environment) and it is possible to program the response to possible failures (even re-entries by reset). This applies today to all specialized devices. There is no discussion here.

I have worked with Espressif devices (ESP8266 and ESP32). They cannot work driving the 9-bit Seatalk bus. Since debugging with these systems is not very pleasant either, I use them in a fairly limited way (almost exclusively for WiFi and bluetooth).

I think Sean and I agree on a lot of things, and if it doesn't seem like it may be because I'm "Lost in Translation". I am evaluating whether to free this AP and Gyro. It is a difficult question because they also use a large part of the communications software of other devices that I sell.

For all these reasons I am convinced that Sean's software could run beautifully on the hardware that I have designed more reliably and robustly. I stand by my proposal, and I am willing to help. (But I'm not used to using github).

José Luis.

[goboatingnow]

Just a point , it is possible to implement a 9 bit serial on the esp32 https://github.com/ionini/espsoftwareserial

[MicHughV]

One should look to the Vendee race boats.....they are singlehanded, so auto pilot is a must.

They spend a fair amount of time in the southern ocean in some pretty big following seas, and do so with admirable dexterity, and they do this 24/7 for weeks on end.

You can check out Youtube for an understanding and explanation of how those autopilots are designed. The programmers that make the " brain" of these units come from another planet. "Artificial Intelligence" is the name of the game for them.

Off course, they come at a price, putting them out of reach for your basic cruiser.

I sailed 1,000's of miles with a Monitor vane gear. I learned that the trick was to over trim the sails a tad. This keeps them full whether you luff a bit or fall off. At the time, vane gear was pretty much your only option for autopilot.

My only complaint about the vane gear is that it follows the wind. When the wind changes direction, so to does your boat heading. This almost always requires attention to sail trim....usually always happens at night....when it's raining...

[MicHughV]

Can''t end my thought on vane gears without this...

Like other sailors that had the Monitor, I fabricated several wind blades of different lengths to use in different wind or sea conditions as it made a notable difference.

[Tehani]

Originally Posted by goboatingnow

Just a point , it is possible to implement a 9 bit serial on the esp32 https://github.com/ionini/espsoftwareserial

That form does not support multiple higher priority interrupts simultaneously. It would be easy for you to lose bit synchronization.
If you use ESP32 for simple work, it can work.

I rely on the manufacturer's hardware manual. The USARTS of that uC does not support 9 bits natively.

[Tehani]

Originally Posted by goboatingnow

Just a point , it is possible to implement a 9 bit serial on the esp32 https://github.com/ionini/espsoftwareserial

Transmission in Seatalk requires that the transmitter be able to receive and analyze bit to bit its own message to detect collisions. It is also necessary to detect the "Line Idle" state to start the transmission.
Those things can only be done by real USARTS.

About 30 years ago I did a software USART using a simple 4Mz PIC because I needed 2 channels and the hardware only had 1. But I did it in assembler, using an interrupt timer to synchronize the bit center. I was able to do it because the uC was not too charged.

[Be Free]

Originally Posted by Tehani

I do not wish to tire the followers of this thread further by following the discussion on highly technical terms. With this entry I will finish.
...
José Luis.

Please continue the technical discussion. That is precisely why I am following it.

[toolbar]

Just ordered Sean's hardware and am looking forward to try it out over the winter. The source code looks nice, hopefully I will manage to contribute something back.

Paul

[seandepagnier]

Originally Posted by Tehani

I think we could explain that term "dead zone" a bit: The question is not to move the rudder within a range of heading error, in order for the same swell to maintain that heading. If we constantly activate the motor of the autopilot to correct those small and constant errors, we will consume a lot of energy in a rather useless way. Sean proposes to apply corrections from time to time, and I accumulate the mean error with his sign (port - starboard), and this also has a temporal response when the accumulated exceeds a certain limit.

You will end up having to adjust this dead zone based on conditions to get the same effect of using a nearly constant time instead.

We will not see a commercial AP that has to load an operating system and software from an SD to boot. Since their origins, all the APs that have been sold have been based on

In the past it was not practical to use an operating system such as linux.

pypilot is a commercial AP and finally brings OS possibilities. There are a lot of boards coming out with emmc data which solves the sd card reliability problem and those boards with quad core can boot in < 10 seconds.

I have worked with Espressif devices (ESP8266 and ESP32). They cannot work driving the 9-bit Seatalk bus. Since debugging with these systems is not very pleasant either, I use them in a fairly limited way (almost exclusively for WiFi and bluetooth).

seatalk should not be a consideration. This is for proprietary sensors and really has no place on my boat. If you really must use there are plenty of converter boards to turn this into signalk, so I see no reason the main autopilot needs to directly communicate with this.

For all these reasons I am convinced that Sean's software could run beautifully on the hardware that I have designed more reliably and robustly. I stand by my proposal, and I am willing to help. (But I'm not used to using github).

José Luis.

Sure, if your board can run micropython it can probably work. There is support to run everything on a single process, although using multiple processes has advantages. Some libraries like scipy won't be ported, so you may have to use a linux computer over wifi to run the calibration algorithms at first anyway. It wouldnt be that hard to make it all work on the esp32 if desired, and it has enough processing power. There won't be much chance of running machine learning or vision processing though.

[rgleason]

Sean I thought I heard an offer/proposal from tehani. Arent you going to accept?