How do I connect the Modem M64 to the raspberry pi?
Hi @safaR -
Welcome to the forums!
Have you seen this guide post? It’s a bit old, but should detail everything well! A quick search for Modem M64 on the forum (and google) brought it up in the top results!
Hi @tony-white
I wanted to connect the same M64 modem from the waterlinked to the navigator and I was wondering do I need to use this converter and connect to the raspberry pi while I am using the navigator?
I just found the page where the integration for Ping1d mentioned the configuration requires the same converter if you using the pixhawk and you just connects without converted directly to the navigator board (serial 5 with i2c). I am using Ping1d on serial 5.
And consequently the 2nd question is - if I want to connect M64 modem and Ping1D can I connect to the navigator board (serial 5 to ping and serial 1 or 4 (serial 3 is used by gps)) so I can save usb port on the raspberry pi?
Nurjan
Hi @nurjan14,
The Navigator uses 3.3V as its logic level voltage, so should work ok for connecting directly to the communication pins of a Water Linked modem, assuming you disable it in the autopilot manager, or write a driver for it that you run as part of the autopilot (e.g. potentially using a Lua script).
That said, Water Linked’s retired M64 modem requires 10+V for its power supply, and their M16 modem requires ~3.3V, whereas the Navigator’s serial ports provide 5V. You can’t connect the modem’s power wire to that, and you’ll need to bridge the Navigator’s ground with the ground of the power supply you use (if that’s not done already).
Thanks @EliotBR for pointing this out.
I have additional questions t0hat might related to this one
I know for the fact there are multiple extension that support waterlniked products for example DVL and UGPS but I didn’t find the anything related to acoustic modems except for the celular modem.
Question is: If I want to have communication with my rov should I connect to the navigator utilizing it’s convience of built in 3.3v logic level voltage and if assuming there are solution that I am not aware of for BlueOS extension that already works out of box OR I should consider make custom node for both side (ROV - surface) using one of this repo .
Thanks
Hi @nurjan14 -
What are you goals for the use of the modem?
I would recommend developing a BlueOS extension, using the library you linked, to accomplish them! An extension like this doesn’t exist, because the range of potential applications is quite broad - unlike that of a DVL or UGPS, where the goal is localization.
As Eliot mentioned, simply connect to the Navigator serial port and appropriate power, remove that serial port from the Autopilot’s control, and access it with your extension.
The goal is make communication between ROV and topside when it operates in tetherless mode.
thanks @tony-white
Is this right place and this where to start to make my custom extension?
Nurjan
Hi @nurjan14 -
That would be the right documentation and example repo, yes. However…
If your goal is top operate the ROV via the modem, with it sending telemetry and control signals from your GCS, that may necessitate a completely different approach!
I’m not sure the bandwidth available from the modem is sufficient for the default control stream.
You’ll definitely want to leave the serial port you connect the modem to in the autopilot’s control, since it will use it to send data. Are you trying to drive the ROV via the modem, or just see information about the battery, or trigger a simple command to start a mission? Since the video stream won’t be able to be sent across this link, how will you drive it - from visual contact, observing the ROV, or does the unit have a localization system so it can perform missions in Auto mode?
Generally, I’m skeptical this would work at all, but hope to be proven wrong!
Certainly, it won’t work for manual control due to latency, simply not practical and not my objectives
I forget to mention that working on autonomous tasks. This is for simple communication in tetherless mode to get current status something like (mission status ….., battery status …., current local position….) and/OR trigger missions like a (start/abort/next mission /emergency surfacing ) . Localizations is based on vision+dvl —> feed to EKF.
Still figuring out this m64 modem, we bough them while ago and never used them. Now time to see how they perform. I assume I need to work on payload size and queue messaging using their discontinued library
Nurjan
Hi @nurjan14 -
In that case then yes, an extension is the right way to go. It would need to talk to the modem, and when key commands are sent, relay them to the vehicle via Mavlink2Rest. This will be tricky, but should be possible!
I would focus first on getting a “hello world” - where you send a message from the topside “ping” - and receive one back from your extension “pong”.
From there, you could use your extension to change vehicle modes, arm/disarm, etc. via pymavlink!
Thanks @tony-white I will see what I can do, for sure start with simple hello world handshake and then see what i can do with pymavlink
Nurjan
A BlueOS Extension would allow you to create a browser interface, send MAVLink commands to the autopilot, and integrate readily with non-autopilot components. The Python library could enable that, and could more generally be useful in the software you want to run on the topside (e.g. you could have a Python program that talks to the topside modem, then gives you status updates in Cockpit).
If you only want the modem to talk to the autopilot then I suspect the most robust integration is likely via a Lua script instead (which then avoids needing to develop or deploy a BlueOS Extension, or use MAVLink, at the cost of your integration being (currently) a bit less convenient for others to install).
Hi Eliot,
Can you share the documentation on the Lua script implementation for Ardusub?
Thanks
There are general ArduPilot Lua script docs, though we haven’t yet managed to fine-tune those docs for ArduSub use-cases.
For BlueOS with Navigator use-cases,
Note that you’ll need to enable scripting support with the SCR_ENABLE parameter, and you may need to create the scripts folder if it doesn’t exist already.