Fixed position for formation flight / inav radar

[error414]

Hi, I don't like "flying" info on the screen about friends (inav radar), so I created proof of concept of fixed position info about the closest peer.

It's new OSD element, I would like open discustion if it's better to create new OSD element (so keep it as I done it) or provide info about the closest peer into inav programming framework and then use custom OSD elements drivven by programming framework.

So far it works nicely on the bench.

So main question, provide info about the closest peer from inav radar to programming framework, or keep it as it is

CONFIGURATOR: https://github.com/iNavFlight/inav-configurator/pull/2029

[Jetrell]

@error414 Nice idea ! Having the Formation flight radar HUD information moving around the screen as it is presently, is useful in some circumstances. But also having the radar as a fixed position OSD element like this, would be extremely useful for multirotors.

So main question, provide info about the closest peer from inav radar to programming framework.

Having the possibility to add info about multiple peers would be useful if the pilot desires.. What type of layout method did you have in mind for this peer information ?

[rts18]

@error414 Can it be made to work independently of the crosshair? So it doesn't require a crosshair to display the formation flight data as it does currently with all the radar HUD functions.

[error414]

@Jetrell I used exactly same layout as original one. As I'm thinking, I don't need to know "peer heading", only direction to peer is important to me. I can allow multiple peers, two or three, but area what is covered by one element is quite big, 2x4 chars. It's not much extra works, so I can keep it on each person how many peers he want to see.

In second line are two informations, distance to peer, and altitude diff to peer. It can be set by osd_hud_radar_alt_difference_display_time and osd_hud_radar_alt_difference_display_time see https://github.com/iNavFlight/inav/blob/master/docs/Settings.md#osd_hud_radar_distance_display_time

Maybe I would like to see both information at the same time. I don't know now :). I'm open to any ideas.

@rts18 new OSD element is independend to HUD in my PR. It's same type of element like "sats", "altitude", 'time', etc....

[Jetrell]

Maybe I would like to see both information at the same time. I don't know now :). I'm open to any ideas.

I figure most people will only fly as a pair. But in the case that multiple pilots are using the FF radar. Then it maybe beneficial to add a full compliment of data to the radar display (peer heading, distance and altitude as well) ? osd_hud_radar_disp presently defines that number. And if we're using the present radar HUD. All that data will be floating around the screen anyway.. At least with your fixed position option. The user can place those radar fields in a location on the screen that suits them. Whether it be 1 or 6 items.

Presently osd_hud_radar_disp = 4 in the INAV software. But I think Formation flight can handle up to 6 peers. But I'm not sure if increasing that number would cause an error for those still using the old INAV radar firmware.

[error414]

so, do you suggest to three lines for each peer?

[heading][peer ID][LQ][direction to peer] [distance to peer] [alt diff] ?

This PR does not use param "osd_hud_radar_disp " because it's not necesesary, it show only one peer, the closest one. How much peers can be stored in memory is defined here https://github.com/iNavFlight/inav/blob/master/src/main/navigation/navigation.h#L456 , there is 5, but I would say it includes your peer as well. For example, if you fly with your friend, there will be stored your peer (everytime 0m distance) and your friend. So 5 means you + next four peers.

New peer is alsways saved to next index, So you are always 0, then your friend is 1, That index correspond to letter on screen. 0 = A, 1 = B ...

So if I would allow to show more peers, how to order them? Imagine, you turn on plane, you will be in index 0, then some ghost peer apper and it's saved in index 1, then your friend turn up plane, and he will be in index 2. In this case you expect only one peer and you set that only peer B will be visble, because there is ghost peer, you will never see your friend because he is C.

So you would have to put to OSD all four OSD elements, for each peer ,to be sure your friend will be on screen.

How it could look with 3 lines, no peer / the clossest peer:

[P-I-Engineer]

thank you, this was on my attempt to do list for a while. a

a static positioned indicator is much preferred for me.

thanks again.

[MUSTARDTIGERFPV]

To contribute to the discussion on layout:

When I wrote support for Ardupilot, I also chose not to implement the "HUD" style display. I have a single, simple, static element which contains all the peers in the following way:

[ID] [Horizontal Arrow] [Horizontal Distance]
[Vertical Arrow] [Vertical Distance]

Every two seconds, the element checks for the "next" peer with fresh data. If that's the current peer, nothing happens and it stays on the same peer. So for flying as a pair, you'd only see your friend. When a third shows up, the element shows friend 1 for two seconds, then friend 2 for two seconds, then rotates back around. I've found this to be more than sufficient to fly up to four people in the air at a time, since once you're close enough to need data more frequently than that you're generally already in range.

You can find my other PR https://github.com/ArduPilot/ardupilot/pull/25684 where I've included a screenshot of what the element looks like in flight.

[Jetrell]

@error414 I agree.. Ordering them would be a pain.. Although @MUSTARDTIGERFPV idea would certainly be a good way around that. And people still have the option to use the HUD radar, if they don't want to wait for the peers to cycle around.

so, do you suggest to three lines for each peer?

[heading][peer ID][LQ][direction to peer] [distance to peer] [alt diff] ?

I thought it may be beneficial.. The element isn't moving all over the place like the HUD does. So an extra line of 4 characters wouldn't be too bulky. I often find myself waiting for the Altitude and Distance to cycle around.. Sometimes the timer for them is too slow, and other times its too fast, and I miss it. Having both would allow for faster reference.

[error414]

It's a good idea, so I copied how it looks like in ardupilot :).

In the cli is new param "radar_peers_display_time" (second), it's switching time beetween peers.

Just image because OBS can't record screen from Xplane11.

I used same arow as for "direction to home", I don't like radar icon, it's dififcult to see what is the direction.

Here are screens how radar icon looks like, it's small circle. Hdzero:

Walksnail:

[MrD-RC]

OBS can record from X-Plane. Well, X-Plane 11 at least. I've done it a few times. Off the top of my head. I captured the whole screen.

[rts18]

I used same arow as for "direction to home", I don't like radar icon, it's dififcult to see what is the direction.

@error414 I would recommend not altering the icon definitions in the code. I believe its more practical for users to load or alter the png images in the font package to suit their taste. That is the benefit of having different font packages. To account for personal choice.

SneakyFPV font packages include the radar icon you prefer for use with Walksnail : https://drive.google.com/drive/folders/1IMGjPGR9hSTKJmKyhVOn6UYDWRlsQSU0 > OLDER > INAV6 > BATMAN

These png images can easily be altered by a user with a simple image manipulation program. Allowing transfer of icons or glyphs from one font package to another to suit ones taste.

Many of us have also become familiar with @MrD-RC cardinal radar layout. As you describe in this image.

The use of three different icon types is beneficial for fast deciphering of the data at a glance.

Rather than having two of the same hard coded 2D icons used to describe two separate data fields.

Peer heading is an extremely important data point when peers are not in the immediate vicinity. Without it, you can not know if your paths will intersect. You may know their azimuth, but not their heading comparing to your own. We've used Formationflight with Ardupilot OSD and INAV OSD. We have a group of four dudes that find INAV's radar OSD format more descriptive and useful in tracking each others aircraft, than Ardupilots.

May we request the layout stays the same. While allowing users to select or customize their own glyphs, or icons as you refer to them. Thank you

[error414]

@rts18 so what layout would you suggest? I do that because I don't like moving radar over screen and I would like to see distance and alt diff at the same time.

[rts18]

@rts18 so what layout would you suggest? I do that because I don't like moving radar over screen and I would like to see distance and alt diff at the same time.

@error414 I think you misunderstand my meaning. I have no issue with your fixed position radar concept.

I was merely stating, can you keep the layout of the radar icon information the same as it is on the HUD radar. But also include the altitude as requested by someone else. Irrespective of the symbols the user will select in their font package for items 1,2 and 3.

Based on the image in your post https://github.com/iNavFlight/inav/pull/9883#issuecomment-2037936459
It appeared you were looking at adding individual peer icon placement by the user, as with any other OSD element.

However from your last commit, it seemed you added cycling peers to one fixed icon, as mustard tiger suggested? I'm fine with either method. My only wish is the radar data layout remains the same for Fixed radar data as for HUD radar data. To avoid confusion for those who are already familiar with the present HUD radar layout, as seen in the first image I posted above.

[error414]

it's lattest test https://www.youtube.com/watch?v=sNFlpUCxnGM center-bottom is new one, others are old ones without any changes. Icon set in HITL can look diferent, icons ID should be same as original ones.

Peer E is quite hysterical, because there are three peers on the same place. ID of peers from inav radar VS OSD are moved, +1. See screenshot. So OSD peer E is peers D E F from inav radar.

It's necessary to test on the field because on the bench behavior could be quite different. I did not change anything about communnication INAV <-> INav radar so I expect it works well, just some issues on bench.

Maybe I will apply same restriction as there are for old inav radar elements, I would solve the issue.

And I'm thinking I will add next settings to cli, switch between inav and ardu style.

[MrD-RC]

Personally, I would keep the element the same as with the floating version. As in the same symbols, positions of the symbols, and positions of the data. People are used to how the floating version looks. So keeping the consistency would be good. Especially if they can have the floating version on one OSD layout and the fixed version on another. They should look the same.

basically like this. But relative altitude below distance. If both are shown.

I agree. Some pilots may prefer to see the relative altitude and distance from the other pilot at the same time. IMHO, this should be a parameter based option, giving pilots the choice. If they enable the option to see both. It should be on both the fixed and the floating versions. To keep them consistent. I would also put the relative altitude below the distance. This will give some separation between the relative heading and vertical direction arrows.

[druckgott]

Would be also cool to switch off/on icons what you want to have and what you do not need. Only in CLI on/off. So that everybody can select the chars/Icons... what is needed. For me for example I don´t need the Information about A/B/C because mostly we are only 2 people so all will be smaller. Also if you do only fly near the ground 30-40m you maybe do not need the information about altitude difference.

[error414]

I decided to keep is as it's on video .

https://www.youtube.com/watch?v=sNFlpUCxnGM

1. fixed version will be same as floating version, just will be visible distance and alt diff at the same time
2. no changes for floating version
3. fixed version will rotate through peer, time will be possible change by osd_radar_peers_display_time , default 2s
4. fixed version will can show max 4 peers

If I would use same layout for fixed element as it's for floating element, then there would be two changes base on time in elemet.

• peer A -> peer B -> peer C ......
• distance -> alt diif

I would say it's too much. If anybody is familiar with floating layout then will not be any problem to "decode" fixed layout.

[MrD-RC]

You should change the arrow on the fixed version to match the floating version. It needs to be as consistent as possible.

[rts18]

@error414 Looking fine. However I agree with @MrD-RC. The 3D peer heading arrow should remain for the fixed version as it is in the floating version. If the user wants to alter it to a 2D arrow. They can do so in their font package. This may seem to some as nit-picking. But I assure you, having a different arrow type helps to differentiate the heading element from the altitude element at a glance, when you're scanning over the data from multiple peers.

[error414]

Ahh, I forgot to mention it. Icons of fixed element will be exactly same as it's for floating version. I use defalt icon set in HITL plugin for xplane 11. Sometimes icons in xplane looks diferent. You can see on my screenshots that even floating version has weird 2d icon for heading.

[MrD-RC]

With X-Plane. You can put updated font in the plugin directory. They're a little bit buried. But look through the plugin and you'll find the analogue and digital fonts. It's useful when testing new elements.

[error414]

With X-Plane. You can put updated font in the plugin directory. They're a little bit buried. But look through the plugin and you'll find the analogue and digital fonts. It's useful when testing new elements.

thank you, now it looks much better in sumulator.

So, it works in sumilator, configurator is prepared, I will test it in field and then I will move pull request to review.

[error414]

tested on two planes on the field and it works like a charm

[Voltharion]

Thank goodness a coding wizard finally put a leash on that rogue OSD info. It was zipping around like a hyperactive squirrel on espresso

[P-I-Engineer]

anyway to get a 7.1.0 version of this? i'm having trouble getting it to build cherry picking this change in.

thanks

[error414]

anyway to get a 7.1.0 version of this? i'm having trouble getting it to build cherry picking this change in.

thanks

not sure if it works properly,

https://github.com/error414/inav/tree/release_7.1.1 https://github.com/error414/inav-configurator/tree/release_7.1.1

[P-I-Engineer]

spoof tested with inav7.1.1 cherrypick, works as desired.

i'd add it to cms menu though

#if defined(USE_GPS) OSD_ELEMENT_ENTRY("MAP NORTH", OSD_MAP_NORTH), OSD_ELEMENT_ENTRY("MAP TAKE OFF", OSD_MAP_TAKEOFF), OSD_ELEMENT_ENTRY("RADAR", OSD_RADAR), OSD_ELEMENT_ENTRY("MAP SCALE", OSD_MAP_SCALE), OSD_ELEMENT_ENTRY("MAP REFERENCE", OSD_MAP_REFERENCE), OSD_ELEMENT_ENTRY("FORMATION FLIGHT", OSD_FORMATION_FLIGHT),

[P-I-Engineer]

flight tested today, worked great

[P-I-Engineer]

can this get merged?

[mmosca]

@error414 can you fix the conflict in osd.h?