[Architecture Advice] Best practice for P2P (LoRa) Collision Avoidance integration?

Hardware Companion Computers
1

Hello ArduPilot Developers and Community,

My name is Ryota, and our team is developing a collision avoidance system based on a P2P mesh network using LoRa (likely based on Meshtastic).

Our architecture consists of:

  1. Companion Computer (Commander): A Raspberry Pi / CM4 running C# (.NET) on Linux. This is the “high-level” layer.
  2. LoRa Module (Artisan): A “low-level” nRF52840-based module connected via UART/USB to the Companion Computer. This module handles the raw P2P mesh networking.
  3. Flight Controller (FC): ArduPilot (e.g., Pixhawk, Cube, or ArduPilot on Linux).

The Companion Computer (C# app) will receive the position/vector of other aircraft via the P2P LoRa mesh.

Our Question Is:
What is the “best practice” (most ArduPilot-native way) to feed this external aircraft position data from our Companion Computer (C#) into the FC, specifically to integrate with ArduPilot’s standard Proximity Avoidance feature (AVOID_ENABLE)?

We want to choose the “cleanest” method that avoids modifying the ArduPilot C++ core if possible.

  • Option A: Should our C# app generate and stream OBSTACLE_DISTANCE messages (perhaps at high frequency) to the FC?
  • Option B: Should our C# app generate and stream ADSB_VEHICLE messages (spoofing them, as if from an ADS-B receiver) to the FC?
  • Option C: Is there a better, more standard message we should be using (e.g., TRAFFIC_DATA, COLLISION)?
  • Option D (Worst Case): Is our initial idea correct—that we must define a new custom MAVLink message (like P2P_MESH_NODE.xml) and submit a patch to the ArduPilot core to interpret it?

We are trying to build this the “right way” to be a good citizen of the ArduPilot ecosystem. Any architectural advice on the cleanest MAVLink path (A, B, C, or D) would be greatly appreciated.

Thank you,
Ryota

1 Like
2

Ideally you would define a new obstacle source and add appropriate mavlink messages and handlers as you are providing neither ADSB data nor another MAVLink vehicle position (as you are fairly likely to run into Sys ID collisions) in literal sense.

Spoofing ADSB_VEHICLE messages should be fine outside of serious production environment, consider using invalid ICAO_address values to avoid collisions with actual ADSB.

TRAFFIC_DATA seems not to exist (AI seems to be good at conjuring things out of thin air).
COLLISION is reporting message for the subsystem that does the evasion.

1 Like
3

Certainly. Here is the concise thank-you message in English, without any internal project details.

Hi ,LupusTheCanine

Thank you for the extremely clear and helpful advice. I’m relieved to get validation that using ADSB_VEHICLE messages (for demo purposes) is a reasonable approach.

In particular, your point about using an invalid ICAO_address to avoid collisions with actual ADSB is a critical safety perspective I was looking for. I will proceed with this implementation based on your advice.

Your note that defining a new MAVLink message is the ideal path for a “serious production environment” is also very helpful for our long-term planning. (And thanks for the correction on TRAFFIC_DATA.)

I truly appreciate you taking the time to share your expertise.

1 Like