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

Views: 291663

Reply to This

Replies to This Discussion

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. ;)

THX,

Gábor

Hi BR928,

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. ;)

Gábor

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.

 

Hi BR928,

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.

Attachments:

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.

Hi Eddie,

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

 Gábor

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.

later

Burt

 

   public const byte MAVLINK_MSG_ID_RC_CHANNELS_SCALED = 34;

    [StructLayout(LayoutKind.Sequential,Pack=1,Size=22)]
    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;
   
    };

Hi  Burt,

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. :)

Gábor

Well was just a Idea, I may still look into trying it on mine as I still have two channels unused on my plane. The idea I plan on using is close to what the APM itself does, pick a few sets of values and when the channel is between these ranges the OSD_Pannels will have code to turn on or off some features.

The RSSI still would need work on the APM itself. I think that on the next major release of firmware on the APM we will see it being send out on the message I am talking about. They have a pin assigned for RSSI on the APM2, but right now it doesn’t seem to be connected in software. There was a another user that did add a RSSI out, but he did modify the APM firmware which is something I didn’t want to do yet.

On another idea for data to be displayed, I noticed when using the MP that current is being send across on the mavlink message “MAVLINK_MSG_ID_SYS_STATUS”. I think it was added for the Mavlink 1.0.

It was something that I have wanted, so I did get it to display on my Miniosd.

In the OSD_Vars.h  uncomment out line #5

//static float    osd_curr_A = 0;                 // Battery A current

In the MAVLink.ino file add

osd_curr_A = mavlink_msg_sys_status_get_current_battery(&msg);

Should add it here.

        case MAVLINK_MSG_ID_SYS_STATUS:

          {

#ifndef MAVLINK10           

            osd_vbat_A = (mavlink_msg_sys_status_get_vbat(&msg) / 1000.0f);

            osd_mode = mavlink_msg_sys_status_get_mode(&msg);

            osd_nav_mode = mavlink_msg_sys_status_get_nav_mode(&msg);

#else

            osd_vbat_A = (mavlink_msg_sys_status_get_voltage_battery(&msg) / 1000.0f);

            osd_curr_A = mavlink_msg_sys_status_get_current_battery(&msg);

#endif           

            osd_battery_remaining_A = mavlink_msg_sys_status_get_battery_remaining(&msg);

            //osd_mode = apm_mav_component;//Debug

            //osd_nav_mode = apm_mav_system;//Debug

          }

          break;

Last need it in the OSD_Panels to display on the OSD so a line like this

osd.printf("%c%c%5.2f%c%c",0x82,0x20,(osd_curr_A * .01),0x8F,0x20);

This added the current to my display.

Now the part about the how bad the current sensor seems to be.

I found in my testing that the sensor doesn’t seem to be symmetric, but at lower current one value needs to be set in the APM, but as you use more current that value needs to go down.

I did a few motor runs on the ground and was changing the value in the MP in the config tab for Battery. I got one that seems to work for my setup with the motor pulling mediun to high current draws. I did this with a watt meter hooked up showing current use, and played with the volt to amp setting.

Now I can see a “close” current use in the air, and most important is I can use the osd_battery_remaining_A and know about when my Battery is close to empty.

Hope you can use this info to add the current output to you display.

Burt

To have a "menu" would be nice. Also, not impossible.

But at the moment, i would like to keep things simple as possible.

Thank you for the ideas. :)

Reply to Discussion

RSS

© 2019   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service