PRO-HUD OSD, a branch of KV Team OSD

[linuxslate]

PRO-HUD-OSD is a branch of KV-Team OSD.

Discussion being moved here to avoid confusion with the "real" (main branch) KV_Team_OSD.

As implied by the term "PRO", it has a little different aim than KV_TEAM_OSD. It is hoped that it looks and works more like an aricraft HUD. It is meant for expirienced RC pilots, possibly with actual aircraft training expirience.

Features/Philosophy:

Units removed from most measurements. Units take up precious space and add clutter. Google some images of real aircraft huds. They usually do not show units for the major measurements.

More use of sliders for quick visual reference. I intend to implement more sliders -- right up until I bust the cycle time. I want it to be as graphical as possible.

Font and Icon changes -- No lower case, Larger Clearer Icons

Terms/Icons changed to more aircraft-like terminology.

It is based on 2.2, r345, since I could not get r370 to work on my board. I will pull in some fixes from later builds as needed.

Specific Enhancements:

Rate of climb indicator on right scale. It's purposely set quite sensitive to aid in landing or precision flying such as limbo competitions or flying under tree branches.

Throttle scale.

I intend to implement an altitude slider on the left scale. It will be set very sesitive, probably only showing the last 20 Feet or so. Again to aid in landing.

I would like to implement a flight path indicator based on the FC accelerometer values. (I'll call it FPI, to avoid confusion).
From Wikipedia:
flight path vector (FPV) or velocity vector symbol—shows where the aircraft is actually going, the sum of all forces acting on the aircraft.[11] For example, if the aircraft is pitched up but is losing energy, then the FPV symbol will be below the horizon even though the boresight symbol is above the horizon. During approach and landing, a pilot can fly the approach by keeping the FPV symbol at the desired descent angle and touchdown point on the runway.

What is not in the PRO-HUD branch

I do not have a reciever with RSSI, so the recent RSSI work is not yet in there. (Back porting RSSI fixes is in work. Help requested since I cannot test.)

Same for other things I do not have, such as a power meter. This code will be unchanged as of right now from r345.

I do not plan to support PID settings via the OSD. All code to write to MW EEPROM will be removed for safety. Associated screens will eventually be removed. Removing the EEPROM Write code makes the OSD basically passive.

I will not be updating the GUI. Having to keep the GUI in sync takes valuable time from "real" OSD development, and I am simply not skilled enough to maintain the GUI on 3 different platforms.

While the GUI currently still works, I plan to move necessary settings back to the config.h file. Again, this is the "PRO" version. If you cannot edit a text file, this version is probably not for you.

The PRO-HUD branch will not have KV's new (and very cool) real time screen editor. Due to the use of sliders, and more animation, moving things around on the fly will just not be practical.

Get the code:

http://code.google.com/p/rush-osd-devel ... me=HUD-OSD

[subaru4wd]

What is not in the PRO-HUD branch

I do not have a reciever with RSSI, so the recent RSSI work is not yet in there. (Back porting RSSI fixes is in work. Help requested since I cannot test.)

Same for other things I do not have, such as a power meter. This code will be unchanged as of right now from r345.

I have a mInimOSD with the RSSI mod done to accept 0-5v analog RSSI. I would be happy to help test some code. I really like the look of your OSD, but can not fly without my RSSI.

[linuxslate]

I really like the look of your OSD, but can not fly without my RSSI.

Try the latest version in the PRO_HUD branch (from source). It should support RSSI.

Note that RSSI has moved to the upper right, use my latest .mcm file for the new RSSI Icon. (I changed Icons so that the icon is not confused with a "live bars" display if I implement that.)

Note that there is now a setting in Config.h for PWMRSSI. (Remember, I am moving things back to the Config.h file.) This should be 0 if you are using RSSI via MultiWii, and 1 if you are using RSSI connected to a pin on the OSD Board.

Set the other RSSI settings like you do on the official KV team OSD. For right now, than means using both the r345 GUI, and editing Config.h (I never said my version would be easy)

Let me know results, including the specifics of your hardware set-up.

[linuxslate]

What's comming in PRO_HUD_OSD:

FPI: Flight Path Indicator (Red Circle).

It is currently coded and working, but probably not in any way accurate. It is currently just showing the accelerometer data without much smarts behind it.

It is probably functional as a turn slide/slip indicator, but I have not even flown with it yet.

I am pretty bad in math -- Calculus 3 does mean that you take it 3 times to pass, right? I got "A" for algebra, so I figured "C" should be about right for Calculus. To make things worse, that was [REDACTED] years ago.

Instead of actually doing the Calculus, I am trying to "fake it" since there are really only a finite number of positions the FPI can be in due to the limited resolution of the OSD board. There really isn't much point in doing 32bit floating point math. Also, the computing power of the OSD board is limited.

The FPI is basically supposed to tell you where the aircaft will end up, if you keep flying the way you are. In a real aircaft, if you just keep the Flight Path Indicator (or Velocity Vector Indicator) on the beginning of the runway, you'll touch down at that spot (assumming proper rate of descent, airspeed, etc.)

Since it shows you where you are going, not where you are pointed, it helps compensate for wind, slide slip, etc.

By Nature, an FPI has to be a little different on a Quadcopter. For example, if I am hovering in exactly one spot, I have no flight path. Airplanes can't (normally) do that.

But it would be really cool to just put that little circle on the beginning of a path through some trees, or under a limbo bar, and know you are going to fly to the right spot.

[linuxslate]

Latest development screen shot

New and Working:

Continuing the movement to (back to?) a more HUD-like look.

Reverted back to the original symbols for rate of climb. They are now just inside the right scale. They take up 3 characters high, and sequence in a more intitive fashion than the original KV_Team_OSD. The 2 arrows in the middle (shown) indicate ~0 vertical velocity. There are no black arrows.

"3D Fix" Tiny letters/icon removed. A GPS fix is indicated by the box around the number of satellites. Screen realestate is saved, and you look at one spot for a all the GPS status information. Why did "3D FIX" get replaced with "GO HOME" when we were in return to home mode? Certainly, we must have a 3D fix in order to do a return home. Now you can see both.

Future:

Rate of climb numerical value is missing in this screen shot. Will be above the arrows, near the top of the right scale.

GPS altitude (bottom of right scale) will get a label (not units), I do not want to take the room for "GPS ALT", so perhaps something like "ASL" (Above sea level).

Flight Path indicator is still in there, but is not visible in this veiw. Still just moves based on accel data. I am still trying to learn the necessary math.

I would like to get rid of the "Acc" "Bar" "Mag" "GPS" icons. HUDs never show irrelevant information, or display things that are not on. They are somewhat redundant to the flight mode. The OSD needs to display the current flight mode, but if you want to know what sensors are used for a certain flight mode, I feel that the proper place for that is in the wiki, not taking up room on the OSD. I may replace that whole area with full-size text that just says "ACRO" "ANGL" "HORZ" "HOLD" "HOME", etc. Much easier to see at a glance, and actually less realestate.

[pki]

Hi.
The development seems to go in a very good professional way. I will like it

What i am missing on this is a trip indicator/odometer. Maybe switchable or changeable with the flight time and the energy measurement (mAh or Wh).