Trying to Connect RPI to Pixhawk 4 through telem 1-2 port

Hi everyone,

I’m trying to connect RPI to Connect RPI 3B using the GPIO 8 and 10 (TX-RX, UART0) to Pixhawk using the telem ports, but I still don’t get any connection, using either telem 1 or 2, changing baudrates, protocols, etc… the blueOS doesn’t seem to recognize the Pixhawk, BUT if I connect USB from the CUBE to USB RPI I can get the connection established and being able to see the cube on the BlueOS - Ardupilot Firmware section from the ip/vehicle/autopilot.

Thanks.

@EliotBR , could you point us to the right direction?
We would like to use BlueOS for Ardupilot (flying drones) but using the Pixhawk USB triggers all sorts of issues (ie due to safety triggers) so we need to use the Pixhawk Telem 1 or 2 or any other serial but not the USB on Pixhawk (serial0). Any direction to point us at ?

Hi @KevinTapia and @RFV-370, welcome to the forum :slight_smile:

BlueOS currently does not support non-USB serial connections for flight controllers. That’s something we’re working on making available, but is not an existing feature.

I’m not sure what’s meant by this - why would using a USB interface trigger safety failsafes?

Hi @EliotBR. Thank you for your answer!

On the other hand I also am trying to connect to the RPI (BlueOS) using the USB port and Telem from Pixhawk4, I tried Mavlink2 protocol and different baud rates but the OS doesn’t recognize the Pixhawk either, before doing the same configuration and mavproxy it worked though. should I configure the Pixhawk with a specific baud rate/protocol or other?

@EliotBR
Here is the link from Ardupilot: Telemetry / Serial Port Setup — Copter documentation
“The micro USB port (aka Serial0) is used to connect to the ground station using a USB cable. This should not be connected in flight because the flight code assumes that if it is receiving power through this port that it is on the bench and some failsafes (i.e. battery failsafe) are disabled.”

Could you point us to the code in BlueOS where is the issue and/or explain the issue - is this within BlueOS or within the Pixhawk ?

  • because Mavrouter should not have any impact on this…
    I am puzzled and interested by this issue actually ?
  • we (Kevin and I) are keen to develop new code if need be, to fork and/or add to your master as an option.
    Let us know?

This is effectively the same problem as in the issue I linked to - BlueOS currently detects “flight controller” options by matching against a limited set of USB device properties, which have been set up to detect a few specific flight controllers, and direct USB connections to cover most other relevant options.

When you’re making a USB connection to a telem port that will need to be through some form of converter, which won’t register in BlueOS as a flight controller, so it will be ignored in that context.

The potential solutions to resolve this are:

  • probe every valid serial port with MAVLink, to query whether it is an autopilot
    • we likely don’t want to do this, because sending random serial packets to unknown devices can be damaging / cause undesirable behaviour
  • create an “override” option (as briefly discussed from here), for when you know a particular serial port is an autopilot that doesn’t satisfy the existing matching rules (e.g. because it’s not a USB device, or it’s going through some converter)
    • this requires some way of manually specifying a port (or multiple) that should be considered as autopilots, likely via some sort of persistent config file, ideally with a frontend interface on the existing MAVLink Endpoints page for accessibility

Huh, I wasn’t aware of this behaviour, thanks for mentioning it - I’ve added a comment about it in the issue, and have brought it up internally.

It’s a BlueOS issue - please see the logic and links in my response to Kevin :slight_smile:

Feel free - BlueOS is open source, and contributions are welcome :slight_smile:

@EliotBR
Fine thank you we will propose a modification of

with “unrecognised” type - we will just be managing the error feedback in the Python script of the existing script that should do it fine. Do you agree?

Where do you store blueos parameters , do you have a main json we can add some parameters ?

So we could add a new parameter

manual_default_serialBoard_Id = “Platform.CubeOrange” (or what is needed)

So that one can automatically force it down.

@EliotBR
I have tracked the code up to “settings.json” but cant find where is actually located your json ?

I’ve taken some time to look at that part of the codebase. The main relevant points are that the Detector is stateless (so things need to be passed in directly, or determined dynamically), and the settings are managed by the ArduPilotManager.

Accordingly, what makes the most sense to me would be

  1. Modify Detector.detect to take in an optional serial_override parameter
  2. Allow that to flow through to detect_serial_flight_controllers, in which case
    platform = Platform.GenericSerial if port.device == serial_override else Detector.detect_serial_platform(port)
    
  3. Create set_serial_override and get_serial_override methods similar to these, but with just a string value
  4. Pass the get_serial_override output in via the detect call in ArduPilotManager.available_boards
  5. A nice frontend interface can come later (likely integrated as part of the BoardChangeDialog) - in the interim the value can be manually added to the configs/ardupilot-manager/settings.json file via the File Browser page.

Note: these changes would need to be done together with the existing pull request change, because otherwise non-USB options won’t be considered at all.

1 Like

@EliotBR @williangalvani
Why not to use the standard MavLink method to get all board information ?
https://mavlink.io/en/messages/common.html?q=#AUTOPILOT_VERSION
because here I am kind of confused of what we want to achieve:

May be it is because you want to have the info for for firmware update… But for flying drones we may not want the companion to be able to update the firmware actually.

Kevin, could you try to fork and test using hardcoded and then using MavLink method so we can avoid to be stuck and/or create another static method platform.TTL to selectable or to force the “if not NONE” with a “If NONE” and then force the if NONE to platform.TTL by default ?

That’s helpful for finding information about a connected autopilot, but assumes you already know that you have a device at the specified port that can talk MAVLink. It’s poor etiquette to send arbitrary messages to a device that may not support them, and could even damage the device if it doesn’t have robust handling of messages it doesn’t understand, or if it misinterprets the message.

The idea here is that we want to determine which connections are autopilots before trying to communicate with them using MAVLink. The current approach in BlueOS just uses the information provided by the USB protocol, but that doesn’t apply to direct serial connections, which is why we’re discussing alternatives to start with.

As discussed above, the most reasonable thing at this stage seems to be adding support for an override, so if a user knows that a particular serial port is a connection to a flight controller they can specify that directly, so that BlueOS knows it can safely treat that port as an autopilot.

1 Like

Hi Eliot. I noticed also that the Docker is not changes persistent after reboot, silly question: how could I manage to modify the files from the /services dir for faster testing/debugging?

Thanks for your time.

One of Docker’s primary features is that modifications to/in a Container do not affect the underlying Image, so if a modification messes something up it’s possible to restore to a fresh state by restarting the Container, without needing to manually revert code/files or restart the whole computer it’s running in.

Accordingly, persistent changes are only possible by either

  1. Modifying files mounted to the Container’s filesystem rather than stored within the Container (e.g. for simple settings / configuration changes), or
  2. Modifying the source files, building a new Docker Image, and running it
    • BlueOS’s Docker Images get built and uploaded to DockerHub automatically, using GitHub Actions if the appropriate variables (search that file for secrets) are available in your GitHub Secrets (in which case they can then be installed from your dockerhub remote instead of the Blue Robotics one), but you can also build images manually+locally for faster testing, and upload them to your vehicle via the manual upload option