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:
Added:
- Changeable unit measurement (US, metric)
- Airspeed
- Home alt
- Battery Percent
- Battery used mah
- Current Draw
- Time From Startup (cleared at takeoff to show exact flight time)
- OSD Menu
- Variometer
- 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
- Temperature
- Smoothened horizon
- Real heading
- RSSI
- 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
Username: MinimOSD_Extra
Password: Top_Secret
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! :)
Enjoy
Replies
This is the after flight summary.
Your OSD thinks that you did fly and landed after.
Gábor
APM has tis design flaw.
Its temperature correction sensor is meauring apm board temperature instead of outside temp.
That makes it not so precise.
I used to power it for a few minutes before takeoff. Than recalibrate it, by replacig the battery from warming battery to flight pack.
This helps a bit.
Gábor
Thanks Thomas and Kevin for the feedback. I'm thinking it is thermal related how as well. I'll do some tests and maybe look at the code as well. And read about the six factory generated calibration/compensation values... Did a simple test today - powered up my plane and left it sitting in the sun for 45 minutes, and watched the the ALT climb about 1ft every minute or two. Seems it should be possible to make the takeoff ALT and landing ALT be within 1 or 2 ft or so,unless barometric pressure (ie the weather) is rapidly changing.
I was thinking the same thing about the MS5611 thermocouples, but I thought temp compensation is built in and activated by default (second hand knowledge mind you ;) ). My takeoff to landing baro drift magnitudes are typically -3 to -5ft, and fairly consistent though it changes a little with ambient temp. I mostly fly in mild weather; I guess freezing weather would result in much larger drift.
The small drift I've experienced has been mostly inconsequential, however once this did create a problem for me. I was increasing max auto descent rate. I made a rather large change, and the final landing descent rate kicked in way too late, resulting in a hard landing. I compensated by adjusting my autoland final descent alt parameter a few ft higher. Since then all of my autolandings have been safe and controlled. I have always chalked the error up to being an example of the "imperfect real world" cliche, since I assumed the ms5611 was already attempting to compensate.
My OSD values are still off the mark most of the flight. Also, since my offset are based off of data from 10min flights, shorter flights land with alt error. If the application required more precision I would have to adjust the parameter before the flight. I think code that fixes this and consistently lands on the zero would be appreciated by the community. Good luck finding a cure!
[edit: One might say, "why not just let it warm up before flight?" I've had numerous flights after warming up for 20min and still had error (usually waiting for my buddy's Naza GPS to lock ;) ). Something is changing the thermodynamics in flight (airflow, increased waste heat due to flight processing... I've no clue). No length of waiting on the pad is going to fix errors caused by variable heat flow.]
Well baros just measure airpressure... airpressure is very dependant on temp, and of course weather changes - they are not, and never will be a reliable indicator for the distance to the actual landing ground. If you need that for landings you will need sonar, laser distance,optical devices, radar.. or maybe a 2 meter stick dangling from the aircraft signalizing ground is near....
I agree with you on this Rob. Even if we fly during a period of perfectly stable climate (just imagine launch pad pressure is fixed for now) and surround the membrane/strain guage with 10000 thermocouples, there will always error. The extra thermocouples would be there to characterize internal heat gradients and levels of self heating in greater detail... to get a closer to the true average temp of the air mass inside. However even our tiny ms5611 has millions of air molecules bouncing around missing the thermocouples. That alone is a practical limitation of barometers... they would pretty much have to clock every atom inside the ports to be 'perfect'... and even then maybe the lipo and esc's are preheating the air before it gets to the baro.
So the yardstick idea seems like a more efficient solution, or maybe a string and plumb bob. I'm steering clear of sonar for APM until it's proven to be reliable. For now I just give autoland some extra wiggle room. Although whenever I get a Pixhawk, I'll definitely look in to optical augmentation.
I've noticed recently a consistent pattern where my home altitude drifts up by 7 to 10 feet between the start and finish of every flight. I'm running APM 2.5 ArduPlane 2.78b. I've checked my last 15 flights or so and happens every time. I have my altitude sensor light blocked so I know that isn't it. Anyone else notice this? Any ideas? Picture shows a couple examples...
My guess is thermal drift. The MS5611 is much more accurate than +-10ft.
Without new graphical MinimOSD hardware PCB board designed, there is nothing usable to reverse engineer! :)
Other thing: guys, the slow refresh rate of the horizon line is because of the OSD or the APM? software or hardware related?
Many thanks,
B
-
95
-
96
-
97
-
98
-
99
of 163 Next