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! :)
> There is something I can't understand. 250m is one char resolution right?
No, not in my approach.
In my approach the 250m is the stepwidth where the scale is resized.
if the object is >= 0m and <250m away, the used grid (14*9 chars) represents 250m * 250m
if the object is >=250m and <500m away, the used grid (14*9 chars) represents 500m * 500m
if the object is >=500m and <750m away, the used grid (14*9 chars) represents 750m * 750m
and so forth.
With that the object steps back to the half of the grid after 250m and then after 500m and so forth (you can see that in the video).
That has the benefit that the object is not shown in the center after reaching the next stepwidth but is shown at the half.
This approach has the advantage, that movement can be seen after 30-40m and not only after 250m, what is quite long for e.g. a copter.
But there are other approaches possible for shure.
In your approach the object sticks at the outer edge after reaching 7*250m in x or y direction.
Ok, 1750m is way enough, but some long range guys maybe will moan ;-)
One tip for your approach:
I think the calculation
int posCol = (osd_lon - osd_home_lon) * 111319.5 * converth / MAX_RANGE * NUMBER_OF_COLUMNS / 2;
needs the correction term
* cos(fabs(osd_home_lat) * 0.0174532925)
because of the variation of the distance of the longitude depending on the latitude you are at.
And the old object has to be cleared if it is located out of the horizon (which is cleared befor drawn).
P.S. I recently committed a new version where the object can be shown in 8 directions, I have to design the mcm tonight.
Thanks, I didn't realised that you were auto-zooming. Nice!
One tip to your approach:
Since it is auto-zooming, you could add something telling the "zoom range" (maybe digital in a corner of the panel).
Continue your great work!
"needs the correction term
* cos(fabs(osd_home_lat) * 0.0174532925) " - I know, thanks anyway :) I was just coding fast :P.
yes, "zoom range" is a good idea.
And in my response from above I think I did a mistake:
You defined the max range to 250 and I wrongly read the code as 7*250.
I currently did not know what the better solution is, auto-zooming or sticking at max range.
Because of the less resolution of the char grid, your approach with sticking at max range is maybe the better one.
I think comparing the approaches while flying in real can answer this.
Hey guys, I just got the MinimOSD working yesterday. I've updated the firmware and characterset using the OSD Configurator software (great job, folks!).
However, the panels spill off the HUD. That is, the dimensions of the panel seem much bigger than the video stream dimensions. Is there a setting for video resolution, or some other way I can solve this problem? I can only see about half of the indicators on the panel. For reference, I'm using an APM2.5 with ArduCopter 2.9, a Lawmate 1.3Ghz Rx/Tx pair, and this Iftron NTSC camera. I had the video Rx output to a projector because that's all I could find with composite input on short notice.
Thanks in advance, Josh.
I just pulled in the positions of the fields I was using until they 'fit' in your display. I pulled in my left and right sides by one 'block'. The top and bottom edges were okay. Also having PAL or NTSC can make a difference on where the characters display. It's kind of a hit and miss adjustment until you find a good compromise.
I have a 'possible feature' request. Using MinimOSD with the APM 2.5, I'd like to have a mAh Consumed display. I'm not sure if the APM calculates this for the MinimOSD to extract and display. If it does, and it can, I think it'd be a nice addition.
I noticed the APM parameter list on the wiki was recently edited, and no longer includes SR0 parameters... just SR3, and I assume SR0 can all be left on defaults=0? Last Sunday I setup a buddy's minimOSD with my firmware based on r462, and experimented to see if it would work with just the SR3 parameters. That did not work as expected, but worked fine after I filled in those SR0's.
Does this change to the list in the wiki indicate that all newer versions code work with the SR0 parameters =0? That's cool, but I think it would be good form to leave a note about those SR0 parameters on the wiki, for those using older versions of the code. ;)
Since you used the words "much bigger", you very well could have the wrong PAL/NTSC settings (drop down menu in the CT). Is all the video from the camera visible? If not, you might have a PAL projector. OTOH, if it's only "one or 2 characters off screen", you probably just have to tweak your panel layout as Lee mentioned above. FYI, be sure to have your GCS operating as it will at the field when you tweak your OSD layout. That way you will avoid silly problems, like the DVR time stamp covering up the GPS coordinates, or a flashing red video recording dot on top of your altitude display. ;)
The camera is NTSC, so that's what I set the OSD to. When I read from the OSD afterwards, though, it always went back to PAL?! Weird. I'll see if I can get one or the other to stick, and move them all inwards in the meantime.
Thanks for the great advice, Kevin. See my comment above regarding the PAL vs NTSC issue. The projector was set to NTSC. I don't know how I'd know if the full video was there or not. Your recommendation to tune the HUD to the actual GCS use case is well taken. I'm waiting on a USB converter to stream the video to the computer (Hauppage USB-2-Live), but until then I'm limited to whatever I can find with a component input.
The only data available on the mavlink is percentage of battery remaining based on the battery capacity you enter via the mission planner.
The APM calculates the mAh used, divides that by the capacity, and returns it as the percentage. I wasn't sure if I liked this as opposed to the mAh used, but now that I have used it I prefer it.
Except for when you use different size batteries. I have from 2650 to 4000mAh packs I use. I'd have to change the battery capacity in the APM each time I use a different size battery...hence why I'd prefer the mAh used.