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 developing version of copter is here: Link to Copter FW

And the latest Plane is here: Link to Plane FW

In bough version, the CT is included. (The FW and the character file is in the root directory)

We are sharing it to see videos you make using it! :)

Enjoy

Views: 154475

Reply to This

Replies to This Discussion

Hi Hein,

"Hi Miguel, glad to be of help"

It's your feedback and tips that make the development worthwhile. They are much appreciated! :)

 

"maybe one can merge it with the artificial horizon to overcome Gabor's concern?"

One way of doing this is to merge them. The downside of doing so is that you won't be able to use them separately. But, I have some ideas ;) Have to think a little bit more about it.

 

"Can you rotate individual characters?"

Man! I wish I could. Unfortunatly if we want to "rotate", we have to use another character from the charset.

Regards,

Miguel

My memory failed :P

Each character is 12x18 pixels!

So we would need at least 12x18=216 characters from the chatset to have a 1 pixel resolution in radar.

With a 2 pixel resolution it would be needed 6x9=54 characters.

We only have 256 characters for everything :S

The principal memory cost is regarding that charset memory usage.

Regards,

Miguel

Nice video, and good work as always Miguel. I also learned some lessons about having antennas near my truck... not as bad as getting diversity connections backwards LOL! At least it appears you weren't under the goggles for this flight. ;)

I like the "landing aid" thing. That's essentially the 'altitude ladder' idea I brought up a while back. I'd like to see that implemented in a more compact traditional "ladder" off to the side... IMHO it's not worth having the AH cross out the center of the video. I also think having a similar speed ladder would be nice... like a carrat that moves toward center at GS=0.

The idea is similar to digital vs dial guages in your car... 'hands-on drivers' like dials, 'cruise controller' type drivers prefer digital. I bet most multirotor FPV guys are the hands-on type pilots who want guages... no time to focus on digital guages when you're snaking through trees... OTOH a ladder/dial guage might be something you can soak in through peripheral vision. ;)

ReadWikipedia: Read may refer to:being gay like a bunghole, making pancakes, brushing your teeth, sing thong aching, and listening to Justin beibers albums.

Hi Kevin,

Diversity backwards should be a little worst LOL

I tryed the googles on, but removed them right away. I will try next time.

I know very well that ladders. The reason I centered that in the OSD is because, when landing in a place where you can't see horizon well (like between trees :) ) you you have to be focused on the centre of attitude line.

 

That's why I centered that, but if people like it most on side I can make it that way ;)

 

Regards,

 

Miguel 

Well, it is possible.

Can you send me pictures?

I would like to take a look.

Gábor

Hi,

reading the discussion about radar, I found it a good idea and coded a little yesterday.

The GPS data in the test video is only simulated, because currently I have no time to fly.


The quad comes out of the middle at about 00:09:




If you like a plane icon more, you can change the icon in the mcm file.
We could also code that the quad or plane is shown with different heading directions, but for that we had less chars free in the mcm file (when using the artificial horizon with the better resolution).
But I will take another look for 8 free chars.


The used grid for the radar is currently configured to 14x9 chars, but this is changeable easily by defines.

And there is an auto scaling, currently set to 250m, which is also changeable easily by defines.



If you like, the code is at the same place where my artificial horizon with the better resolution is located.



The code is as follows:


/******************************************************************/
// Panel  : panUAVPosition
// Needs  : X, Y locations of center
// Needs  : globals: osd_home_lat, osd_lat, osd_home_lon, osd_lon
// Output : shows the UAV position in a radar like style
// Status : do flight test
/******************************************************************/

#define    STEP_WIDTH    250            // every STEP_WIDTH in [m] it is down-scaled
#define    SCALE_X        ( 7.0 / STEP_WIDTH)    // SCALE_X * 2 chars grid in which the uav is drawed
#define    SCALE_Y        ( 4.5 / STEP_WIDTH)    // SCALE_Y * 2 chars grid in which the uav is drawed

void panUAVPosition(int center_col, int center_line) {
    static int last_x = 0;
    static int last_y = 0;
    
    // distances from home in lat (y) and lon (x) direction in [m]
    int dy = (int)(111319.5 * (osd_home_lat - osd_lat));
    int dx = (int)(111319.5 * (osd_home_lon - osd_lon) * cos(fabs(osd_home_lat) * 0.0174532925));
    // display offset in y and x direction
    int y = (int)(dy / (((int)(abs(dy) / STEP_WIDTH) + 1) / SCALE_Y));
    int x = (int)(dx / (((int)(abs(dx) / STEP_WIDTH) + 1) / SCALE_X));
    // clear UAV
    osd.openSingle(center_col - last_x, center_line + last_y);
    osd.printf_P(PSTR(" "));
    last_x = x;
    last_y = y;
    // print UAV
    osd.openSingle(center_col - x, center_line + y);
    osd.printf_P(PSTR("\xF4"));
    // print home
    osd.setPanel(center_col, center_line);
    osd.openPanel();
    osd.printf_P(PSTR("\xF5\xF6"));
    osd.closePanel();
}


Have fun, bye
JR

Hi Jörg,

Thank you for sharing the code.

There is something I can't understand. 250m is onr char resolution right?

Imagine UAV is 1000000m (1000Km) from home in latitude:

int y = (int)(dy / (((int)(abs(dy) / STEP_WIDTH) + 1) / SCALE_Y));

 int y = (int)(1000000 / (((int)(abs(1000000) / 250) + 1) / (4.5 / 250)));

In my calculator it is equal to 4

4 shouldn't stand for 4 x 250 = 1000m ?

 

My approach:

#define MAX_RANGE                      250

#define NUMBER_OF_ROWS        14

#define NUMBER_OF_COLUMNS 14

#define NUMBER_OF_ROWS_FROM_CENTER     NUMBER_OF_ROWS / 2

#define NUMBER_OF_COLUMNS_FROM_CENTER  NUMBER_OF_COLUMNS / 2  

void panUAVPosition(int center_col, int center_line) {

int posRow = (osd_lat - osd_home_lat) * 111319.5 * converth / MAX_RANGE * NUMBER_OF_ROWS / 2;

int posCol = (osd_lon - osd_home_lon) * 111319.5 * converth / MAX_RANGE * NUMBER_OF_COLUMNS / 2;

 

//Deal with extrems

if (posRow > NUMBER_OF_ROWS_FROM_CENTER)    

    posRow = NUMBER_OF_ROWS_FROM_CENTER;

if(posRow < - NUMBER_OF_ROWS_FROM_CENTER)    

    posRow = - NUMBER_OF_ROWS_FROM_CENTER;

if(posCol > NUMBER_OF_COLUMNS_FROM_CENTER)

    posCol = NUMBER_OF_COLUMNS_FROM_CENTER;

if(posCol < - NUMBER_OF_COLUMNS_FROM_CENTER)

    posCol = - NUMBER_OF_COLUMNS_FROM_CENTER;

// print UAV

osd.openSingle(center_col + posCol, center_line + posRow);

osd.printf_P(PSTR("\xF4"));

}

Regards,

Miguel

Hi Miguel,

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

That means
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).


Bye
JR

P.S. I recently committed a new version where the object can be shown in 8 directions, I have to design the mcm tonight.

Hi Jörg,

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. 

Regards,

Miguel

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.

Bye

JR

Hi Jörg,

Thanks for your feedback.

"I think comparing the approaches while flying in real can answer this." - I agree with you. Nothing better than testing ;)

 

I think this panel is a good item to the "wish list". If you have "radar test videos" please share :)

 

Regards,

Miguel

yes, I will share them, but unfortunately the winter came back last saturday  :-(

But when we will get back above 10°C and dry conditions, I will do some real test flights.....

Bye

JR

RSS

© 2014   Created by Chris Anderson.

Badges  |  Report an Issue  |  Terms of Service