First off, well done on Cockpit. It looks fantastic - and I look forward to trying it out on the water soon!
Some basis questions:
You mention it will be web-based or capable of running as an application. What’s the underlying technology for this? Supported platforms/OS? In evaluating Cockpit vs. QT/QGroundControl as a software base for our own (open source) development work we’ll likely need to know this.
Love the screen/widgets approach. I take it there’ll be support for us to develop our own custom widgets (?)
In terms of an MVP as drop-in replacement for QGC - and I haven’t tested it in the water yet: it looks great but the major missing piece would be telemetry logging. Ideally configurable by variable as per QGC. Is this on the features list? Got a time frame?
Thanks! It’s not fully featured yet, but hopefully your testing goes well
The interface is Vue-based, which is packaged up into
a BlueOS extension that can serve it
this can be accessed via a web browser (Chrome recommended) that has network access to the vehicle
an Electron app that can run on common operating systems
we automatically generate application binaries for Linux / macOS / Windows as part of the release process
It’s perhaps worth noting that Cockpit is currently reliant on web-based access to the MAVLink stream and WebRTC video streams, which are provided by MAVLink2REST and MAVLinkCameraManager in BlueOS, so it’s currently not straightforward to connect to a non-BlueOS vehicle, even when using one of the Electron app binaries.
So do we!
Absolutely. It’s currently only possible to add widgets via the Cockpit codebase, but the longer term intent is to support some form of dynamic widget loading, at which point it will be possible to design freestanding widgets that can be shared with others as downloadable add-ons.
Yes, telemetry logging is a planned feature, but no fixed time frame for it at the moment.
In the interim it might be sufficient to use the DataFlash logs from the autopilot. They should be accessible (and viewable) via the BlueOS Log Browser. Note that recorded data uses a different structure (and higher frequency) compared to the directly recorded MAVLink messages that QGC stores in its .tlog telemetry log files.
Could you clarify what you mean by this?
As I understand it QGC’s telemetry logging stores all the MAVLink messages it receives, and the only configuration options are for the stream group rates from the vehicle, as well as optionally saving the telemetry data in .csv files instead of only .tlog files.
If I’m remembering correctly it does record only the currently displayed telemetry values in the .ass subtitle files that are used as overlays for video recordings, but those are not the telemetry logs.
@EliotBR we’ve also been enjoying using Cockpit in some initial testing. Looks really encouraging. One thing we have noticed is the latency on the video stream - this to us is a critical factor. Any views on why it maybe high and also inconsistent. The UI and configurability is great but if the latency isn’t low / consistent then it procludes it’s use in piloting. Direct comparison to QGC sees a marked difference on the same ROV system.
I would also encourage focus on the recording of videos with telemetry data as per the ass file in QGC, that’s vital for most of our use cases.
Exciting times, and looking forward to seeing it progress.
Has this been with a standard BlueROV2 setup? We’ve tended to find that the Cockpit latency is often lower than QGC’s. That said, there are a couple of upcoming fixes to the video pipeline in BlueOS that should improve the stability of the WebRTC streams being sent to Cockpit.
Fair enough, and good to know - I’ve flagged your interest in the issue for it (the Cockpit repo is currently private, so the issue isn’t publicly accessible yet).
Clarification on my ask around ‘telemetry logging’:
I’m really asking for the same thing as @mattcmgb . I would suggest that QGC approach of logging variables that are configured for display into the .ass file is a bit restrictive. So maybe a settings section that allows you to pick vars and then choose if displayed and/or logged.
@EliotBR Hi Eliot, We tested Cockpit on a completely standard BlueROV2 build with Navigator / Pi4 and latest BlueOS. Tether was 50m, all works as expected via QGC on same setup.
I tested Cockpit in both Chrome and Edge (not tried Firefox). It was on a Rugged Dell Lattitude 7330 laptop i7 with intel Iris X 8gb GPU. This is normally beefy enough for QGC usage.
Only thing of note is Windows 11 OS, but that’s the same for both use cases.
The latency wasn’t consistent and there was definite stuttering on the feed with pauses of a second or two.
I’ll do some digging around with other computer setups to see if it is the same.
Cheers
Matt
Hi Matthew!
Can you check if BlueOS is also connected via WiFi? We noticed that when the vehicle is connected by both WiFi and Ethernet, it tries to use the WiFi sometimes, causing stuttering. In this case, try disabling the WiFi and reloading the Cockpit tab.
Hi Rafael,
It definitely would have had a wifi connection as well, we were testing on the bench in the workshop. I’ll test without wifi and report back.
Cheers
Matt
A quick update on this - I can confirm that Rafael was correct. When the ROV is not connected to a wifi network, there was no latency/glitches in the video feed in Cockpit. It’s a fantastic control system and we are loving the ability to customise the interface - great job!!
To better explain what’s happening: we use WebRTC for streaming videos from the ROV to Cockpit. WebRTC can use multiple stream routes at the same time, and it will always priorize by default the default OS connection, which is usually the WiFi one. That’s why you experienced the problem, even having the wired connection.
Since this is a very common issue, and we don’t want users to have to toggle WiFi on every dive, we (@joaoantoniocardoso actually, which is our specialist on video and streaming) are working on a update that will always check the connection and prioritize wired ones. If all goes well, we won’t have this kind of problem in the future anymore. We also plan to allow the user to choose between different connections for troubleshooting.
And Matthew, thank you for the feedback on Cockpit. We appreciate it and are also very excited on how things are going.
And make sure to check the latest release (0.10.0). We just released it. It comes with some new features, new widgets (Virtual Horizon and iFrame), a face lift in the top view Compass widget and also some bug fixes.
I might add to your primer questions Peter if I may. It’s related to Peter’s third item. A very useful feature for us would be something we call ‘eventing’. Suppose we are inspecting an underwater structure and find a big hole (or other defect). We need to capture that event. It requires a basic table/database. The record should have
ID/DatestampTimestamp/Lat/Long/depth/altitude/heading/Screenshot of the defect. Ideally there would be another table to log projects. Ideally it would be possible to output reports with this data also or export into something else that can facilitate report generation.
Is this something you’re considering? if you need any further guidance on the industry need here we’d be happy to give you a steer.
Hey Gav!
Yes, it’s something we want to add! We have discussed that feature before but it’s not yet in our timeline!
Would you mind opening an issue in Cockpit’s repository with the details you see for this feature? I would be happy to better understand and make plans for adding it.
Also, about the logging and video overlays that @PeterM requested, I’m happy to say that we included that in the BETA milestone, I worked in it during the last week and we are almost ready to merge it! You can track it on this PR. Feel free to comment on it or in the issue linked to it about features not yet included but that would be desirable.
It’s a very initial feature implementation, but it’s already being used internally with success. We plan to add more features to it in the issue I’ve mentioned in the comment above.
