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
remote boatimu
#1
How could I make pypilot use the imu data of a remote boatimu? pypilot_boatimu seems to ignore ~/.pypilot/pypilot_client.conf

I have my tinypilot built into a tiller pilot, including the imu, but when the tiller pilot is not in position, it seems the calibration gets messed up, despite locking the calibration when I swing it out of position. I want to replace my boat's commercial electronic compass anyway with an additional tinypilot connecting to openplotter's signalk database. So it would be great if my autopilot-pypilot could use the IMU data from that additional boatimu. 

Thx!
Reply
#2
This is something I am very interested in as I want to split off the IMU from the auto pilot - primarily for redundancy and the ability to perhaps in the future build one of the ZED-F9 GNSS modules capable of millimetre 3D-fixes & RPY & heading accuracy that is just mind-blowing.

Looking at the code, it's not straightforward but it is possible - I'm still learning Python as all my previous programming (inc a drone IMU) has been with C & AVR Assembler
Reply
#3
I don't think using a remote imu is a good idea or intended because of the lag between reading the sensors and reacting with the motor.


Instead, consider fixing a tinypilot to the boat in a good location (not inside tillerpilot) Then use a remote on the tiller pilot. The options for a remote:

1) 433mhz remote. I have built and have the source code and schematic for this. You can use universal 433mhz remotes
2) wifi remote. based on esp32 this gives the same display as the tinypilot with configuration abilities but connects over wifi. I have two size screens working, these are ttgo display variety
3) tinypilot in remote mode. You can use a second tinypilot and connect to the wifi of the master tinypilot. This gives the same function as #2, but is higher cost because a raspberry pi is used instead of esp32. The advantage is, it could be a backup if the primary fails if you have inertial sensors, otherwise you do not need inertial sensors for this pi.
Reply
#4
(2021-04-02, 01:42 AM)seandepagnier Wrote: I don't think using a remote imu is a good idea or intended because of the lag between reading the sensors and reacting with the motor.

Still, it's what I want to try; if the IMU refresh rate is 100ms I don't mind losing a few millisecs on wifi pingtime. I think I can get boatimu connect to a remote pypilot through configuration of pypilot_client.conf and similar changes (below), but I can't test it now yet. I'll let you know the results, positive or negative. 


Code:
pi@openplotter:/usr/local/lib/python3.7/dist-packages/pypilot-0.23-py3.7-linux-armv7l.egg/pypilot $ diff ~/pypilot/pypilot boatimu.py
37,39c38,42
<         self.client = pypilotClient(server)
<         self.multiprocessing = server.multiprocessing
<         if self.multiprocessing:
---
>         self.client = pypilotClient()
>         #self.multiprocessing = server.multiprocessing
>         if False:
310c313
<         if True:
---
>         if False:
316c319,320
<         self.client = pypilotClient(server)
---
>         self.client = pypilotClient()
342c346,347
<         self.auto_cal = AutomaticCalibrationProcess(client.server)
---
>         self.auto_cal = AutomaticCalibrationProcess(client)
365c370
<         self.imu = IMU(client.server)
---
>         self.imu = IMU(client)
386c391,392
<         if self.imu.multiprocessing:
---
>         if False:
396c402,403
<         if not self.imu.multiprocessing:
---
>         if False:
516c523,524
<     client = pypilotClient(server)
---
>     client = pypilotClient()
Reply
#5
Quote:Still, it's what I want to try; if the IMU refresh rate is 100ms I don't mind losing a few millisecs on wifi pingtime.
It isn't deterministic. You do not have guarenteed latency. So unless you use a dedicated wireless link (not using raspberry wifi at all) for this, you may end up with something that works most of the time but occasionally does not react. I have seen wifi on raspberry link get stalled up to a few seconds.


If you want a wireless link somewhere between the imu sensors and the motor moving the rudder it needs dedicated link, either two esp32, or some other rf link that does not use linux wifi/bluetooth stack.
Reply
#6
Ok that's a very clear and convincing argument. Thx.

This ideosyncretic idea stems from my requirement to have a pypilot that is 100% interchangeable with my backup, commercial tiller pilot, both electrically and UI-wise. If pypilot would fail, i simply swap it. This has not happened over the last year, which is testament to the design! The remote imu idea is an attempt to optimise that concept, because an imu that regularly swings out of position is hard to properly calibrate.
Reply
#7
Hi Sean
Are you selling the esp32 WiFi remotes?

Thanks
Andrew
Reply
#8
(2021-04-04, 01:10 PM)andrewAB Wrote: Hi Sean
Are you selling the esp32 WiFi remotes?

Thanks
Andrew

not yet but I support two different ttgo designs which have lcd displays
Reply
#9
(2021-04-02, 08:55 PM)seandepagnier Wrote:
Quote:Still, it's what I want to try; if the IMU refresh rate is 100ms I don't mind losing a few millisecs on wifi pingtime.
It isn't deterministic.  You do not have guarenteed latency.  So unless you use a dedicated wireless link (not using raspberry wifi at all) for this, you may end up with something that works most of the time but occasionally does not react.  I have seen wifi on raspberry link get stalled up to a few seconds.


If you want a wireless link somewhere between the imu sensors and the motor moving the rudder it needs dedicated link, either two esp32, or some other rf link that does not use linux wifi/bluetooth stack.

This is an old post of yours but curious if your thoughts have changed. I'm just getting started with the whole OpenPlotter setup, have all the parts and have been playing with a few ESP32's for sensors around the boat. I love the way I can connect the sensors wirelessly and so, naturally, I thought why not the IMU via an ESP32 as it's time to start working on the autopilot. Then I got thinking about latency, lapses due to interference, etc.

Then I got thinking about mounting, you'd want the IMU mounted as close to the actual rudder as possible, and along the centerline of the boat I'd guess so that it "feels" what the rudder has to work with. That puts my RPi5 quite a ways away.
the 
Is it best practice to have a second dedicated Pi or similar for pypilot running as close as possible to the IMU and then an NMEA0182 from the Pi to the ST4000's controller?

Sorry, I'm sure this has been covered, I've tried searching but the forum search is a little wonky, and I've been considering the ESP32s wirelessly until now so maybe looking in all the wrong places.
Reply
#10
pypilot in remote mode just allows a second raspberry pi to act as an additional control head. It has the lcd display and potentially buttons or remote control but the actual core pypilot process runs in a different pypilot that has the imu.


There should be no wifi links between the gyros and the motor controller. The imu does not need to be anywhere near the rudder in fact it is best near the center of the boat, but the actual position is not critical.
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)