[feature request] buddy OSD navigation

[Daniel-1276]

Hi, since day one flying FPV I was always enjoying this great hobby together with some friends at the local flying field. I love to FPV around in formation with my buddies, but since the first days, it was always kind of difficult to meet "in air". I thought about this idea:

1.) Receive telemetry (GPS koordinates) data from your buddy on your airframe
2.) Add a second "buddy" navigation arrow to OSD (in parallel to home arrow) + up/down difference in relative height to your buddy.

First point could be achieved maybe by using some custom code from FrSky. Imagine adding a second cheapo receiver like the XSR or XM+, bind it to your buddy (that's where the custom firmware code comes in ... binding two receivers does not work at the moment) and than this second receivers outputs serial data to calculate in iNav with your buddies telemetry data (GPS). Alternatively there are telemetry radios available from the Ardupilot/APM/Pixhawk project, that could cover this functionality today or any bluetooth SPP device (may cause interference for 2.4Ghz radio control link).
-> Feature request @ FrSky already raised :-)

Adding the buddy arrow in INav OSD code should be rather simple. In general it could just be a second launch location that is "moving in the air" and relative altitude and "home arrow number two" just refers to that, to guide you to your buddy.

You are a developer and this sounds simple to be implemented? Please support this request and add my most missing feature since years in the FPV hobby :-D

Many thanks for reading along. Keep up the great work in iNav, this has reached a very mature level these days, good job !

Greetings, Daniel.

[VoicOfReason]

I like it.

[Pairan]

We talked about this lately too! Nice feature but surely not easy possible without additional and NEW hardware on the air frame.

Here are some ideas on that

• The hardware should be able to send and receive those buddy gps broadcasts and not use the 2.4/5.8 etc bands as it could collide with TX or VTX

Data in the broadcast could/should be like:

• GPS (needed of course for calculations of OSD data)
• HEADING (arrow, direction from "me" direction)
• ID (perhaps to add/block from beeing rendered)
• CALLSIGN (having a dot represents nothing useful)

The new piece of hardware shoudl be transceiver in this case! Sending its own data, receiving the data ot the others nearby

I did just take a look, what perhaps could do the job (hardware part) ... maybe a thing like this?

https://www.banggood.com/433MHz-Wireless-Transceiver-Module-p-1172989.html

But ... how the software would control it and how to "listen" to multiple transmitters ... i dont know.

Maybe these thoughts are useful to somebody

[Pairan]

I'm still digging on this module and the features of the above idea! Has anybody some knowledge on how to code that stuff?
Board documentation is here:

https://github.com/Bob0505/E32-TTL-100/blob/master/datasheet/E32-TTL-100_Datasheet_EN_v1.0.pdf

The Repo seems good!

The Module has a BROADCAST TRANSMISSION mode and an FIXED TRANSMISSION code:

Broadcast sounds just right:

"Set the Module adress to 0xFFFF, then the module can communicate with other modules on the same channel"

Further the module supports compression and encryption straight away! ...

Now, is it only me who like to read these features and finding the idea massive?

[Daniel-1276]

Hi Pairan,
thanks for your support and bringing in more ideas. In regards to hardware I think we would have a couple of options. First lets summarize, what's IMHO on the requirements list:

• Bi-directional communication
• Non interfering with GPS frequencies, 5.8Ghz VTX, 2.4Ghz radio control link. Maybe we have to add even more 868 and 915Mhz for crossfire / FrSky long range R9M hardware.
• Capability of doing full duplex, as I am unaware how that works if two (or even more) GPS buddy modules send 10Hz of data packets at once and un-synchronized.
• Sufficient bandwidth. UBLOX7 GPS mode in INAV seems to be most efficent. CMD command "gps_provider = UBLOX7", usable on UBLOX modules 7 and 8. If we send and receive this GPS data to both planes on a 10hz sampling rate, this could use ~5KiloByte/second of bandwith in sum. 1 GPS "PVT" sentence is around 100Byte x 10hz x 2 for bi-directional communication + buffer for errorcorrection and protocoll overhead. I guess 57600 baud seem to be a good starting point.

Possible design using telemetry modems:

• Enabling second "buddy" GPS serial port, receiving UBLOX PVT formatted location data
• (not defined yet) Telemetry modem connected in parallel to GPS module and "receiving" GPS serial port on the flight controller.

Wiring telemetry modem:
Telemetry modem --- GPS module --- FC buddy GPS port
RX ---> TX --- xxx
TX --- xxx ---> RX
VCC --- xxx ---> VCC
GND --- xxx ---> GND

Wiring from GPS perspective:
GPS --- telemetry modem --- flight controller (FC)
RX --- xxx --- TX main GPS port
TX --- RX --- RX main GPS port (in parallel to FC and telemetry modem)
VCC --- xxx --- VCC main GPS port
GND --- xxx --- GND main GPS port

Optimum design (IMHO) using standard FrSky receivers:
If we could get some custom firmware running on an cheapo frsky XM receiver that is bound to the main RX of plane 1 (behavior of that code more like a second TX radio module, sniffing/catching smart port data) and outputs received S.Port telemetry data to a serial port on the flight controller of plane 2. Not sure how that could work with more than two buddies, as you have to identify somehow, from which buddy you are currently receiving GPS data ... maybe we need some unique header data to identify plane 1, 2 and 3 ...
Benefits of that solution:

• FrSky sells more receivers and is maybe willing to support this idea :-)
• No interference with anything as no extra data packets are being sent
• cheapest solution in terms of additional hardware
• smallest hardware in terms of mounting the solution

Downsides:

• dependent on FrSky
• Not everybody flies FrSky

[Pairan]

hmmm ... personally I dont think we need another GPS to make it happen.

iNav knows where WE are and could handle the data (along the other stuff) to the LoRa thing for broadcast and in return get the latest data from "the others" out there.

So, I would assume an additional UART to be the only thing. Perhaps this could be something that fits perfectly to @digitalentity s extra board idea.

From my point of view this would be all requirements (aside from the code making the magic happen).

1. iNav sends "OUR" ID/Cords via UART to the LoRa transceiver
2. LoRa returns the latest Data via UART from the others which is processed and displayed in iNAV OSD

Summarized:
iNav FC <- UART -> LoRa/Telemetry modem

Other things to keep in mind

The OSD uses characters to show things- painting IDs and directions may not be possible by now and like that. Perhaps a full graphic osd is required! (i think only BRAIN has that)

Of course the frequencies are a problem. So many systems out there. But a low power "433 like" seems the best option in my mind.(e.g. the description says something about 410MHz) A predefined frequency could be used in order not to interfere with all the other transmitters/receivers.

Thats all from my 2 cents ... :)

[Daniel-1276]

Hi, you are right, I did not made clear how that parallel wiring of the GPS module is meant ... I will just update the wiring section in my last post ... in sum, only one GPS is needed. And I agree, if we need to add a telemetry modem, 433Mhz seems to be the best choice.

[Pairan]

Lets hope there are other people who would like this too!

[Daniel-1276]

https://www.youtube.com/watch?time_continue=1&v=5j0MPclUUm0 something similar that was ported to RemzibiOSD/minimosd, exactly what I was looking for :)

[Pairan]

that was back in 2012 ... today my expectations are a bit higher :) But the idea in pointing into the right direction

[FPVZaphod]

Nice idea...
I don't think a full graphic OSD is even required. If you find the way home with a simple arrow, why not to another plane? A simple List of all received positions with Name, Direction Arrow, Distance and Altitude Difference should be enough? Like:
Plane A 300m -13m >
Plane B 50m +22m ^
Plane C 48m -17m v
Always sorted by distance, used in an own OSD Page :-)

[stale]

This issue / pull request has been automatically marked as stale because it has not had any activity in 60 days. The resources of the INAV team are limited, and so we are asking for your help.
This issue / pull request will be closed if no further activity occurs within two weeks.

[Daniel-1276]

Any feedback from a developer about possibility for implementation?

[Pairan]

Still got the Modules in my shopping cart but the time is missing to start a code for prototyping. Hope somebody gets interested in this.

[wx4cb]

the problem you're going to have is, mainly radio wise.... it's going to be completely useless if you use 433 for control if you have it on uhf for example, same thing if you are going to use 900 meg, that rules out crossfire users

[fiam]

On raven the exchange of data happens both on the air and on the ground, using 2.4Ghz in both cases. When data is exchanged on the group (from TX module to TX module), each aircraft gets the data for the others via the uplink telemetry link (each TX with its paired RX). It works fine as long as no pilot is using 2.4Ghz for RC (using it for video would make the direct aircraft to aircraft not work, but they would still exchange the data via the pilots on the ground).

[Pairan]

i think the attached module is able to be adjusted down to 410MHz and of course 25mw or less :) ... perhaps this leaves a small window for communication between the position radios

[wx4cb]

@fiam and that's going to be the problem you're going to have irrespective on what frequency you use because if there's something already on there, control or video for example, it's going to render one of them useless. Plus EVERYONE is gong to need the same frequency.

as far as tuning @Pairan now you're getting into the realms of legalities. for example, US users can use 420-450, whereas uk users can only use 420-450 providing they have their amateur radio license and operate within the auspices of that (which you should be anyway right :D)

Now especially in the UK, there is a TON of 70cm band repeaters and video repeaters as well that you would have to contend with. not so much here in the us i think (only speaking of FL), but when you're talking about a small module that's pumping out 25mW pep compared to a repeater thats potentially pumping out upwards of 25 watts, guess which is going to get swamped :D

Now of course, the use of such equipment ultimately lies with the operator of said equipment, however I can think of a much easier way to do it (next post)

[wx4cb]

why even worry about having it onboard the aircraft at all? other than the fact you can fly with a buddy that's not standing next to you, why not just have something that can be hooked together in a simple network (can be done with arduino as i've done similar things), it pulls the telemetry data from the transmitter you're holding in your hands and then just outputs it to an osd that can be overlaid with what you already have - similar to the way the dock king works. much easier, less interference to rc/video links, no legal issues arising (that i can see but IANAL) and you can have as many as you want on there

[fiam]

I want the data to reach the aircrafts because it lets the FC implement other interesting features like automated following, formation flying, collision avoidance, etc...

[Pairan]

why even worry about having it onboard the aircraft at all?

I see your point, but here comes mine: why transmit a lot of data back an forth if the only place of importance (speaking from my point of view) is in the osd which is rendered in the fc ?

It doesnt matter to me, which side frequency we use... Im fine with 420MHz too! I simply wanted to get away from 433/XF/1.3/2.4/5.8 :)

[Daniel-1276]

I agree on the interference issue. This will most probably kill any "one for all" solution. I think a solution that is able to capture surrounding telemetry data streams from other FrSky receivers would be best. This would add a receiving component to each model, but not sending. I have asked Simon from https://github.com/fishpepper/opensky to see if he may could modify his USKY receiver to receive GPS telemetry pakets, including ID of the sender. Each FrSky sender has it's own ID and passes it to the receiver while binding procedure. I assume this ID is also used to send back telemetry data to the TX and could therefore help to identify the source and to have a unique relation to GPS data and the source plane :)
Another attempt could also be, by using Arduino Nano/Micro/whatever and a CC2500 board including some FrSky RX + Telemetry protocol here on github. Maybe a DIY "capture all"/ "monitoring mode" device could be developed, with some efforts.

[lgojniczek]

Hi, if you are interested in some kind of Multiplayer mode to help everyone to find each other and create some kind of formation I could help as I am an author of Android application named TrackMyRC². It is still in test phase but I'm going to release it soon as it passed all the test successfully.

You can see it in action here https://www.youtube.com/watch?time_continue=39&v=diaqSy9UehY and here https://www.youtube.com/watch?v=fO28dZgoC7Q

It supports eLeReS, Pitlab and is almost ready to support native FrSky telemetry protocol (is ready to support more proto as it has abstract telemetry layer).

Here is more photo http://rc-fpv.pl/viewtopic.php?f=4&t=43942&hilit=trackmyrc2&start=45#p562122

Of course english version is available.

Feedback is really appreciate

[putimir]

Looks awesome! Can you join the inav radar FB group (https://www.facebook.com/groups/360607501179901/) and have a chat with the guys....we are already flying some alpha versions but are still having some issues...thanks