I have started to add functions to MinimOsd code.
At first i did it for myself only. Added many functions i thought i need. Then opened this thread.
after a while, Pedro and later Miguel came, and things started to happen fast. :D
They have optimised the code and added even more things to it.
They have worked hard on CT, and it became a great tool!
Thank you Bough! :)
By now MinimOSD-Extra got a pretty advanced OSD.
Here it is in action:
- Changeable unit measurement (US, metric)
- Home alt
- Battery Percent
- Battery used mah
- Current Draw
- Time From Startup (cleared at takeoff to show exact flight time)
- OSD Menu
- Wind horizontal speed and direction, and also the average wind speed of the last few minutes.
- OSD on/off
- Switchable secound screen
- WP distance
- WP heading
- Crosstrack error
- Warning messages for Lost GPS fix, Stall, Overspeed, battery volt, battery Percent, RSSI
- Efficiency, glide distance & thermic notifier. 3 in one panel
- OSD Brightness
- HAM Call Sign
- After flight summary
- Trip distance
- Smoothened horizon
- Real heading
- Vertical speed
This functions can be turned on and off, and placed on different screens now, by the Config. tool.
Also RSSI, switching mode and channel and unit measurement, Stall speed warning, Overspeed warning, Battery warning volt, Battery percent warning, RSSI warning, can be set in new Config Tool.
We built in a new way of setting video standards. Now OSD does not guessing anymore :). You can set it fixed from CT. It is in "Video Mode" menu.
Here is how it looks: (This video is a bit outdated, sorry. I will make a new one soon.)
The MinimOSD-Extra project is here: Link
This project is the developing version of the official Arducam OSD located here: Link
The latest stable version is: 2.2
The latest version can be downloaded from here: MinimOSD-Extra R800
CT is included. (The FW for Plane, Copter, Character upload and the character file is in the "FW & Char" directory inside CT directory)
We are sharing it to see videos you make using it! :)
No it isn't :S
I've just commited a new folder called librariesOK.
Those are the libs we're actually using.
could you please tell me where the libraries are locateted ? I am particularly interested in the code for intercepting the Mavlink messages for vertical speed. My plan is to take the Mavlink VS data with a pro mini or micro and convert it to an analog signal which will be fed to the video TX audio input.
By the way - I noticed that heading information is represented with 1 to 3 digits. In aviation normally three digits are used on PFDs or MFDs. A heading of 5 degrees would be shown as 005, a heading of 15 degrees as 015 and so on. It's just a matter of consistency for representing heading values.
The libraries are located here
I think that that variometer feature shouldn't be hard to achieve with a mini.
Thanks for pointing the 3 digit standard. It's a none code space cost.
Also it gave me an idea to save more code space, thanks :)
The only drawback regarding the leading zeros is the fact that the OSD will became more clutered.
Let's see what other guys think about it.
On leading zeroes; it is because of useable sreen area.
We have made many things different than real aviation HUD-s have. It has a reason.
In a real plane you dont only have the HUD view. In here you see everything through the OSD.
So yes. It is not a HUD. We call it OSD. :)
We are happy to help if you still want to achive this!
Hi Miguel and Gabor
thanks for reply, Will keep you updated about my project.
Regarding leading zeroes on the heading - let's have a look at it randomly : around 95 % percent of the time you have at least two digits, around 70% of the time you have three digits anyway. The OSD is cluttered, that's an argument. But it is way much easier for our brains to navigate in an OSD if it is clean and consistent. And I can tell you from own experience - a HUD in real aviation is cluttered as well. And the guys designing it spent a lot to make it more readable. The came up with trend vectors and bars instead of plain numbers. What a treat - it's so easy to interpret.
A big improvement would be a transition from digital information (numbers) to bars indicating errors or deviations from zero (for example VS)- that's widely used in real HUD. Absolute numbers often don't count much when it comes to interpretation of information. Just my own experience.
The minimosd is a little limited - I know. But part of the information could in my opinion as well be presented in another way.
On baars it is very! :)
Well, i belive you. I am not a real pilot.
We will talk this over with Miguel.
But on RC planes Heading is not very usefool.
That is why we made real heading panel.
I am usually around 20-30° off from the compass, becauseof wind.
So it would be more usefool might be to show real-real heading instead what we have now.
Like it tells you that you are 11° off to the right.
You really made me think now. :D
Bars or ladders with low speed/altitude ladder signs/warnings.
The ladders mostly in the center of the field of view like on a stealth plane HUD (human eye has very high resolution but only in a narrow field of view).
If we only had a platform to develop that...
Regarding heading orientation IMHO for FPV I think that the most important panel is the Home Arrow :)
quote "Regarding heading orientation IMHO for FPV I think that the most important panel is the Home Arrow :)" yes, I agree.
quote "human eye has very high resolution but only in a narrow field of view" yes, I agree. But movement on a ladder on the side captures your attention, and at a glance you know what is going on without processing this information in your brain in a big way..
One question : what about conditional compiling to free memory space ? Just to push development ahead and nevertheless being able to keep the most common features aboard anytime.
Completly agree, ladders are great. Do you know that Vertical Landing Aid that copter fw as built in horizon panel? My goal was to "at a glance" know if copter is at low altitude.
Conditional compiling is something I've already implemented (sort of).
It will however be difficult to mantain/support versions.
Some thoughts about this:
Will the source code be in the user PC installation folder (my current implementation) or "on-line" and downloaded at "compile time".
Will we compile all possible combinations? APM Mission Planner work more or less this way for each plane / copter / rover type. Also if I recall well, Companion9X radio fw application works also this way.
In this case we would need a routine to generate all the hex everytime there is a new version. Also we would need a repository since code.google does no longer support uploading "downloadables".
We have been on this trip for a while now and I guess it will take even more time to achieve this.
hey! thanks for the reply - tried to call and left a message. Were you able to fix this?