Hi, would just like to ask if the BlueOS is still running with QGroundControl or does it have another control interface?
Hi @Aquila,
BlueOS connects to the topside computer in the same way as the old Companion Software, and the vehicle is still primarily expected to be controlled with QGroundControl.
It has a significantly improved web interface over the Companion Software, but that doesn’t include control of the vehicle motion (for now 
).
Hi @EliotBR,
Thanks for the information above.
Just a few questions, the BlueOS was installed on Raspberry Pi 3B and connected to Pixhawk 4 V3.
- Why was it unable to install firmware and what was the error code “Request failed with status code 504” about?
- So the settings and controls are still the same to be controlled in QGroundControl while the companion software was changed to BlueOS?
That can happen if there are issues reaching the ArduPilot firmware server. If you have a stable internet connection then that’s likely an issue with the server itself, in which case the problem is generally resolved by just waiting a while for the server to become available again. You can also try going to the server page to see if it’s available, and if you can access it but BlueOS is still struggling to contact it then you can find and download the firmware file you’re after yourself, and install it manually via the “upload custom file” option.
As a general note, the firmware installation interface is a bit nicer and more robust in the more recent BlueOS versions, so it may be worth switching to a BlueOS beta image (can be installed via the Version Chooser while Pirate Mode is on) when flashing autopilot firmware.
QGroundControl predominantly talks to the autopilot, and the Onboard Computer software (be that BlueOS or the older Companion Software) acts as a proxy to allow that communication to happen. The things you previously did with QGroundControl (e.g. changing ArduSub parameters, controlling the vehicle, configuring your joystick, etc) can still be done with QGroundControl, and the things the Onboard Computer is in charge of (e.g. video streams, checking for Ping devices, updating autopilot firmware, etc) are available in the web interface, as they were previously.
The main changes at the moment are in the robustness and new functionalities available via BlueOS - how you interface with functionalities that were already available before should be largely the same (for now).
Hi @EliotBR,
I tried using the beta, however, seems like it can’t be downloaded. Same 504 error code is shown while trying to upload the custom file manually.
Here’s an attached of how my setup is currently running now. While Pixhawk 4 is running on the companion PC QGroundControl is also not showing the flight control. Do you have any ideas on why this is happening?
Does your BlueOS Raspberry Pi have a stable internet connection (e.g. through wifi)? If you can’t download a BlueOS update and you’re also having issues downloading an ArduSub update then perhaps those problems are related.
That’s confusing to me, as 504 is a networking related error, although perhaps there was a timeout while BlueOS was waiting for your computer to send it the file.
Can you please retrieve your latest ardupilot-manager log and upload it here? It may provide some insight.
My best guesses are
- the Pixhawk 4 is not running properly (e.g. incorrect firmware, in bootloader mode, or damaged)
- the connection hardware between the Pixhawk 4 and your Raspberry Pi 3B is damaged / faulty (the cable, and the connector on each end)
- there is an issue with your BlueOS install, or a bug with BlueOS that means it is not correctly detecting your Pixhawk 4 board
- there is an issue with your network setup that’s preventing the telemetry from getting through (e.g. firewall, QGroundControl lacking permissions, etc)
Hi,
Thanks for all the help @EliotBR, really appreciate it!
I’ve successfully connected everything up and running, however, my servo is not working. Do you have any ideas about why? Attached is my servo and controller setting in QGC for your reference, the servo is connected to I/O output pin 8.
On top of this, does BlueOS supports the connection of IP cameras (Onvif) at the current stage?
Hmmm, the ArduPilot docs seem to specify that the channel mapping should be I/O → MAIN, so I would expect your current configuration to work. Some things you can try/check:
- go to the
Analyze Tools/MAVLink Inspectorpage, select theSERVO_OUTPUT_RAWmessage, and see whether the channel you’re expecting is changing when you try to control your camera servo- if it’s off by 8, try changing to channel 16 in the Camera page
- potentially try one of the FMU channels instead
If the camera is on the same network you should be able to reach it from the topside regardless of what BlueOS is doing. That said, we are at least planning to have decent detection and configuration support for IP cameras, and I’m not certain what the state is of that, so I’ve asked internally and will get back to you 
1 Like
Server8_raw’s value is changing when I tried to control the camera servo but the camera is still not tilting. I’ve also tried the FMU channel as well, but the same problem persists.
My IP camera was on 192.168.2.207, the topside laptop was 192.168.2.1 and it was connected to the same network switch, cmd ping was okay, but BlueOS seems only detected the USB Camera. An error code was shown when I’m trying to add stream using camera’s rtsp. Find the attached for your reference. The rtsp are as follow: rtsp://192.168.2.207:554
VLC player was able to stream using rtsp.
In that case I’m thinking either your output isn’t connected properly, you haven’t provided power to the servo, or your servo is damaged.
Following up on this,
We do not yet have ONVIF support included. There is IP support through RTSP, but it is currently only available through the developer interface described here, not the main frontend display.