Connect RPi to Ardu using GPIO & UART

Blue Robotics Software BlueOS
1

Hi,
I’m trying to connect my pixhawk (Aurdupilot) to my RPi using the Telem2 port and GPIO pins, as I don’t have the space in my enclosure to connect via USB.

I initially followed this
https://ardupilot.org/dev/docs/raspberry-pi-via-mavlink.html
Except for the following:

  • I think BlueOS already has the correct options enabled for UART
  • Mavproxy is no longer used so I’m using Mavlink-routerd
  • Also changed the baud rate in the pixhawk as people seem so suggest to 57600.

So I’ve successfully got my Mavlink messages to my qgroundcontrol computer by running the following in the terminal of BlueOS docker environment:
mavlink-routerd -e 192.168.1.13:14550 /dev/serial0:57600

However, I don’t know how to make that persistent between docker reboots or full reboots.

I know there’s a mavlink-router config file I could create, but would that file get deleted between reboots? Is there anywhere I could store that file in the docker container that would be persistant?

Also, I don’t know how to get the autopilot data to come through to the BlueOS interface, e.g. I’m not seeing any Mavlink in the Mavlink inspector, and I’m not able to use the Autopilot firmware or parameter update functionallity of BlueOS, as BlueOS doesn’t seem to see the Autopilot.

Is there an endpoint I can add to my mavlink-routerd command to allow me to see the Autopilot in BlueOS? In the same way it shows up when I connect via USB?

2

Hi,

I’ve worked on it a bit more, and see that when the Pixhawk is connected through USB, Ardupilot manager is starting up the endpoints automatically

Is there a way I can get it to detect that my serial connection is there?

image
image1748×88 8.92 KB

I’ve just ran the following script from the terminal:
mavlink-routerd /dev/serial0:57600 0.0.0.0:14660 -e 192.168.1.13:14550 -e 127.0.0.1:14000 --tcp-port 5777 -l /root/.config/ardupilot-manager/logs

And I can see the mavlink data coming through in the mavlink inspector, and the heartbeat signal is now working. But I can’t see it being detected in the ardupilot firmware manager and reflash the firmware in the pixhawk unless connected via USB into the Pi.

I’m worried that I’m fudging it here by forcing the mavlink with this command.

Two questions:

  1. Can I make a bash script run on startup from within the docker container to run that command?
  2. Is there something better I could be triggering, or is there a setting I can change to make blueOS recognise the Ardupilot on the Serial0 and let it do the endpoints for me?

Thanks, any help or re-direction is greatly appreciated.

Regards,
Kieron

3

Hi @XYZEng,

I believe you should be able to just set up your serial endpoint from the MAVLink Endpoints page in the BlueOS web interface (requires Pirate Mode). Those should be persistent across reboots.

If that doesn’t work then we may need to modify the ardupilot manager service to allow starting from a non-default port, or just add that port to the defaults.

4

Hi Eliot,

Thanks for your response.
I tried adding the MAVLink endpoints first, but it seems to require the BlueOS to be receiving MAVLink to work.
Note my script specifies /dev/serial0 instead of the usual /dev/ttys0 or /dev/ttyAMA1.

BlueOS doesn’t seem to be looking for /dev/serial0, hence why it’s not receiving my MAVLink data.

I believe if I could specify Serial0 as the input source in the MAVLink Manager, I could then send the data to the appropriate endpoints using the endpoint manager.

While searching the code for “Serial1” in the ArduPilotManager code, I noticed that /dev/serial0 isn’t being checked.

Note - Serial0 is the GIO pins 8 and 10 on the Raspberry Pi, and seems to be the easiest way to connect them while avoiding USB.

My questions are:

  1. Is there an easy way to include Serial0 in the MAVlink Manager?
  2. If not, is it easier to run the mavlink-routerd script on Docker startup? And would running the script cause me to miss out on any functionality?

Regards,
Kieron

image

image
image757×597 30.4 KB

5

We had some internal discussion on this last week, but I’ve just realised I didn’t actually respond to you - sorry!

The current state of things is discussed here. Basically, non-USB serial ports aren’t checked for at the moment in the autopilot detection functionality, and there is not currently an override option to manually specify a path.

Beyond that, our software team is confused as to where your serial0 comes from.

Given the ardupilot manager service will be failing to detect an autopilot there shouldn’t be any conflict if you manually run mavlink-routerd, but you would miss out on the manager’s functionalities like flashing firmware.

I’m not sure whether the MAVLink2REST service is reliant on our ardupilot manager, but if it is then you would also be missing the parameter setting and MAVLink browsing functionality, in which case all that would work would be the passthrough to and from the topside.

6

Hi Eliot,

Wow, thanks for the response.

Please ignore any confusion I may have caused with Serial0.
After reading your message, I just stumbled across this:

Raspberry Pi Serial Ports - section on serial devices:

image
image735×633 39.6 KB

So I tried running the script with ttyS0 instead of Serial0, and it worked for sending mavlink messages to my ground control station.

mavlink-routerd /dev/ttyS0:57600 0.0.0.0:14660 -e 192.168.1.13:14550 -e 127.0.0.1:14000 --tcp-port 5777 -l /root/.config/ardupilot-manager/logs

Does the pull request you have linked to discuss a way of adding non-usb serial ports?
If so, I’ll happily wait for the next beta update to BlueOS.

Or,

If it’s not on the cards to include non-usb serial in BlueOS (which would be understandable) -

Is there a way for me to run a bash script within the container on startup of the container?

As a workaround, I have found a persistent folder (userdata) in the container, and have created a bash file in there:
/shortcuts/userdata/kd_mavlink.sh:

#!/bin/bash
mavlink-routerd /dev/serial0:57600 0.0.0.0:14660 -e 192.168.1.10:14550 -e 127.0.0.1:14000 --tcp-port 5777 -l /root/.config/ardupilot-manager/logs

and am kicking it off from the Raspian environment with this:

#!/bin/bash
docker exec blueos-core sh /shortcuts/userdata/kd_mavlink.sh

I feel like my method may not work if the userdata folder is emptied as part of an update.

I’ve read a little about making my own docker container which would run my script inside the BlueOS image, but haven’t tried that

Would I be better off waiting for an update to blueOS that detects non-usb serial devices, or is there a better way to run a script inside the docker environment?

7

It was intended to support automatically detecting them, although as is discussed there it may not fully achieve that in its current form.

I’ve raised an issue where you can track progress, in case we decide to take a different approach in a different pull request.

There’s no reason for us not to, and doing so would make BlueOS more versatile - it’s just a matter of finding the time to implement and test the functionality.

I’m not aware of a trivial / event-based one, although if you wanted to you could make a service/script that runs on your Raspberry Pi at startup, and waits for the blueos-core container to be detected as running before running your existing docker exec command.

userdata is intended for data provided by the user, so we can’t reasonably do any kind of automatic emptying - that’s not something you need to worry about.

8

Hi Eliot,
Thanks, I really appreciate the support!

I’ll run the scripts as suggested. And follow the ticket out of interest.

FYI. We’re really happy we choose the BlueROV because this community forum is so well supported.
I would highly recommend the BlueROV and Blue Robitics for that reason.

Learning how it all works has been really enjoyable too, especially how flexible and open source the system is.
I’m quite fresh to linux and serial data etc, so I’ve been using your community forum responses for the specific stuff, then asking ChatGPT about the basic stuff I should already know about e.g. what is a docker container…

Without them both I’d be lost!!

Also, I found this presentation really useful for understanding BlueOS, if you guys have any other long form presentations like that they’d probably be really helpful for a lot of people.

Thanks again!

Kieron

3 Likes
9

That’s lovely to hear, and I’ve shared it with the team - thanks! :slight_smile:

Our company mission is enabling the future of ocean exploration, and we feel a big part of achieving that is through fostering and collaborating with the amazing community of people around the world who have similar interests. It’s always great to hear when those efforts are appreciated and working (as well as feedback and ideas on how to do them better).

Many users of our equipment and software will never need to know what a Docker container is, and it’s not knowledge we expect people to have. That said, we don’t yet have great documentation for developing BlueOS itself, so our main helper information about Docker is currently in our development docs for BlueOS Extensions.

While it’s great that you’ve got the motivation to search for topics you don’t have experience with, if something “basic” or important is not readily available/findable in our documentation then please feel free to ask about it / mention it on the forum (that’s what the Feedback and Suggestions category is for), or raise an issue in the documentation repo.

We try our best to predict what information will be useful to people, and it’s possible we’ll already know that what you’re asking for is missing (or be able to point you to its location), but feedback is critical for us to know what’s not available that should be, and whether the information we do have is accessible for the people who need it. That helps us prioritise what to focus on documenting, and improves things for everyone in a similar situation :slight_smile:

Glad it was useful! It was the first conference I’ve been involved in with Blue Robotics, and the ArduPilot Developers Unconference has quite a different format and audience than the marine-robotics conferences, competitions, and trade shows we’re also frequently involved in.

A few points:

  • Presentations are challenging, because they’re time and resource intensive to make, and (at least where software is concerned) often become outdated reasonably quickly
    • Our product release videos are likely the closest thing we’ve got, but they tend to be focused on mostly the product being announced, rather than providing a broader overview of the entire system
  • Documentation is much easier to update, but it’s easy to get caught in the weeds rather than providing/absorbing high level overviews that help build a first pass of intuition

Thanks for the feedback - we’ll try to keep it in mind going forwards :slight_smile:

10

Just on the “basic stuff” I also am new to Linux, so I have a lot of stuff to learn there. Running simple commands and scripts for example.

It was only when I start going way outside the intended use of the BlueROV and BlueOS, that I needed to turn to ChatGPT. I’ve noticed that ChatGPT has a tendency to give unreliable code where it’s made a lot of assumptions, so I’m avoiding using it for large chunks of code unless I’m capable of identifying where it’s wrong.
But it’s great for a quick explanation of various words or terms and error codes I come across.

Thanks again for the help!

One last question, does the fact that the pull request has been Committed, mean that that code is now live in the “Master” version I can see in BlueOS. If so would you like me to test to see if it works?

Regards,
Kieron

11

For some context here, a pull request is a request for one or more commits (code changes) to be accepted into a particular repository branch (codebase variant). In this case Willian has committed some changes to a branch called serialportsfix that lives within his personal fork (copy) of the BlueOS codebase, and has started the process of getting those changes merged in to the master branch of the official BlueOS codebase (which is where newly developed changes are added, before they can be included in a release).

  1. Currently the pull request is marked as a draft, which indicates there are more changes or discussion planned by its developer before we should start reviewing it and planning to merge it in.
  2. If/once it gets marked as “ready for review” the status will change from grey “Draft” to green “Open”, at which point the other relevant developers will review the code changes and the commit history and determine whether it’s suitable to be merged, or if there are changes required before it’s acceptable.
  3. After any required changes have been fixed it will be approved, and could get merged in to the main BlueOS, in which case the status will change to a purple “Merged”, but if instead it’s decided that this is not a valuable feature, or it should be achieved some other way in an alternative pull request then it might get changed to red “Closed”

You can actually test the functionality even without it being merged into the official branches - if you change the remote in the version chooser to williangalvani/blueos-core then his branches should show up, in which case you can install the serialportsfix one and see if it helps.

That said, as per the discussion in the pull request it’s not expected that the current changes will actually resolve the issue (which is why the pull request is currently marked as a draft).