Thank you, I will thus limit the aircrafts transmitted to the auto-pilot to some reasonable limits.
I shall thus generate the heartbeat, any suggestion what sysem-id I should use ?
For testing: would it be possible that this gets tested with two or more drones, so we don’t risk “real” aircrafts ?
It would be enough to install OGN-Tracker with every drone and they would see each other and hopefully should avoid close encounters. I am struggling to make my own drone, but I would need at least two - well, I can generate simulated traffic too.
OK, I am now able to send (and receive on the other end) some MAVlink messages, to start my OGN transmitter/receiver is sending time and position which is probably not useful here, but I needed to test MAVlink message functionality.
I still don’t know what Sys-id I should specify in my MAVlink messages ?
Shall I generate HEARBEAT ? There I should specify autopilot, etc. but I am not autopilot, simply a transmitter/receiver with possibly a GPS and pressure/temperature sensor.
I am not sure what information apart from ADSB_VEHICLE shall I send to the autopilot ?
Functionality is about same as the ADS-B receiver, so I could use same component-id or would it go into conflict if some plugs in another ADS-B receiver ?
If I create a new component, let’s name it “OGN” instead of “ADSB”, would I need as well to create a separate message-id ? Then the functionality would not work, only until this is all accounted for in the next software version ?
Yes to heartbeat and I agree using the adsb comp id, but it would conflict if a pingRx etc was also connected. Perhaps do the testing with 156, as a starting point. You don’t need a new message though, if you change comp id.
I’ll need to look into how flarm is managed: would be best to be consistent.
I keep trying to make ArduPilot run with the messages coming from the OGN Tracker.
I send the ADSB_VEHICLE message but it seems not be have any effects, while those sent by the ADS-B receiver do have, thus what is the difference, where could I learn how to make my messages accepted ?
As part of an internship I have developed a reactive collision avoidance algorithm using a camera and OpenCV framework. However, I cannot find any reference on how to send MAVlink messages to the FCU in order to steer left/right or to relocate an existing waypoint (maybe also create a no-fly zone, in case of an extended obstacle).
The only references are in Python while for C/C++ the always linked (without any proper explanation though) https://github.com/mavlink/c_uart_interface_example doesn’t seem to work with Pixhawk/Ardupilot properly.
Would it be possible to allow address in the ADSB_VEHICLE to be at least 26bits, not 24 ?
This would help to keep the uniqueness thus avoid possible clashes between ICAO, FLARM and OGN or whatever other systems might be in operation.
Another thing: EMITTER_TYPE, would it be possible to add a subset of the types used in FLARM/OGN ?
I am translating now, but direct copy would be easier and there is space for it as the emitter type is 8 bit and only few values are used this far. For example one of the higher bits could mean FLARM or OGN and the four lower bits would contain the aircraft-type used by FLARM/OGN.
The AP_AVOIDANCE library can detect external aircraft from two sources:
GLOBAL_POSITION_INT
ADSB_VEHICLE
Regardless of which source, it gets turned into a common “obstacle” object.
This allows you to automatically sense other aircraft via MAVLink, not just via ADSB. Yuu don’t need to override the ADSB_VEHICLE message; just send a heartbeat and a GLOBAL_POSITION_INT message. This works great in WiFi networks for swarming for “just works” avoidance where all the drones can hear each other’s data.
regarding EMITTER_TYPE. Those are official enums from the ADSB spec. I’m not sure how I feel about adding values to it, I’d like to see what behavior ADSB hardware has in case those values were accidently broadcasted. We would need to ensure we check that when sending an ADSB_CFG msg… but it’s possible.
Regarding extending ICAO numbers to 26 bits, what does FLARM and OGN use? I don’t see any mention of a unique number in this FLARM document.
Instead of overriding bits in the ID or an upper nibble of the emitter type, how about adding a flag to ADSB_FLAGS?
Yes, adding a two-bit flag with the meaning “address-type” would be just fine.
Ideally, the address-types should be:
0 = Random address
1 = ICAO address
2 = FLARM address
3 = OGN-Tracker address
This would correspond to what FLARM and OGN-Tracker are using.
FLARM actually uses 0,1 and 2, OGN-Tracker 1 and 3, possibly 0 as well.
0=Random is when an aircraft either does not know what address to set or it wants to hide its identity.
1=ICAO is when FLARM or OGN Tracker are set to use the assigned ICAO address of the aircraft (if the aircraft has an assigned ICAO address).