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 works for me!
#1
I've been slowly working on building a PyPilot autopilot for a few months.  I wanted it for a sailing tour I'm on at present of locations within Melbourne Australia's Port Phillip Bay.  My approach has been to test each part of the system in turn, but like @McNugget says in his Hackaday project, I also found it hard to get the info about how to wire things. Last Sunday I finally got all the parts hooked up:

   

This autopilot is to replace an old Autohelm 3000, and I'm using the connectors and motor from that unit.  I'm also using an adjustable CV/CC module I bought on AliExpress to convert and filter the 12V down to 5V, and a TVS across the motor terminals.  The motor driver is a VNH5019 I bought online, which hasn't had any of the problems I found in the VNH20SP30s I've bought.  I didn't need to change motor.ino.  For minimal protection (I'll improve this) I'm using a 5A circuit breaker with a blade fuse form factor.  The keypad is one I found online, and I'm connecting the RPi and nano via a USB cable (will use an opto for my next version).

My approach is to make something as simple and "ghetto" as possible, and leave making something rugged or protected until the next version.  That way I can test and learn things earlier.

After some electrical testing to make sure the RPi and nano were working properly, I set about putting all the electronics into a sealed lunchbox (I held it under water and there are no bubbles, and no water gets in).  Everything is held vaguely in place with hot glue and some cable ties.  For better or worse, hot glue bonds to new plastic are not hard to break, but they only have to last long enough to show the unit works.

]    

After powering up the unit and confirming that the RPi works, that I can connect to it with my phone, and that the left and right buttons work (motor gets driven ok, drive current around 800mA), I mounted the unit on my boat and did the compass calibration.  This went fine, and heading has been stable and reliable over the past week.  However once I started sailing and enabled, I found to my surprise that the motor commands are reversed when in autopilot mode, which is also what @McNugget found:

Quote:I had the suspicion that my rudder command might go into the wrong direction. And sure enough, even though the buttons for "go a little port" or "go a little starboard" were functioning at the dock, the moment I started using the automatic course keeper, the boat always steered in the wrong direction!

At this moment I had started my journey, so I wasn't able to return to the dock (this has been a just-in-time project!), and so I wasn't able to try out the autopilot on the first day.  However at the end of the first day I swapped the motor output wires on the driver board, and the next day the autopilot worked fine in calm seas while motoring.  This reversal between standby and engaged is definitely a bug!

   

On the second day we sailed on a beam reach, and the autopilot did a good job of holding course with minimal input.  It had the tendency to stop a few degrees short of the desired heading, so I raised the P and D values, which seems to have helped.

On the third day we had a following sea, and the autopilot did very nicely, with it working the helm noticeably less than I was in the circumstances.  So that's good results in three different sea states.

On this third day, I used the LCD interface to set the autopilot type to "learning".  The result of this is that while the autopilot can be engaged, no motor commands get sent - the boat just gets further and further off course.  What's worse is that even switching the autopilot type back to "simple" or "basic" doesn't improve things: The autopilot never moves the motor.  I also tried a power cycle.  It's not a hardware problem though, as the left and right buttons still move the motor when in standby mode.  Not sure what's going on here, but this also seems like a bug, and one that leaves you without a working autopilot.  My guess is that choosing "learning" mode puts something in the config that upsets all modes.  I'll diff the SD card against the original files on my computer and see what I find.  Suggestions welcome!

All in all, I'm simply delighted that the project exists, that it's open source, and that in practice it works as well as it does.  A huge shout out to @seanepagnier (and other contributors) for all the hard work!
Reply
#2
https://github.com/pypilot/pypilot/issues

tensorflow error this is the learning mode.
i have developed an interest in the machine learning but i have a lot of human learning to do to be able to understand it .lol
Reply
#3
(2020-01-11, 08:58 AM)CapnKernel Wrote: ...

I had the suspicion that my rudder command might go into the wrong direction. And sure enough, even though the buttons for "go a little port" or "go a little starboard" were functioning at the dock, the moment I started using the automatic course keeper, the boat always steered in the wrong direction!
...
while motoring.  This reversal between standby and engaged is definitely a bug!

So the direction is reversed for manual mode. The current source code supports assigning the keys on the web interface.
Quote:On the second day we sailed on a beam reach, and the autopilot did a good job of holding course with minimal input.  It had the tendency to stop a few degrees short of the desired heading, so I raised the P and D values, which seems to have helped.
It depends on your style also and comfort. Sometimes making the autopilot steer straighter uses less power, at least on unstable courses. You can decrease the gains on naturally stable courses like upwind to save power. Many wind vane steer + or - 10 degrees when running in following seas and this is acceptable as long as the sails can stay full. The autopilot usually does better but doesn't have to.
[quote]
On the third day we had a following sea, and the autopilot did very nicely, with it working the helm noticeably less than I was in the circumstances.  So that's good results in three different sea states.

On this third day, I used the LCD interface to set the autopilot type to "learning".  The result of this is that
[quote]
This pilot is not at all functional yet and I don't think it produces output commands or anything. I haven't even had a chance to make trials. It should not be in the list unless you installed tensorflow so I'm surprised it was available.

Sean
Reply
#4
(2020-01-11, 04:18 PM)seandepagnier Wrote:
(2020-01-11, 08:58 AM)CapnKernel Wrote: while motoring.  This reversal between standby and engaged is definitely a bug!

So the direction is reversed for manual mode. 

Is this intentional?  (Mind boggles)

(2020-01-11, 04:18 PM)seandepagnier Wrote:
(2020-01-11, 08:58 AM)CapnKernel Wrote: On the second day we sailed on a beam reach, and the autopilot did a good job of holding course with minimal input.  It had the tendency to stop a few degrees short of the desired heading, so I raised the P and D values, which seems to have helped.

It depends on your style also and comfort.   Sometimes making the autopilot steer straighter uses less power, at least on unstable courses.

The course was nice and straight, autopilot was doing a good job.  Just that the heading was 3-4 degrees downwind of what was dialed in.

(2020-01-11, 04:18 PM)seandepagnier Wrote:
(2020-01-11, 08:58 AM)CapnKernel Wrote: On this third day, I used the LCD interface to set the autopilot type to "learning".  The result of this is that

This pilot is not at all functional yet and I don't think it produces output commands or anything.   I haven't even had a chance to make trials.   It should not be in the list unless you installed tensorflow so I'm surprised it was available.
I'm using tinypilot_30092019.img.xz, haven't done anything special.  Pressing Menu gave me a menu where the second option was "gains" and the first option was (I think) "pilots", and from that first option I chose "learning".  Sadly, this option has now gone away, but I was able to change the pilot from the web interface.  (What is basic mode, and what is simple mode?  What should I be using?)

Do you know how I can get the autopilot working again?
Reply
#5
I have cooked up a schematic in KiCad for my bare-bones point-to-point no-PCB hotglue-assisted OMG-you-didn't-sail-with-that-did-you first draft PyPilot build:

      

  
.pdf   ozhelm.pdf (Size: 51.42 KB / Downloads: 694)

This is a bare bones implementation with no protection apart from a power input fuse and the TVS across the output.  I did it just to confirm that PyPilot works (which it does).  It's also missing the opto-isolated interface between the RPi and the nano.  My build just connects the two with a USB cable, which shouldn't matter because they're running off the same supply and they're 2" apart.

I'm posting it here because it may be useful to someone who is just starting out, like I was a few months ago.  There's a lot of non-obvious details in how to hook things up.  I'm thinking of @McNugget's recent experience here getting started:

Quote:I ran into a trouble when I tried to understand what was required to get the motor controller to PyPilot to work. I thought, it should be easy to just hook up an Arduino to an H-bridge that you can easily obtain from Amazon or Ebay and have the system communicate happily. However, I ran into documentation issues right from the start, couldn't find a part-list, couldn't find schematics and so on and so forth.

Turns out code and schematics are available but it took me the better part of a week to understand what's going on in the arduino code and I didn't like the schematics.

In case someone things I'm bashing PyPilot and what's on the website, I'm not.  Again, I agree with @McNugget:

Quote:Please do not get me wrong: What the original author, Sean, put together is amazing overall! 

I'll gladly contribute whatever I can to helping others get into it (but some pointers on what would be accepted would be appreciated).  I'm also happy to put the KiCad files on github.
Reply
#6
Thank you, for all the references.
I realize, parts of my write-up might seem like I’m a bit frustrated with the state of the documentation. I guess I was but that’s why we’re here to help others don’t run into the same issues. Or, if they do, help them out of there and get going.

Again, I love how well this works! I just need to figure out how to create different PID profiles for different weather conditions and sea states. Ideally, I could change how often the motor moves.

Cheers
Timo
Reply
#7
The motor controller can really be implemented in a lot of different ways which makes it difficult to document. It depend on the type of motor, the voltage, the maximum current, cost, efficiency and several more variables.

If I were building just one, I would use different parts from building 20 and again completely different parts from building hundreds.

It would be great to have a list of examples using integrated drivers or whatever, but I do not have time/interest to explore so many different possibilities when in the end they will cost more (in quantities) and have worse efficiency and reliability than a custom board.

I would like to integrate changes into motor.ino to support different hardware configurations, but this is going to have to be set at compile time and as suggested use different header files.

I support free software and designs so that you can be assured your autopilot is not evil, but I don't really feel like I am responsible for listing every part number or layouts which I am constantly changing anyway.
Reply
#8
(2020-01-11, 04:18 PM)seandepagnier Wrote:
Quote:
Quote:This pilot is not at all functional yet and I don't think it produces output commands or anything.   I haven't even had a chance to make trials.   It should not be in the list unless you installed tensorflow so I'm surprised it was available.

Sean

New to the board, first post, so : Hello World!

Interesting idea. I presume the added predictors of rudder control would then be boat movement (mainly as a surrogate for wave data) and wind. I would investigate it with a more frequentist approach at first. Identify any regularities that could be used either as global parameters or within small (<1s) timeframes (or both). 

After a very quick look at NOAA for possible databases to exploit, it seems that the archived data is in fact pre-processed and not raw, with waves averaged over a period of 20 minutes. See:

https://www.ndbc.noaa.gov/rsa.shtml

This is unusable for the present purpose. On a side note, their approach to pre-processing wave data could be worthwhile to look at:

https://www.ndbc.noaa.gov/wave.shtml

The crux of it seemingly a Fourier transform. I might have sourced some real time marine wind data. Waiting for an answer.

The best would be to have data (all of it, including output to rudder control) logged by Pypilot at a high sampling rate in a variety of sea conditions.
"Overthinking, I try very hard not to do that."
Reply
#9
The noaa wave data is a model based on wind and other weather to predict what the sea state would have been and the model is updated to match the measurements of the relatively few actual buoy measurements.

I am not sure how this would be useful to an autopilot anyway, and consider that all of the measurements recorded greatly depend on the vessel itself not just the conditions. The predicted waves and forecast is useful for planning where you will sail, but not really useful to the autopilot who is steering in the moment.

I have performed fourier transforms (pypilot's scope has this built in) of various sensor data, and in certain sea states I can see both the swell period as well as the boat period, but have yet to apply this in a useful way. The future improvements for using rudder feedback as well as all the other sensors I believe is similar to how a human can learn steer better (machine learning)
Reply
#10
(2020-01-25, 07:35 PM)seandepagnier Wrote: The noaa wave data is a model based on wind and other weather to predict what the sea state would have been and the model is updated to match the measurements of the relatively few actual buoy measurements.

I am not sure how this would be useful to an autopilot anyway, and consider that all of the measurements recorded greatly depend on the vessel itself not just the conditions.   The predicted waves and forecast is useful for planning where you will sail, but not really useful to the autopilot who is steering in the moment.

Useless, I agree. I meant real time wave or water mouvement data of high sampling rate (>50Hz - in fact, highest rate reliably achieved by Pypilot), to analyze as an exploratory step. Maybe eventually make a training set out of it. Vessel here is essentially a constant, the bulk of variability comes from water movement (and wind, then deployment of sails would also be variables).

[quote pid='12030' dateline='1579977342']
I have performed fourier transforms (pypilot's scope has this built in) of various sensor data, and in certain sea states I can see both the swell period as well as the boat period, but have yet to apply this in a useful way.   The future improvements for using rudder feedback as well as all the other sensors I believe is similar to how a human can learn steer better (machine learning)
[/quote]

Since here the amount of data is quite small (compared to typical recent machine learning contexts), the measurement error is also quite small, and all the data, including predicted rudder control values, are numerical and not categorical, machine learning (Tensorflow) could be an overkill or inappropriate. It's more of a black box approach, becoming grey if you incorporate a parametric model, and I personally prefer to use that kind of ML only when everything else fails, or if I'm not interested in understanding.

An afterthought:

About those sails being a variable. If there was a way to get sheet tension through a sensor, this could be used to add an "electronic" sheet-to-tiller component to Pypilot. Wouldn't some type of rudder corrections could then be initiated and continued almost at the same rate as a gust develops, before the other sensors can detect a change significant enough to do it? 

"Self-steering for sailing craft" by John S. Letcher has a well thought in depth analysis of sheet to tiller systems that could be drawn upon.
"Overthinking, I try very hard not to do that."
Reply


Forum Jump:


Users browsing this thread: 2 Guest(s)