Hi I'm newbie here.
Wondering if the Mavlink mission planner software is open source and what it was written in for Windows.
I have a daft idea about porting it to run on an embedded linux system. Running the linux system in the air - controllable from the ground so I can develop a hi res transparent OSD for the airborne linux system.
The other things I'd need would be good documentation for the Mavlink serial protocol or how the serial data stream is organised from the OSD/Modem port on the IMU and or the Adrupilot's USB port. I'd also need to know if their is any way to access raw RC PWM values via these interfaces. My very fledgling idea is to use three spare RC channels to simulate a mouse to control the linux system from the ground. Two axis (left right, up down) and mouse down signal and transmit the linux systems display to the ground using a bog standard video link. The hardware I have in mind has a composite output and good graphics capabilities. Its also small (slightly larger than a credit card) with low power consumption.
Any thoughts or suggestion about the idea?
Where can I get hold of a detailed description of the Adrupilot serial protocols? Without them I cant make much of a start - I cant even write the code for the linux system from scratch without this documentation.
Any comments? Good bad or indifferent?
Mavlink start here: http://qgroundcontrol.org/mavlink/start
Planner is open source it's here: http://code.google.com/p/ardupilot-mega/
It's in C#3/.Net 2 (for linux/mono compatibility). No port necessary if you use Mono, however the code may have to be re-organised to decouple the GUI and get what you want out into a library.
Probably a better approach is to use the Mavlink code generation tool - it creates a mavlink parser library in C or Python (I have a C# version also although it's not in the main mavlink repo)
Yes you can get RC values over mavlink. This is how the planner does configuration of the TX etc.
No need to use spare RX channels for control, if you have good telem link, then UAV control can be achieved over that (search for threads describing PC joystick control)
If your end goal is to make a super duper OSD, then one piece of advice I have is to develop it 'on the ground' - i.e write a simulator for your composite out hardware. Then you can get the OSD/Mavlink code right MUCH faster than trying to develop on the target. Also makes writing test harnesses easier.
It took a while to reply because it took a me a few days to get Debian 6 installed (dual boot) on my laptop, then getting Qt installed and getting to the point where I can compile and execute the code! Thanks for the pointers, very helpful. I havnt installed linux before - so great fun - not used it much either !!!!!!
My plan is to compile the code for an embedded Linux box that is installed in the airframe - this way the only downlink needed is the composite video (could use the audio channels for limited telemetry) no ground station needed and it would work with av monitors or lcd glasses (HUD). Also possiblities of using USB webcams for video. The RC transmitter control of QGroundControl is all that needed to be able to control the application in the aircraft from the ground- assuming I can compile it for the embedded platform that is.
Not sure if its a good way to go or not really?
If your OSD overlay is going to be composed in software from something like a USB camera, the first test would be the latency for the video signal through the system. If you can't get that right then it will be unflyable for FPV.
However I suspect it would be more useful if the board has composite video in, that way you can use any camera.
The embedded system doesn't have composite video in unfortunately - it did occur to me that I could just mix the composite video from the linux box with any analogue camera the old fashioned way with a video mixer, easy and cheap :). Take your point about latency of USB webcam setup - I will test it. Need to get my hands on a Adrupilot 2 now - no stock in the UK.
I've got the C++ (Qt) code for QGroundcontrol compiling and running on my laptop - I'm very curious about your C# code though - is that open source too - can I get my grubby mits on it?
My C# mavlink generator is here:
I also have a Silverlight Mavlink packet analyzer her:
both open source but not actively maintained. One day I might get back to them.
If you are mixing video like that, you might as well do it on the GCS side, i.e run a seperate video and telemetry tx from the UAV. That has the advantage that if the video link goes bad due to range issues etc, you may be able to still fly via the OSD. That is assuming the data link has a longer range, which it usually does. Also means you can get this system working on a laptop. MUCH easier.
You don't need a APM to start the OSD btw - just grab a TLOG file.
I do need to get some log files - I've just been looking at the HUD code - looks like a work in progress, looks reasonably easy to customise. I cant see any reason why I cant run a ground station (laptop) and the airborne linux embedded system side by side to get it all working using a telemetry link for the ground station. I'm hoping to not need the ground station in the end. I've thought about modding a cheap lcd tv by adding a touch screen to control the airborne linux box. Im trying to avoid the need for multiple transmitters in the airframe, I think it has advantages in terms of weight - battery life - RF interference (two transmitters in close proximity causes its own problems) and I like the idea of all the avionics except the display being in the UAV - less bits and bobs to lug around. I know its not the way things are normally done - if I can get it to work there's no reason the linux box couldn't be used as a ground station which runs QGroundControl, dedicated small form factor solution (it would work for longer on a battery pack than a laptop does too)