Is QGroundControl needed to control my rover or can I use a BlueOS extension?

[EliotBR (Eliot)]

@grantdutoit

It would be great to chat.

I’ve sent you an email.

@grantdutoit

My developers would like about how you may advise we go about integrating our stack with BlueOS and perhaps QGC.

You’ll need some form of extension for the integration side of things (communicating with your peripheral board), and then you’ve got a few options for the interface:

• include it in your integration extension
• develop it as a separate extension, possibly together with us
• modify QGC to support the data display and input options you need
  • QGC tends to be somewhat difficult to add functionalities to, and is an extra dependency required off the vehicle, so I probably wouldn’t recommend this one
• some hybrid option of the above

@grantdutoit

In a previous version, we created our own control platform using Vue …

This is cool to see - thanks for sharing!

@grantdutoit

• The joysticks use MAVLink in QGC, can a Logitech Extreme 3D Pro joystick be directly integrated into BlueOS and if so, how do we do it? If not directly into BlueOS, I guess this would be part of the extension? Perhaps pulling in parts of QGC into an extension?

Our Cockpit extension has joystick support already - there’s a browser-based joystick API that make this kind of thing possible, although it’s a fair amount of work to get implemented in a generic way with support for quite arbitrary joysticks. If you only need a single type of joystick that does simplify things somewhat, because you can use a hardcoded mapping.

@grantdutoit

• The motors in use are steppers requiring PWM (speed) and DIO (direction). How do we get two stepper motors working via their motor drivers in BlueOS or would this require an extension? I believe MAVLink is used to control steppers via the driver.

It’s not clear to me what your electronics stack includes. In the case of our Navigator board we control our thruster motors using servo-style signals from the ArduSub autopilot firmware, but as far as I’m aware ArduPilot firmwares don’t have any stepper motor support, and since you’re using your own electronics it may be quite a lot of work to configure a suitable ArduPilot firmware for your vehicle anyway.

I’m not sure what you mean on your last point there.

@grantdutoit

• Most of the cameras are IP with one camera being a PTZ IP. Can BlueOS be used to control the PTZ camera or is this going to be part of an extension? Perhaps this link, Handling custom camera feeds (without MAVLink?) may be of use? I found this link, Gimbal Protocol v2 · MAVLink Developer Guide, which speaks of a gimbal manager being built into the autopilot. If it works and was included into BlueOS, perhaps that could be a way to control a PTZ camera position? If using MAVLink would give a time advantage, we’re happy to use it as it seems we’re going to need it for other peripherals.

To clarify some points:

• BlueOS is the extensible high-level software that runs on the Raspberry Pi (Onboard Computer)
• The core BlueOS functionality includes being able to run an autopilot firmware belonging to the ArduPilot-family (like ArduSub) when the Onboard Computer is used as a host for a flight controller board like our Navigator
  • Other flight controller boards (like a Pixhawk) are freestanding and run the autopilot firmware internally (no host required), but they can still interface with a Raspberry Pi using BlueOS as a Companion Computer (generally via a USB connection)
• ArduPilot firmwares communicate to other devices using the MAVLink communication protocol, but control their internal components using whatever protocol is appropriate for that sensor/actuator (e.g. the motors commonly use servo-style PWM signals, our external pressure sensor uses I²C, etc)
• BlueOS also contains a camera manager, which allows configuring video streams from USB cameras, and redirecting RTSP streams (e.g. from an IP camera), then presenting those via the MAVLink Camera Protocol for easy discovery by a software like QGroundControl
  • This is unrelated to and independent of the autopilot functionality
• recent ArduPilot firmwares have some functionality built in for interfacing with gimbals that are able to communicate using MAVLink, but if your PTZ camera does not present itself that way (which is likely the case) then that’s not relevant to you
• BlueOS does not have any built in gimbal support outside that provided by the autopilot firmware (if one is running/connected), so this would likely need to be implemented via an integration extension

@grantdutoit

• There are four indendent LEDs, can these be controlled with BlueOS or does this require an extension? These are the first release BR2 LEDs. I see LEDs can be controlled by MAVLink however I believe BlueOS doesn’t come packaged with MAVLink as standard which means BlueOS has to control the LEDS.

If you have a flight controller + MAVLink-enabled autopilot combination with “relay” support (e.g. Navigator + ArduSub) then BlueOS can pass along MAVLink commands from the topside to control those relays. Otherwise the signals will need to be passed to something else, likely via an extension.

@grantdutoit

• We the BME280 to monitor pressure, humidity and temperature. We are placing a sensor in each peripheral and in the main enclosure. We use I2C to communicate via multiplexors to make addressing easier - don’t have accidents if the address isn’t changed on the sensor.

ArduPilot firmwares have a library for interfacing with BME280 sensors, but I believe you can generally only have one of the same sensor type connected to the same bus, since the I²C addresses are hardcoded. There’s also a limit of 3 pressure sensors in a single autopilot. Both of those could be worked around by compiling a custom autopilot firmware, although it’s likely a fair amount of effort to learn enough about the ArduPilot codebase to modify those features.

You could instead just talk to the sensors directly from a BlueOS Extension.

@grantdutoit

• We use the MAX9611/MAX9612 to monitor power, current and voltage in various locations such as motors, LEDs, cameras etc. Each channel that gets powered goes through one of these so we can tell if all is well or not.

I don’t believe the MAX9611 is supported in ArduPilot, so if you wanted to use an ArduPilot firmware you’d need to create a driver for it.

Alternatively you could talk to them directly from BlueOS, which still requires a driver but the interfacing code could be isolated to only your own dependencies and programs, instead of needing to be integrated into ArduPilot.

@grantdutoit

We plan to display these values on the pilot GUI either on BlueOS as an extension or through QGC. The problem with QGC is that we need to accommodate the large numbers of sensors which QGC doesn’t currently cater for. As a result, we thought going straight for an extension may be better.

Either of these approaches is technically possible, but I expect displaying things in a BlueOS extension should be simpler than modifying QGC to display lots of new things, especially if you don’t want MAVLink to be a requirement for you data, and/or don’t want every display value to need a bunch of hardcoded boilerplate.

@grantdutoit

• Does BlueOS have MAVLink? My understanding is that MAVLink is not integrated anymore, Handling customized mavlink packets with BlueOS/mavlink-routerd . Thoughts are around the ability to integrate items such as the joystick and other potentially MAVLink reliant peripherals.

MAVLink is a communication protocol. BlueOS has a number of tools that use MAVLink to operate.