Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fixed position for formation flight / inav radar #9883

Merged
merged 2 commits into from
Jun 22, 2024

Conversation

error414
Copy link
Contributor

@error414 error414 commented Apr 2, 2024

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: iNavFlight/inav-configurator#2029

8f333d5b-e943-4b2b-b7a0-7991049f8d43
5054bb9c-d24d-4f45-bd06-f7abd16d8831

@Jetrell
Copy link

Jetrell commented Apr 2, 2024

@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
Copy link

rts18 commented Apr 2, 2024

@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
Copy link
Contributor Author

error414 commented Apr 2, 2024

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

Screenshot_1
Screenshot_2

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

@Jetrell
Copy link

Jetrell commented Apr 3, 2024

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
Copy link
Contributor Author

error414 commented Apr 3, 2024

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:
Screenshot_4
Screenshot_3

@P-I-Engineer
Copy link
Contributor

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
Copy link
Contributor

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 ArduPilot/ardupilot#25684 where I've included a screenshot of what the element looks like in flight.

@Jetrell
Copy link

Jetrell commented Apr 3, 2024

@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
Copy link
Contributor Author

error414 commented Apr 4, 2024

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

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:
Screenshot_6

Walksnail:
Screenshot_7

@MrD-RC
Copy link
Collaborator

MrD-RC commented Apr 4, 2024

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
Copy link

rts18 commented Apr 5, 2024

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

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

Capture

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

Capture

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

Capture

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
Copy link
Contributor Author

error414 commented Apr 5, 2024

@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
Copy link

rts18 commented Apr 6, 2024

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

Based on the image in your post #9883 (comment)
It appeared you were looking at adding individual peer icon placement by the user, as with any other OSD element.

image

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
Copy link
Contributor Author

error414 commented Apr 6, 2024

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

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
Copy link
Collaborator

MrD-RC commented Apr 6, 2024

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
Copy link
Contributor

druckgott commented Apr 7, 2024

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
Copy link
Contributor Author

error414 commented Apr 7, 2024

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
    Screenshot_11
  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
Copy link
Collaborator

MrD-RC commented Apr 7, 2024

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

@rts18
Copy link

rts18 commented Apr 8, 2024

@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
Copy link
Contributor Author

error414 commented Apr 8, 2024

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
Copy link
Collaborator

MrD-RC commented Apr 8, 2024

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
Copy link
Contributor Author

error414 commented Apr 8, 2024

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

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

@error414
Copy link
Contributor Author

error414 commented Apr 13, 2024

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

@error414 error414 marked this pull request as ready for review April 13, 2024 12:12
@Voltharion
Copy link

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

@DzikuVx DzikuVx added this to the 8.0 milestone Apr 21, 2024
@P-I-Engineer
Copy link
Contributor

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
Copy link
Contributor Author

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

@error414 error414 force-pushed the fixed-formationflight branch 2 times, most recently from bb53a28 to ceba26a Compare April 23, 2024 17:45
@P-I-Engineer
Copy link
Contributor

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
Copy link
Contributor

flight tested today, worked great

@P-I-Engineer
Copy link
Contributor

can this get merged?

@mmosca
Copy link
Collaborator

mmosca commented Jun 21, 2024

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

@error414
Copy link
Contributor Author

pullrequest is rebased to master. Configurator iNavFlight/inav-configurator#2029

BTW: just I noticed that OSD element https://github.com/iNavFlight/inav/blob/master/src/main/io/osd.h#L288 is not in configurator. ID: 152 (OSD_BLACKBOX) is missing, there is only 151 (ADSB_INFO) and then 153 (FORMATION_FLIGHT)

@MrD-RC
Copy link
Collaborator

MrD-RC commented Jun 22, 2024

The blackbox stuff is in iNavFlight/inav-configurator#1941

Looks like it was bumped to 11 on master already, going +1
@mmosca mmosca merged commit a42af76 into iNavFlight:master Jun 22, 2024
22 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

10 participants