The TSC Working Groups provide brief summary updates here. More detailed monthly status updates may be found in the Dronecode blog here.
The SDK WG has made significant progress:
- Dronecore gRPC bindings moving forward for multiple language support
- Docker image to be created for development using Dronecore
- Documentation of DroneCore C++ API moving forward and has near-complete coverage.
- Need a SW designer look at the design of DroneCore for vendor extensibility. Currently task on hold due to lack of developer bandwidth.
- Release 1.8 should support extensibility
- Offboard Control API added
- Example: https://github.com/dronecore/DroneCore/pull/134
- PR for API documentation: https://github.com/dronecore/docs/pull/53
Camera API WG
- Camera control protocol changes have been merged into to QGroundControl.
- Intel to share details of drone apps processor code – https://github.com/01org/camera-streaming-daemon
- SITL camera module development
- Proposed design here (in progress)
- Gets frames from Gazebo camera
- Video Streaming
- Mavlink messages for video streaming delayed until docs for camera control complet
- The messaging WG will also be working with the SDK WG to evolve the SDK in ways that may not work well over MAVLINK.
- The biggest missing piece of the RTPS support is broader testing
- EProsima is going to have a look at this.
- The VIO samples using RTPS should be completed
- RTPS refactoring
- Serialization code should be pre-generated in its own layer so the Agent code need not depend on all of Firmware and its submodules
- FAA Application for Dronecode stack certification with Intel. Upcoming calls, but still moving forward.
- FAA not concerned with security but other agencies are (ala DJI). Talking to other agencies about security issues (XCOM, Dept of Interior, EPA, etc).
- Concern voiced about safety of a platform not addressing platform security and data security
- Threat analysis needed
- Opportunity for transparent process of how data is handled by the platform
- Discussed using ROS2 security model and also supporting proprietary solutions (e.g. FLIR, INSITU)
Code Quality WG
Progress in Code Quality is being made on several fronts:
- Architecture Refactoring
- NuttX update that was previously blocking other refactoring work has been merged
- I2C NuttX drivers are now cross platform via vdev. SPI devices not supported yet (missing a handful of things in drivers/device).
- PX4 v1.8 release targeted for refactoring the drivers to use vdev and hopefully moving DriverFramework drivers to use vdev.
- Rearchitecture proposals for vendor layers were prototyped, and provided for comments
- Latest one is here: https://github.com/PX4/Firmware/issues/8127
- Proposal for Offboard Module Architecture
- HW Support
- Not clear to new users what HW platform they should start with
- List what is known good HW
- RPi – best effort vs Intel Aero (supported)
- Need new categories
- Experimental HW
- Unmaintained HW (mfg’s who create non-compliant products, poor build quality)
- Supported HW
- Need quality standards for HW vendors to self certify
Group activities has been suspended until WG participants have more time available to contribute.