Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
WIP: Basic video streaming discovery using MAVLink #5271
TL;DR: Adding Basic video streams discovery on QGC using MAVLink messages merged on mavlink/mavlink#677.
But, we have also discussed that it would be important to have a basic video camera support using only MAVLink messages, to be used as a fallback. And this is what I am proposing in this PR: To use MAVLink messages already merged in mavlink repository to discover video streams and present some available options to the user.
How to test it:
Why adding a new Widget:
@DonLakeFlyer as Otavio mentioned, there is an implementation for this as part of Camera Streaming Daemon (which can be run together with both PX4 and Ardupilot). The idea with this proposal is to get more testing and use this as a testbed for the proposals and implementation of messages that are being discussed as part of the ongoing camera efforts within MAVLink and Dronecode projects. Implementing support for these messages inside the flight stack itself might make sense in some cases, but particularly for ours we are more interested in having this on the side of the companion computer (we're testing on Intel Aero, but there is nothing platform specific on the project and the idea is that it can be used by anyone interested in this).
Video streaming from multiple cameras on-board is managed by a system that is not part of the flight stack. This new system is camera-streaming-daemon which is a process running on the companion board. The camera-streaming-daemon registers its presence by sending mavlink heartbeat messages to the GCS and later exchanges mavlink messages directly with the GCS without having the mavlink messages go through the Flight Stack. Different system = different sys_id.
@otaviobp I've been out of town and only now I'm looking at this. I've also pushed a PR that changes slightly how to handle video streaming (look at #5318). Let me clone this PR (your repo) so I can build and take a better look at it. If you don't mind, I will merge/fix the conflicts created since you pushed it.
Yes, the idea all along was to have a camera control widget. I have not yet added one as I've been waiting on a resolution on how to discover the camera parameters (the ongoing discussion in http://discuss.px4.io/t/mavlink-camera-api-discussion/3278/21)
Also, yes, the idea is to have a basic, MAVLink only interface for discovery and settings (such as you've done here). The notion of a camera definition file (the Json file mentioned above) are for extending the functionality that would be beyond the scope and capabilities of using MAVLink alone.
This is all in flux as things are still being sorted out. With that said, at first glance this PR is a move in the right direction. Note that my focus on the discussion above was in controlling an onboard camera for recording videos and capturing images. Video streaming was a secondary function. The primary method for discovery and setting of video streaming will probably still be through MAVLink only as you've done here.
referenced this pull request
Jun 21, 2017
Ok, now that I see how the widget was created, it won't work. You are using the old QtWidget type widget, which is being phased out. Those won't even build for mobile platforms.
This will be quite a bit more involved. What needs to be done is for a widget to be written in QML and loaded (from a
Given the amount of work involved, let's wait for 3.2 to be done and out. In the mean time I will create the widget and controller (using the code you have here for video streaming discovery). We can then go from there and move along with the rest of the Video/Photo controls discussed above.
In summary, leave this here for now. I will get going with the base code and use the MAVLink interface you've added here. Once that's done, we can close this PR and start working on the new code.
In addition, we will also need to deal with the Flight Widget, which takes an enormous amount of screen space. We will have to have both Flight Widget and Camera Control widget fit within the UI without covering too much space, even if the Camera/Video control will only be shown when the video view is shown.
The widget itself should be just a camera/video icon to switch the camera between video and photo mode and a shutter button to Start/Stop recording videos or capture a photo. A Settings button would also be present. When this Settings button is pressed, a Video/Photo/Streaming Video settings dialog will be shown in the middle of the screen (with the video in the background). In order for this to be properly shown, we need to know if the vehicle has video recording, photo capture, and/or video streaming capabilities. That will determine how the controller is built. In addition, when the Video/Photo/Streaming settings is shown, we need to know what parameters are there and what options each parameter offers. That's the whole point of the ongoing discussion.
Ha! And lastly, we also need to figure out how to integrate the local video recording. That's the recording of the video stream to local storage as opposed to recording video on the camera itself (at a likely much higher resolution and quality).