The evolution of BlueOS and features such as the Extensions Manager are remarkable. Well done! This makes me think towards future developments for my rover.
Is QGC still going to be required to control my rover if I am not using or need a mission planner? I will need a mission planner in future but experience has shown that the shortest route travelled is often the best. There are no unneeded bits in the middle.
My requirements are greater than the standard release abilities in BlueOS. For example, I have four LEDs and do not daisy chain them. I run four IP cameras and no USB or directly connected cameras to the RPi4. I use the BME280 and run 16 of them all feeding back data simultaneously. I use large NEMA stepper motors as my torque is around 120Nm out on each of the two motors. I have my own electronics stack to serve these devices. Now, I need an interface for these.
I’m hoping to use extensions and the extension manager to create an interface to manage and display the data as required. I know extensions are not viewed as stable and there will be issues along the way but if I’m not bound to QGC, then I’d love to explore an extension.
I would love to hear people’s thoughts and questions. If you have experience with developing an extension, I’d love to chat with you. Maybe you can help us write one? Many thanks in advance.
QGC is a control station software that can control vehicles over MAVLink. It is not the only such software*, and there’s no requirement to use it if your vehicle does not use MAVLink communications.
*NOTE: QGroundControl is currently the only control station software we support for use with the ArduSub autopilot firmware. There are other such softwares that cater to other MAVLink-based vehicles (e.g. MissionPlanner for copters/planes).
Custom integrations are one of the primary use-cases for Extensions, and seems like a good basis for what you’re trying to achieve.
If you haven’t already seen, we have initial extensions documentation available, which includes some examples that may be helpful for developing your own.
That said, given the overlap of functionality with “control software that can display video streams and data” it may make more sense to join efforts with us. Unfortunately we haven’t yet decided whether our control station software will be open source, so at this stage those kinds of discussions would likely need to be held privately. If you’re interested I’ll set up a chat with the relevant members of our software team.
If you’re interested I’ll set up a chat with the relevant members of our software team.
It would be great to chat. My developers would like about how you may advise we go about integrating our stack with BlueOS and perhaps QGC. We needed to add more peripherals than the Navigator catered for so we developed our own stack in the form of several boards each doing what the Navigator does in one but with quite a bit more. We used many of the same chips, such as the PCA9685, as is used on the Navigator. We have the stack working via Arduino and now need to integrate it into BlueOS via an extension and or QGC.
We are looking to use an extension instead of QGC however our deadlines are steep and not sure if there’s enough time to create an extension. In this case, we may look at using QGC for the easy wins and an extension to meet the rest.
In a previous version, we created our own control platform using Vue, which is the same as BlueOS uses. We were able to control the robot using a Logitech 3D Extreme Pro joystick. In the GUI, we could switch each peripheral on and off, dim LEDs, control motor speed and direction and view the outputs of all sensors. The end goal would be to do the same with BlueOS as the mission planner feature in QGC is not suitable for our next step with respect to navigation.
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?
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.
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.
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.
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.
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. 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.
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.
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
This is cool to see - thanks for sharing!
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.
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.
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 I2C, 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
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.
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 I2C 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.
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.
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.
MAVLink is a communication protocol. BlueOS has a number of tools that use MAVLink to operate.
