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
Best of both worlds?
#11
(2020-02-25, 05:29 PM)Ranur Wrote:
(2020-02-25, 05:16 PM)seandepagnier Wrote: I got esp8266 communicating with pypilot for possible wireless remote.

the esp8266 doesn't have enough ram to run the pypilot scripts in micropython.   So a simpler tcp client is needed but it works ok and can command pypilot using gpio.

Rather than write the lcd rendering bit in c, I will try an esp32 and see if it can run the same python script used on the pi..   If it can, it might eventually be viable to run pypilot itself on the esp32 which would probably be ok for the basic pilots but not machine learning.


I am thinking more in using OP on the RPI, with your motor controller (tucked away in a bench outside the ST1000+ and just use the mechanical hardware of the ST), and to ADD an ESP inside the ST1000 to get push button functionality at hand ON the ST1000, using it's original buttons. Doable?

Yes, I have a python script that works with micropython and can set and retrieve values from pypilot as well as read from gpio.


Attached Files
.txt   pypilot_remote.py.txt (Size: 1.89 KB / Downloads: 13)
Reply
#12
(2020-02-25, 08:17 PM)seandepagnier Wrote: Yes, I have a python script that works with micropython and can set and retrieve values from pypilot as well as read from gpio.

But if that code works with micropython, then you can probably use this on your ECD https://github.com/marcobergman/pypilot_...ter/ray.py with some changes. It emulates the original raymarine button functionality, adding a bit more functionality to adjust gains while in operation. You can remove the 'bell' and 'remote' code.

The raymarine-style functionality distinguishes between 'auto' (=compass) and 'track' (=gps) modes, making it possible to choose between the two modes at your descretion. I had to make some modifications to the pypilot code to make this work. I have not documented these modifications yet, but if you are going to reuse this code I will first have to confess the details of these cardinal sins to Sean Wink because those modifications might have some undesirable side-effects.
Reply
#13
I like this - I'm not quite there yet. (As I ran into some pypilot problems with my log files yesterday...) I just want to make sure I get the concept before I order the controller from Sean. ;-) And I have already looked at and drooled over your Ray.py... :-D
Reply
#14
(2020-02-25, 09:24 PM)ironman Wrote:
(2020-02-25, 08:17 PM)seandepagnier Wrote: Yes, I have a python script that works with micropython and can set and retrieve values from pypilot as well as read from gpio.

But if that code works with micropython, then you can probably use this on your ECD https://github.com/marcobergman/pypilot_...ter/ray.py with some changes. It emulates the original raymarine button functionality, adding a bit more functionality to adjust gains while in operation. You can remove the 'bell' and 'remote' code.
Yes it probably works. You didn't correctly use the server but I am not sure the bell code is functioning?

I am more interested in having a wireless remote with small lcd display, but it could beep also.
Quote:The raymarine-style functionality distinguishes between 'auto' (=compass) and 'track' (=gps) modes, making it possible to choose between the two modes at your descretion. I had to make some modifications to the pypilot code to make this work. I have not documented these modifications yet, but if you are going to reuse this code
What did you need to change? It should be possible to change the mode.
Reply
#15
The bell-related code chimes a sound on my laptop each 5 seconds when there is a waypoint arrival, 1 times for a starboard change and twice for a port change of heading. It's a bit ugly code but it works.

When switching to 'compass' when there is an active route, pypilot normally goes back to 'gps' mode, as discussed in this thread. I had to solve this in the pypilot code. Also the waypoint confirmation logic had to be integrated into nmea.py. Still being a python newbie, I struggled a bit and resorted to the use of global variables, so please have mercy on me Tongue . Attached the changes I made.

The set of measures I took make that my PyPilot-powered tiller pilot has exactly the same user interface as the original one, which I have as backup. They both react in the same way to OpenCPN active routes as well. So when the going gets tough and the brain fogs up, you don't need to think about which tiller pilot is on duty.


Attached Files
.pdf   pypilot-git-diff.pdf (Size: 106.33 KB / Downloads: 10)
Reply
#16
(2020-02-26, 04:04 PM)ironman Wrote: The bell-related code chimes a sound on my laptop each 5 seconds when there is a waypoint arrival, 1 times for a starboard change and twice for a port change of heading. It's a bit ugly code but it works.

This is nice. I don't think bells needs to be integrated into pypilot directly but through your control client is ok..

It would make most sense to me that opencpn can do this through the autopilot route plugin.

Quote:When switching to 'compass' when there is an active route, pypilot normally goes back to 'gps' mode, as discussed in this thread. I had to solve this in the pypilot code. Also the waypoint confirmation logic had to be integrated into
So in this case switching to compass just holds a compass course correct?

Then switching to gps would go back to "nav" mode. It should have this behavior if you change the nmea sentence prefix.

Should there be a separate "nav" mode and now gps mode just holds a gps course, or nav mode could be whatever the chart plotter commands??

As for waypoint confirmation.. I believe this is supported already in the autopilot route plugin in opencpn. If not, is there any specific reason for the autopilot to need to deal with waypoint confirmation? To use the same remote or controls?

Quote: nmea.py. Still being a python newbie, I struggled a bit and resorted to the use of global variables, so please have mercy on me Tongue . Attached the changes I made.
I learned python to write pypilot so I am also new; not using it very long.
Quote:The set of measures I took make that my PyPilot-powered tiller pilot has exactly the same user interface as the original one, which I have as backup. They both react in the same way to OpenCPN active routes as well. So when the going gets tough and the brain fogs up, you don't need to think about which tiller pilot is on duty.
Sounds good. It would be cool to be able to have the same interface as other pilots as an option, so once we can settle on the details and the best way to implement, maybe it can just be a boolean in the config.
Reply
#17
First and for all, we do agree that if Ranur wants to proceed with building the UI into a remote ECD that seems to be feasible in the way described, right?

Additionally, for being able to run in 'compass' mode without automatically flicking to 'gps' mode when a route is active, a small change to nmea.py would be required, possibly enabled by a config switch ('boolean'). But that is not really needed for Ranur to proceed; the workaround would be to simply deactivate the route.

The rest I would like to say about waypoint arrivals I have put it in a separate thread in Feature Requests, otherwise I might scare off a potential PyPilot builder :-).

http://forum.openmarine.net/showthread.p...8#pid12698
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)