Cruisers Forum
 


Join CruisersForum Today

Reply
 
Thread Tools Search this Thread Rate Thread Display Modes
Old 06-02-2018, 03:38   #151
Registered User
 
transmitterdan's Avatar

Join Date: Oct 2011
Boat: Valiant 42
Posts: 4,537
Re: Autopilot Control

No worries on quoting.

The arrival logic in O is pretty good I think. Any scheme has to deal with the case that the arrival radius boundary is never crossed. It's maddening to get close to the waypoint but the damn AP is turning in circles trying to get closer.

It would be nice if there were an NMEA message to set rudder angle. But there isn't so there's nothing we can do unless we want to invent new messages.
__________________

transmitterdan is offline   Reply With Quote
Old 06-02-2018, 05:44   #152
Registered User
 
rgleason's Avatar

Join Date: Mar 2012
Location: Boston, MA
Boat: 1981 Bristol 32 Sloop
Posts: 11,551
Re: Autopilot Control

Note that Condition 4
https://opencpn.org/wiki/dokuwiki/do...x_nr_and_xte_0

Editor's note: Editor's Diagram Correction: Boat B location Normal Range should be shown at the arrival radus with boat starting the turn!]
__________________

rgleason is offline   Reply With Quote
Old 06-02-2018, 07:10   #153
Registered User
 
rgleason's Avatar

Join Date: Mar 2012
Location: Boston, MA
Boat: 1981 Bristol 32 Sloop
Posts: 11,551
Re: Autopilot Control

Note: After considering Diagram 4 (which needs to be redrawn to be accurate)
https://opencpn.org/wiki/dokuwiki/do...g_nr_and_xte_0
I think we should have the additional condition that
RNG has increased for 2 seconds, just for safety purposes, to turn.

I have had no experience with this mode, however.
rgleason is offline   Reply With Quote
Old 06-02-2018, 08:09   #154
Registered User
 
boat_alexandra's Avatar

Join Date: Aug 2009
Location: chesapeake bay
Boat: bristol 27
Posts: 3,345
Re: Autopilot Control

I am making it so if you cross the perpendicular line, it counts as arrival as well.
boat_alexandra is offline   Reply With Quote
Old 06-02-2018, 10:12   #155
Registered User
 
rgleason's Avatar

Join Date: Mar 2012
Location: Boston, MA
Boat: 1981 Bristol 32 Sloop
Posts: 11,551
Re: Autopilot Control

Sean
In Condition 4
  • NR < Arrival Radius
  • Range increase is not considered.

What is this perpendicular line?
Is it NR=0?


Quote:
Originally Posted by boat_alexandra View Post
I am making it so if you cross the perpendicular line, it counts as arrival as well.
rgleason is offline   Reply With Quote
Old 06-02-2018, 11:36   #156
Registered User
 
boat_alexandra's Avatar

Join Date: Aug 2009
Location: chesapeake bay
Boat: bristol 27
Posts: 3,345
Re: Autopilot Control

The perpendicular line is a line that crosses the waypoint perpendicular to the route. You can either be before or after the waypoint in this way. It is a better test than using increasing arrival radius.

If the gps jumps enough from few satellites or other reasons, it could trigger the waypoint advance. Not so with this method. The option to not advance also is not needed.
boat_alexandra is offline   Reply With Quote
Old 06-02-2018, 14:31   #157
Registered User
 
rgleason's Avatar

Join Date: Mar 2012
Location: Boston, MA
Boat: 1981 Bristol 32 Sloop
Posts: 11,551
Re: Autopilot Control

Sean wrote:
Quote:
"The perpendicular line is a line that crosses the waypoint perpendicular to the route."
...which is the same as NR (Normal Range) = 0

Quote:
"This is a better test than using increasing arrival radius."
...OpenCPN uses NR < Arrival Radius for Condition 4.

Quote:
If the GPS jumps enough from few satellites or other reasons, it could trigger the waypoint advance. Not so with this method.
Wouldn't the waypoint advance be triggered in this situation in any case? Why?

Quote:
The option to not advance also is not needed.
Can you explain why? --So do I understand correctly that you are considering a single universal test without the 4 Conditions? Would this be for AP_route_pi or also for OpenCpn? I am trying to understand the full scope.
rgleason is offline   Reply With Quote
Old 09-02-2018, 08:41   #158
Registered User
 
CareKnot's Avatar

Join Date: Sep 2016
Location: Greater Houston Galveston Metroplex
Boat: 1979 Endeavor 32
Posts: 337
Re: Autopilot Control

Morning Captain Gleason,

I just wanted to chime in and say thanks to all the contributors in this thread. So far, it has been a pleasant and interesting read. Fair warning. I feel an attack of wordiness coming on.

Not being personally familiar with the nomenclature and only an informal understanding of the topic, I had to reread many posts while jumping around to find acronyms, definitions and mentions of standard practices. So thanks to those that posted all that information and also to those that asked questions and provided real-world context and hypothesis.

I don't know if you will find the following of any value, but I wanted to share, mostly on a general level, some ideas that might be food for thought. I don't know how applicable they might be future upgrades or the topic at hand, so feel free to ignore my ramblings if it suits you.

Quite some time back I had the privilege of working with a remarkable innovator whose background was extremely varied and whose work product was mostly classified. His name was Gene. For near 15 years we were close friends and coworkers. He passed about a decade ago.

Together, we worked on a number of new ideas and tech upgrades that required a broad set of skills applicable to both sides of the software/hardware boundary. One in particular was a voice encoding algorithm that produced about two orders of magnitude in bandwidth savings over contemporaneous digital encoding technology. I loved the work and in retrospect, it was the 'spit-balling' sessions that I miss the most.

At one point and simply for fun, we started playing with ideas for an AP for land vehicles. Many of the ideas we shared ended their life as a crumpled wad of paper, while many of the systems we designed and developed ended up on vehicles participating in a well known government program's efforts to realize automated off-road vehicles; which brings me to the second reason for this post: The 'spit-balling' sessions that I miss.

While Gene and I were initially defining the 'AP for autos' technical requirements way back in the early 90s, I had a revelation that I shared with him. I remarked that, "Auto in auto-pilot meant automatic, but did not necessarily mean autonomous. Perhaps we might want to consider the latter case. Some of the inputs this system requires can be applied to cartography as easily as collision avoidance or routing." Ultimately, this change in perspective took the project in a new direction; how to network the delta. That is, only sharing the data that was missing in any given data set.

We were looking at the problem of AP like OCPN currently does now; a semi-autonomous navigation system with certain optional input sensors to assist in avoiding undesirable results, like avoiding unplanned gybes. In our case that included avoiding collisions and routing around obstructions and congestion, kids chasing balls into the street, etc. In your application, available sensors include AIS, weather, depth, etc., so there is likewise, a wealth of information to gather and share.

The system we tested made use of a number of different types of sensors to locate and track both static and dynamic objects. One such device was an inexpensive laser scanner (like those used in the check-out lane at the grocery). That is how we tested the concept. Ultimately, we designed a laser scanner for vehicles. It could very small objects while operating in the 200-250 knot speed range (I know, I know, but we were trying to test the limits). Though originally conceived as a collision avoidance sub-system, we found it useful in imaging and mapping too; and this brings me to my 'spitball'.

First off, aren't there some FPGA (Field Programmable Gate Array) projects out there to drive an AP motor unit? In the final analysis, all you need to send it from OCPN is your corrected heading information. I found one project online that was intended to drive an RC boat. It is equipped with a manual mode so that you can drive it via a wireless joystick controller. (There were times when I would have appreciated that option, like last year when I was standing the helm in an open cockpit in freezing rain and 20+ knots of wind for days at a time. Sheesh!)

Anyway, check out this PDF. It is dated 2010, but it was the first thing I came across and it looks like an easy conversion to drive an AP stepping motor: http://www.diva-portal.org/smash/get...476/FULLTEXT01

So, for the sake of argument, let's say we have accomplished that goal and are driving your AP stepping motor to control your helm directly with OCPN. In my mind, that is only a small part of the ultimate goal of OCPN as the ultimate onboard nav and marine data network solution. So how can we get more usable data into OCPN and how do we share it?

Without getting too technical, it's pretty easy to build a network that can collect data from onboard devices. Sharing it in a meaningful way isn't always so easy. That is a large part of this conversation. But what if there were another approach? A holistic approach that would allow course adjustments based on verified sensor data and shared data from other vessels that have recently transited the area you are heading towards?

Building a device that can 'see' through fog, smoke, glare and darkness to yield vector data and images is not all that difficult. Fifteen years ago, we built a scanning laser that would return a raster pattern of vector data 'hits'. Research took a little time. Building it took much less.

It had to be very fast and very reliable, so we mounted small mirrors on two piezoelectric oscillators, one for each axis. Oscillating one axis much faster than the other generated a slightly skewed raster pattern. Every reflection generated vector data (relative direction, angle and range to target). We utilized a spinning prism synced to the frequency of the oscillators and corrected for range. It was used to illuminate CCD arrays in order to read the reflected light. We also used filters and gates to eliminate ambient light so that the reflected light could be read through fog, smoke and other impediments when needed. But that was fifteen years ago and I understand laser imaging has progressed a great deal since then.

If the system 'knows' it's location, the device can accurately map objects in the area as you travel. It can even recognize its location and orientation by 'reading' surrounding objects, so it can correct GPS by triangulating off of know landmarks. It can distinguish between static (fixed or stationary) objects and dynamic (moving) objects. Comparing known objects (whether on a chart or a GPS indexed data source) can greatly enhance local data, not the least of which are obstructions, markers and buoys. The question is how do you use this data to improve AP use?

Sharing data with nearby vessels can help produce hyper-accurate coastal survey maps and charts. As you sail, you map automatically. So, how about turning OCPN into the ultimate P2P nautical net? The beautiful thing is, if you are updating a chart data source, all you need to transmit is data NOT listed in the incoming data index or the data that IS listed, but is older than yours. Of course, the same holds true for data recieved. The updates can be stored in a data table and displayed as a layer.

Imagine if you will, your charts and other data being seamlessly and automatically updated with corrected depth/GPS pairs, obstructions, hazards, channel markers, buoys and information on fuel docks, dockage, provisioners, shipyards, marinas, etc., every time you pass another OCPN vessel or get a WiFi connection! It can even be accomplished over a cell net. And everytime a sensor adds usable data, it is propagated across the entire OCPN community via short-range transceiver for P2P or uploading data to the website of your choice.

Hopefully my suggestions might help you expand OCPN's functionality, especially as it applies to organically updating both charts and local knowledge and further, as it applies to AP use. It would be nice if your system could be updated with the hazardous objects the boat approaching you just passed - and then have your AP steer around them - automatically.

Thanks for listening and in closing, I would like to say, Arrrh!
__________________
Kindest Regards,
Phillip
CareKnot is offline   Reply With Quote
Old 09-02-2018, 09:24   #159
Registered User
 
rgleason's Avatar

Join Date: Mar 2012
Location: Boston, MA
Boat: 1981 Bristol 32 Sloop
Posts: 11,551
Re: Autopilot Control

Dear CareKnot, We enjoy these kinds of discussions. I know Sean will appreciate the ideas too. Your light/laser scanner idea comes very close to a discussion we had about sensing waves which is needed to anticipate for the autopilot, to possibly steer around the big ones and optimize the route.

Data sharing and storage between boats would be a great bountiful resource and the pieces are slowly coming together.

I hope you'll continue to participate in this discussion. Thanks.

PS the 97 page PDF is certainly comprehensive. I'll dive in at some point. Take a look at Sean's Pypilot!
rgleason is offline   Reply With Quote
Old 09-02-2018, 11:45   #160
Registered User
 
CareKnot's Avatar

Join Date: Sep 2016
Location: Greater Houston Galveston Metroplex
Boat: 1979 Endeavor 32
Posts: 337
Re: Autopilot Control

Quote:
Originally Posted by rgleason View Post
Dear CareKnot, We enjoy these kinds of discussions. I know Sean will appreciate the ideas too. Your light/laser scanner idea comes very close to a discussion we had about sensing waves which is needed to anticipate for the autopilot, to possibly steer around the big ones and optimize the route.

Data sharing and storage between boats would be a great bountiful resource and the pieces are slowly coming together.

I hope you'll continue to participate in this discussion. Thanks.

PS the 97 page PDF is certainly comprehensive. I'll dive in at some point. Take a look at Sean's Pypilot!
EDIT: Still looking for a bare-bones AP motor controller that speaks NMEA 183.

Rick, the PDF is an engineering student's 'Final' project from 2010, so it contains a lot of explanations for the choices made. It is also very dated. However, I chose this simply as an example of how it had been done cheaply.

I'm sure there are other solutions more suitable to this cause. Arduino and Raspberry are good candidates, though I haven't investigated this in any depth. From what I've seen, these are self-contained, programmable and highly customizable solutions that can be interfaced with OCPN. See: ArduPilot Open Source Autopilot
__________________
Kindest Regards,
Phillip
CareKnot is offline   Reply With Quote
Old 09-02-2018, 13:32   #161
Registered User
 
rgleason's Avatar

Join Date: Mar 2012
Location: Boston, MA
Boat: 1981 Bristol 32 Sloop
Posts: 11,551
Re: Autopilot Control

Thanks, see Sean's Pypilot pypilot - open source marine autopilot
Github https://github.com/pypilot/pypilot

autopilot computers - pypilot store
controllers - pypilot store

http://forum.openmarine.net/showthread.php?tid=611
rgleason is offline   Reply With Quote
Old 09-02-2018, 15:34   #162
Registered User
 
transmitterdan's Avatar

Join Date: Oct 2011
Boat: Valiant 42
Posts: 4,537
Re: Autopilot Control

There are no NMEA messages defined that seem suitable for talking to a stepper motor controller.

Anyway, i donít know any AP systems that use stepper motors. The reasons are varied but in the end itís about cost. A simple PWM driver is adequate to the task and much less expensive than a stepper controller. All the AP drives I have seen are simple DC motors with a fairly traditional servo control loop. Maybe there are new AP drives with steppers but I havenít seen one yet.
transmitterdan is offline   Reply With Quote
Old 09-02-2018, 16:16   #163
Registered User
 
CareKnot's Avatar

Join Date: Sep 2016
Location: Greater Houston Galveston Metroplex
Boat: 1979 Endeavor 32
Posts: 337
Re: Autopilot Control

Quote:
Originally Posted by transmitterdan View Post
There are no NMEA messages defined that seem suitable for talking to a stepper motor controller.

Anyway, i don’t know any AP systems that use stepper motors. The reasons are varied but in the end it’s about cost. A simple PWM driver is adequate to the task and much less expensive than a stepper controller. All the AP drives I have seen are simple DC motors with a fairly traditional servo control loop. Maybe there are new AP drives with steppers but I haven’t seen one yet.
Hi Dan,

Thanks for that. I should have thought of the cost factor but I was looking for examples of functionality. I'm pretty far removed from current electronics so it's been a learning experience. The first link I posted above is using NMEA 183 sentences from a GPS unit to control an RC boat and that was 8 years ago. The recent arduino solutions do too. But these are small stepping motors so I assume the costs are feasible.
__________________
Kindest Regards,
Phillip
CareKnot is offline   Reply With Quote
Old 09-02-2018, 16:24   #164
Registered User
 
boat_alexandra's Avatar

Join Date: Aug 2009
Location: chesapeake bay
Boat: bristol 27
Posts: 3,345
Re: Autopilot Control

I sailed today for the first time with the autopilot route plugin.

The results were good in "route position bearing" mode. This is the mode that does not use xte, but instead finds the optimal position to steer to that is (I set to 100) meters ahead, and takes that bearing. This means a continuously changing bearing.

I have several bugs to fix, and I did change opencpn, so it won't be available until the next beta series.

Quote:
Originally Posted by CareKnot View Post
Morning Captain Gleason,

Anyway, check out this PDF. It is dated 2010, but it was the first thing I came across and it looks like an easy conversion to drive an AP stepping motor: http://www.diva-portal.org/smash/get...476/FULLTEXT01
This level of precision is nice, but not really useful on an autopilot because the precision of a brushed motor is an order of magnitude less than what the autopilot compensates for in normal operation anyway.

We don't need to print things, or make a laser cutter or 3d printer for example... just move the rudder a few degrees +- 10% is ok. I'm not saying stepper motors won't work, they absolutely do, but generally, unless the stepper motor is closed loop (has shaft position feedback to the controller) it will be less efficient than other types of motors. If it is closed loop, it becomes much more efficient, on par with brushless motors, and also very accurate, but becomes more expensive, maybe worth it. Check out the mecharduino project.
Quote:
So, for the sake of argument, let's say we have accomplished that goal and are driving your AP stepping motor to control your helm directly with OCPN. In my mind, that is only a small part of the ultimate goal of OCPN as the ultimate onboard nav and marine data network solution. So how can we get more usable data into OCPN and how do we share it?
signalk
Quote:
Without getting too technical, it's pretty easy to build a network that can collect data from onboard devices. Sharing it in a meaningful way isn't always so easy. That is a large part of this conversation. But what if there were another approach? A holistic approach that would allow course adjustments based on verified sensor data and shared data from other vessels that have recently transited the area you are heading towards?
There is ais, but transmitters are out of reach for many people (very expensive)

As for sharing the data. I have considered the idea of using wifi for this for passing vessels, but generally it's impractical. It might be more useful in anchorages.
Quote:
Building a device that can 'see' through fog, smoke, glare and darkness to yield vector data and images is not all that difficult. Fifteen years ago, we built a scanning laser that would return a raster pattern of vector data 'hits'. Research took a little time. Building it took much less.
Would the laser be dangerous? Scanning the waves would be useful, would it get returns from water?
Quote:
If the system 'knows' it's location, the device can accurately map objects in the area as you travel. It can even recognize its location and orientation by 'reading' surrounding objects, so it can correct GPS by triangulating off of know landmarks. It can distinguish
Already GPS is more accurate than your corrections from a moving vessel in most cases. Now there are european and russian satellites to make it very accurate.
Quote:
between static (fixed or stationary) objects and dynamic (moving) objects. Comparing known objects (whether on a chart or a GPS indexed data source) can greatly enhance local data, not the least of which are obstructions, markers and buoys. The question is how do you use this data to improve AP use?
Having eyes on the autopilot is a long term goal of mine. The vision would be used in the same way as image recognition is utilized by driverless cars.
[quote]
Sharing data with nearby vessels can help produce hyper-accurate coastal survey maps and charts. As you sail, you map automatically. So, how about turning OCPN into the ultimate P2P nautical net? The beautiful thing is, if you are updating a chart data source, all you need to transmit is data NOT listed in the incoming data index or the data that IS listed, but is older than yours. Of course, the same holds true for data recieved. The updates can be stored in a data table and displayed as a layer.
[quote]
There is a serious issue with mis-trusted data, and poorly calibrated sensors. Depth sensors need to know the water temperature and to a lesser degree the salinity.

These factors change, and even if the temperature is measured at the surface, it cannot be easily measured for the entire water column.

Furthermore, even with tidal corrections, low pressure systems also affect water levels, as well as rainfall. It is difficult to deal with this. The best bet would be to map relative water depth finishing the survey at the starting point.

Consider the case of navionics sonar charts. They tried to do what you describe, and failed at it, causing numerous boats to run aground. Now the data might be interesting but cannot be considered reliable.

Quote:
Hopefully my suggestions might help you expand OCPN's functionality, especially as it applies to organically updating both charts and local knowledge and further, as it applies to AP use. It would be nice if your system could be updated with the hazardous objects the boat approaching you just passed - and then have your AP steer around them - automatically.

Thanks for listening and in closing, I would like to say, Arrrh!
The question of hazardous objects can be dealt within opencpn. A camera can see other boats much like a human would, and then alarm is sounded and from there, the autopilot could be commanded to evade.
boat_alexandra is offline   Reply With Quote
Old 10-02-2018, 05:14   #165
Registered User
 
rgleason's Avatar

Join Date: Mar 2012
Location: Boston, MA
Boat: 1981 Bristol 32 Sloop
Posts: 11,551
Re: Autopilot Control

Quote:
This level of precision is nice, but not really useful on an autopilot because the precision of a brushed motor is an order of magnitude less than what the autopilot compensates for in normal operation anyway.

We don't need to print things, or make a laser cutter or 3d printer for example... just move the rudder a few degrees +- 10% is ok. I'm not saying stepper motors won't work, they absolutely do, but generally, unless the stepper motor is closed loop (has shaft position feedback to the controller) it will be less efficient than other types of motors. If it is closed loop, it becomes much more efficient, on par with brushless motors, and also very accurate, but becomes more expensive, maybe worth it. Check out the mecharduino project.
mecharduino https://www.kickstarter.com/projects...strial-servo-m

Sean are these strong enough and fast enough?Overview of Specification
Microcontroller: SAMD21G18A

Encoder: AS5047D
Motor Driver: A4954
Motor included with Mechaduino 0.1 Servo: 17HS16-2004S1
Magnet: Diametrically Magnetized NdFeBr
__________________

rgleason is offline   Reply With Quote
Reply

Tags
autopilot

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes Rate This Thread
Rate This Thread:

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are Off
Pingbacks are Off
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
valid sanitation control exemption control certificate dwedeking2 Training, Licensing & Certification 1 21-02-2017 10:04
For Sale: Seafire control module, remote display, control BobH260 General Classifieds (no boats) 0 28-08-2016 07:29
New Autopilot Control, old Autopilot motor Pablo Danic Marine Electronics 3 28-06-2016 23:28
Replacing Dual Lever Control with Single Lever Control ? Alecadi Engines and Propulsion Systems 47 03-12-2011 17:16
Want To Buy: ST600R Autohelm Autopilot Control Unit sonaps Classifieds Archive 2 11-07-2011 16:16



Copyright 2002- Social Knowledge, LLC All Rights Reserved.

All times are GMT -7. The time now is 02:34.


Google+
Powered by vBulletin® Version 3.8.8 Beta 1
Copyright ©2000 - 2018, vBulletin Solutions, Inc.
Social Knowledge Networks
Powered by vBulletin® Version 3.8.8 Beta 1
Copyright ©2000 - 2018, vBulletin Solutions, Inc.

ShowCase vBulletin Plugins by Drive Thru Online, Inc.