WingMan - 'iNav-radar' like audio call-outs.

[50UR4V]

Is your feature request related to a problem? Please describe

Today the way iNav radar is implemented using an TTGO (ESP32+LoRa) board is great but here is a list of issues that I see.

1. Relying on in-craft hardware that is not very cheap.
2. Adding another bit of RF equipment with a different frequency on the craft (not ideal for long range)
3. Though the visual clue about the position of your co-flyer is great but then it crowds up the OSD and with lag can be misleading. (needs significant delay tuning)

Describe the solution you'd like

The idea is to exchange telemetry data between the pilot radios using the serial ports on openTX / EdgeTX based radios. Next do a bearing calculation in the respective radio and 'speak out' the bearing in a 'Clock-bearing & Altitude' format.
More detailed steps (refer to the attached image):

1. Radio A receives full telemetry data from the craft. (already exists)
2. Radio A sends its data (GPS position, Altitude, ground course, speed, craft name) via a serial port (E.g. AUX1 on the TX16S) - requires the serial port to be configured as LUA in the radio settings -->hardware of EdgeTX??
3. Radio B receives the data (about craft A) via its serial port (e.g.AUX 1 on the TX16S) . While also sending out its own data packet on the same port.
4. Radio B runs the data from craft-A through a modified version of radar.lua (which already has heading calculations) in the scripts-set. sends the results as clock-bearing, altitude and speed callout in Audio.

For the new radios with bluetooth and headphone jacks built-in (like the TX16S mark2)... it will not require any additional hardware.

Typical use case scenario (imagined)

1. Pilot A /Pilot B (user-s) connect bluetooth modules and headphones to their radio's AUX1 and headphone jacks respectively.
2. Users configure the radio to let LUA access the AUX1 port. (radio settings --> serial port in EdgeTX)
3. There is already a screen configured with a full screen widget for the iNAV LUA script. User enters the config screen using stick positions.
4. <<we will need a method to setup the bluetooth connection between the radios... maybe there exists another LUA script to set up... mode/pin/name/pairing etc...for the bluetooth modules>>
5. Navigate to the 'WingMan' option on the list and change it to 'ON'. and set the audio callout volume on a switch... (maybe other preferences can be configured here)
6. They launch their crafts and if one user raises the volume slider all the way up, the radio speaks into the earphone "Keith, 2 O'clock 50meters away, Altitude 85 meters, 65 kilometers per hour" (Keith is the other craftname)
7. Once the user has sights of his 'wingman', he can flick the toggle switch to make the volume (only for this feature) zero (inaudible)... but the entire system keeps doing the calculations. of tracking each wingman!

Describe alternatives you've considered

• I have seen the iNav Radar with ESP32+LoRa being used. I think that is an overkill for what it achieves.
• I dont know well about BLE 4.0 and 5.0... maybe they allow mesh networks with multiple pilots?

Additional context

I have been running EdgeTX on TX16S with ELRS for control+telemetry so many of the assumptions and references are to the same setup. I have tried to be as generic as possible after studying a bit of the codes/features from all of these projects.

I could have dug down and coded the project myself. But I guess, with my coding skills it would take ages!... and there are others out there who can do it faster and more efficiently. I dont believe the effort is very high compared to the features/benefits. I am happy to help/discuss with anyone who plans to take this up.

[50UR4V]

@fiam @stronnag : Just tagging Alberto and Jonathan (developers of the radar part of the widget), to get some quick feedback about the idea itself. (maybe it is stupid and can be closed accordingly) I dont want to crowd the development pipeline of an already well managed project.
Also, the attention of @OlivierC-FR as the developer of the inav-radar project.

[stronnag]

There are no resources to work on this idea, regardless of its feasibility.

[973nN]

@50UR4V Fabulous idea, and it will work. Totally agree that using another RF board inside crafts is not the best idea specially for medium / LR flying.
Immediate benefits I see here:
a) No changes / rewiring needed on the crafts
b) no extra hardware required on the craft
c) Simple BT based boards to run this feature ( we got to check how this might work with say for example with the TBS full module on a Taranis) - otherwise with the BT based boards, just plug the board behind the radio and your good to go
d) As you rightly called out, a future possibility of this working with more than 2 pilots at a location
e) Since it will be based fully on telemetry data, less chances of lag issues

[sensei-hacker]

Broadcasting the location of your craft is Remote ID - those in the US are already required by law to broadcast this information, starting soon..It seems likely that other countries may follow. You might consider receiving and processing the signal they are required to broadcast anyway. Rather than asking them to send it redundantly, over a different protocol.

<<we will need a method to setup the bluetooth connection between the radios... maybe there exists another LUA script to set up... mode/pin/name/pairing etc...for the bluetooth modules

Bluetooth pairing is short-range one-to-one communication. Better would be broadcast so all pilots in the area can see it, including the pilot on the other side of the park whom you don't know about.

[50UR4V]

@sensei-hacker : That's a great idea... Though I am not sure, it meets the strict remote ID guidelines. Since (in the above described architecture) the Broadcast would happen from the base station or radio controller. Not the craft.
However, with a cellphone receiving (broadcasts) and posting these packets to the internet solves the problem in a similar way DJI is doing it today...

[sensei-hacker]

Though I am not sure, it meets the strict remote ID guidelines. Since (in the above described architecture) the Broadcast would happen from the base station or radio controller. Not the craft.

Yeah given that within a few months,the same data will be broadcast from the craft (for many users), I wonder if it makes any sense to send duplicate data from the transmitter?

Perhaps the transmitter could send the data only if the craft isn't already sending it - and the transmitter could send it in the exact same way that the craft would.

Meaning the receiver could receive it without knowing or caring whether the info is coming from the craft or from the transmitter. The receiver just receives the data- it doesn't care which part is transmitting it. :)