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 came, and things started to happen fast. :D
He optimised the code and added even more things to it.
He worked hard on CT, and it became a great tool!
Thank you Pedro! :)
Also Burt & Eddie came.
They also worked on it and added many smart things to our firmware.
By now MinimOSD-Extra got a pretty advanced OSD.
Here it is in action:
- Changeable unit measurement (US, metric)
- Home alt
- Battery Percent
- Current Draw
- Time From Startup (Will be cleared at takeoff to show exact flight time in the next release)
- OSD Menu
- Wind horizontal speed and direction, and also vertical wind speed (Vertical wind speed will be in next release)
- OSD on/off
- Switchable secound screen
- WP distance
- WP heading
- Warning messages for Lost GPS fix, Stall, Overspeed, battery volt, battery Percent, RSSI
- Efficiency, glide distance & thermic notifier. 3 in one panel (Will be in next release)
- OSD Brightness (Will be in next release)
- HAM Call Sign (Will be in next release)
- After flight summary (Will be in next release)
- Trip distance (Will be in next release)
- Temperature (Will be in next release)
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.)
About the menu:
I made a menu inside OSD. You can enter this menu only after boot, the same way as screen switching works.
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.1
We are sharing it to see videos you make using it! :)
Any way to add the current value. mavlink now sends it out to the mission planner and I display it my Minimosd using the value
I have hard coded a lot of things I use but like what you have done with the config tool.
Other things that you might think about adding is
a. way to change from meter to feet, m/s to mph
b. a way to display a message. (some of us need to display a call sign)
Hi Burt Green,
I think i will. ;)
I do not use current yet. I did use battery remaining. (Not very precise with my sensor... :( )
If you have ideas, let me know. ;)
Using Arduino IDE 1.0.1 I am still getting compile errors. Says conflicting return type associated with uint8_t. Any ideas?
There are 2 source codes in your zip file. Is the OSD the original and the beta your changes?
Just left the source structure as it was, when i first downloaded it. :)
Beta can be deleted. I think i will.
So the answer is; The original is the one.
Here is what i use: Link
Try it. ;)
So the ArduCam_OSD _Beta is the original source and can be deleted?
I was able to get your G1.22 ArduCam_OSD to compile using Arduino 0100-relax and 1.0.1 without any errors. The Beta still will not compile but that is not a problem if it was the original code.
Does this code select between MAVLink 0.9 and 1.0?
I am using Arduino Pro w/ AT Mega 328 as the board. Is this what you are using?
I was able to upload the code to the board but I can't view anything because the video section is burned up. I am waiting on a replacement. I can't wait to get this working again.
There was bough in the original source. (I have never even opened "beta")
Started with normal code.
This firmware does not select between MAVLink type. Simply uses 1.0.
A have used Arduino Pro w/ AT Mega 328 also.
I am also waiting for my gps tracker to arrive.
Till it does not, i can't do any flight testing.
I have made a new function.
It is OSD on/off
At the moment it works this way;
If you switch between stabilized, and manual mode faster than 1,5s but slower than 1s than it will turn off/on.
It is not the best solution of this function, but i did not have better idea. Not yet.
Also i think that my code on this function is a bit too circumstantial.
So, if you know a better way, please write it down! ;)
If warnings function is on, and any warning is present than it will turn osd on automatically, and osd can't be turned off, till warning is off.
What about switching between any two modes and back to the previous mode within 1 sec toggles the OSD. Maybe exclude RTL. eg, Stab > FBWA > Stab, OSD toggles on 2nd Stab.
I did exclude rtl and circle, because low radio signal could case osd go on and off.
I was planning switching time below 1 sec also, but it seams that this OSD is not fast enough for that. Or using millis instead of start time might helps. Hmmmm...... :)
I should have used millis.
Will try after work.
It supposed to work with FBW also, but it does not. I have to find out why.
It is usable as it is now, but i am afraid that this function needs much more work, to be perfect... :D
I'm not sure it gets decoded on the Miniosd, but the mission planner does decodes the mavlink message below. I think if it doesn't it should because it has the RSSI data when the APM starts sending it.
If it decodes this message, you could take the raw rc channels and use one channel to turn on and off the display. Also could set it up to have pages of displays for say a three postion switch on the transmitter. As example chan5_scaled < -50 display off, chan5_ scaled > -50 and < 0 display page 1.
I may look in to this on sunday, my next day off.
public const byte MAVLINK_MSG_ID_RC_CHANNELS_SCALED = 34;
|public struct mavlink_rc_channels_scaled_t|
|/// <summary> Timestamp (milliseconds since system boot) </summary>|
|public UInt32 time_boot_ms;|
|/// <summary> RC channel 1 value scaled, (-100%) -10000, (0%) 0, (100%) 10000 </summary>|
|public Int16 chan1_scaled;|
|/// <summary> RC channel 2 value scaled, (-100%) -10000, (0%) 0, (100%) 10000 </summary>|
|public Int16 chan2_scaled;|
|/// <summary> RC channel 3 value scaled, (-100%) -10000, (0%) 0, (100%) 10000 </summary>|
|public Int16 chan3_scaled;|
|/// <summary> RC channel 4 value scaled, (-100%) -10000, (0%) 0, (100%) 10000 </summary>|
|public Int16 chan4_scaled;|
|/// <summary> RC channel 5 value scaled, (-100%) -10000, (0%) 0, (100%) 10000 </summary>|
|public Int16 chan5_scaled;|
|/// <summary> RC channel 6 value scaled, (-100%) -10000, (0%) 0, (100%) 10000 </summary>|
|public Int16 chan6_scaled;|
|/// <summary> RC channel 7 value scaled, (-100%) -10000, (0%) 0, (100%) 10000 </summary>|
|public Int16 chan7_scaled;|
|/// <summary> RC channel 8 value scaled, (-100%) -10000, (0%) 0, (100%) 10000 </summary>|
|public Int16 chan8_scaled;|
|/// <summary> Servo output port (set of 8 outputs = 1 port). Most MAVs will just use one, but this allows to encode more than 8 servos. </summary>|
|public byte port;|
|/// <summary> Receive signal strength indicator, 0: 0%, 255: 100% </summary>|
|public byte rssi;|
I did not try that. I am also interested in RSSI. :)
On hiding osd data;
My point was to not to waste extra channels. Like my plane already uses 9 (All much more important than hiding osd.)
If you find a better way, pleas share it.
If that is ok with you i might use it. :)
Some other OSD's use a two channel system. I'm not exactly sure of the details, but I gather it's something like one channel going high activates a menu, which overrides a second channel which becomes an up/down selector, then when the first channel goes low it chooses the currently selected menu item. That way you only need one dedicated channel, and the second one could be rudder or flaps or something that can be overridden for a while to use the menu.
I didn't suggest this before as it would involve the AMP knowing to disable the main function of the secondary channel while the menu was active, but I guess you could use camera tilt or something that's not a flight control and then you wouldn't necessarily have to disable it's main function.
Maybe eventually an extra flight mode could be added, an OSD_MENU mode, where the plane was stabilized, or loitered, while you interacted with a menu. Then you would still only need one channel to control the APM and OSD.
But back to reality, I think the quick switching between flight modes is quite ingenious as it doesn't require anything extra to be added to other parts of the system. As soon as you think it's reliable I'll try it out on my plane. :)