We had a very productive TSC call today. This is a summary of what was discussed for those of you who couldn't make it.
The first topic was the status of ADSB hardware and the software to take advantage of it. We had Matt Lee from uAvionix join the call to describe the status of their Ping range of products, and Tom Pittenger described the status of the software side of ADSB support (along with the associated MAVLink messages).
On the receiver only side uAvionix have the Ping which receives on both 978MHz and 1090MHz. It provides ADSB_VEHICLE MAVLink1 packets over a serial interface. Support for the Ping is integrated in both the PX4 and ArduPilot flight stacks. In current releases the functionality this enables is primarily situational awareness for the GCS operator, with GCS implementations able to display other aircraft on the map.
The discussion then centred on providing more functionality for avoidance. We looked at two proposals. One is from Peter Barker which adds a COLLISION MAVLink packet and a set of avoidance strategies designed with ADSB applications in mind.
The PR for ArduPilot is here:
The associated MAVLink changes are here:
There was consensus that the COLLISION packet should provide more information on the location of the threat by including int32 lat/lon and float altitude (as AMSL). That would allow a GCS to display the threat in a way that can be shown visually on the map. The COLLISION_TYPE is also not defined.
We then looked at a very different approach to a similar problem that Lorenz has been taking. He is focussing on a setup where the avoidance calculations are being run on a companion computer and where the avoidance may be vision based. The proposed MAVLink additions are shown here:
these provide a lot more information on the vehicles planned flight path, with information that would allow a spline fit to be displayed to a user. The PLANNING_TRIPLET message provides information from the autopilots navigation code on where it wants to navigate if there are no obstacles (so it is essentially a moving window on the user defined mission). The AVOIDANCE_TRIPLET is a reply from the avoidance subsystem on the companion computer telling the autopilot a new path that will avoid objects that have been detected.
There was some discussion on time stamps and reference frames for these packets. The "micros since boot or unix epoch" in the packets is commonly used in MAVLink but is not well defined. The use of local NED frame is problematic for avoidance systems on a larger scale (such as with ADSB) where the origin may not be known to the recipient.
Next we discussed the Ping 20-20 which is a full transponder, with the ability to transmit and receive on 978MHz, and receive-only on 1090MHz. That makes it suitable in the US for inter-drone avoidance. Matt described a timestamp based method to allocate ICAO numbers in the packets which avoids the need for registration. That opens up use by a much wider variety of users. Allocation of ICAO IDs is more difficult for 1090MHz used outside the US.
Matt has proposed a set of 3 MAVLink1 messages for giving the Ping 20-20 the information it needs to transmit. The fields closely follow the DO-282B standard. Matt, could you post a public link to the proposed messages if possible? Unfortunately DO-282B is quite an expensive standard to purchase, so we will also need a description of the fields that reference that standard without having to have a copy.
We discussed the issue that all these new MAVLink1 messages are quickly consuming our remaining MAVLink1 message IDs. In fact, the proposed message IDs for the Ping 20-20 overlap with an existing ID (the GIMBAL_CONTROL message 201). Matt and I discussed the possibility of uAvionix using MAVLink2 for the 20-20 so that the larger message ID space and the ability to extend messages can be used. Matt will investigate that and I offered to provide technical assistance if needed.
Tom asked if we could have a compile time option to disable MAVLink2 signing. We could do that if needed, although the memory overhead of having it compiled in is already very small so it may not be needed. We will decide based on feedback from Matt.
The next major topic was an update on Pixhawk hardware. Philip started with a Pixhawk2 update, with plans for an initial run of 50 boards to be produced soon, followed by a run of 500 boards after that. Key features for the Pixhawk2 are the flexible carrier board system, the larger flash space available, the MPU9250, the vibration isolation and the IMU heating.
Plans are also underway to start supporting F7 based boards. This will require some significant bringup work at the NuttX level, but will give a big boost in CPU performance and memory.
The remainder of the call focussed on plans for firmware versioning for the new boards, along with bootloaders and USB identifiers.
For firmware versioning, it was decided we should call the Pixhawk2 FMUv3, but also advertise the fact that FMUv2 firmware will run unmodified on FMUv3 boards. Use of FMUv3 firmware will be required to take advantage of the additional flash space of the Pixhawk2. Philip noted that some Pixhawk1 units do have the fixed stm32 hardware revision that has 2MByte of flash available (and safe to use).
For USB string IDs we decided it would be best to start using the "Pixhawk" name in the string ID. So a device may show up as /dev/serial/by-id/usb-Pixhawk_v3.x_0-if00 on a Linux system (for example). This provides a vendor neutral string identifier.
The more problematic issue of the USB vendor ID was also discussed, but not fully resolved. Currently a VID assigned to 3DRobotics is used by many vendors of Pixhawk compatible hardware. The USB VID is controlled by the bootloader and flight firmware and we discussed if it may be possible for the flight firmware to inherit the VID from the bootloader.