Anonymous: Interested if there were any remote ID discussions lately.
We did not hear of any. How much of it is already being done? When is the next deadline?
1 year out companies should produce remote ID capable products and 2 years from now it’s starting to get mandatory to be able to fly. https://www.faa.gov/uas/getting_started/remote_id/ Standard Specification for Remote ID and Tracking
The user is interested because he has to deliver a drone in 2023 which should be FAA compliant in terms of remote ID. There are already messages in PX4 but it needs to be checked if they satisfy the requirement. Presumably, a specific piece of hardware needs to be used and supported.
Apparently the requirements are pretty open and it’s mentioned the community should settle on a standard. It’s apparently not ADSB and there is no big movement or exact requirements or hardware yet.
@mwbb Holybro X500 2 is merged and he’s continuing with flight testing.
He has a question about a flight where he had altitude hold problems: https://review.px4.io/plot_app?log=21beb351-f2bb-4767-b71f-725946098ec0
It’s suggested that he opens a GitHub issue with a description of what happened such that we can follow-up and help with any
The plan is to make a new PX4 hardware dev kit with this frame and a Raspberry Pi. It will get available once it’s fully developed and tested.
Conor: Is using PX4 with a high fidelity simulator that is not running real time. There is lockstep for the simulation but he noticed an error poping up whenever the simulation takes longer than a second to respond.
Place in the code this message is coming from: PX4-SITL_gazebo/mavlink_interface.cpp at master · PX4/PX4-SITL_gazebo · GitHub
This error is meant for debugging and is basically a warning to signal that the simulator is possibly hanging. If the simulator takes long this timeout can be ignored/increased. There seems to be a problem where if the error occurs it does not wait further for lock step but just continues.
Project Updates
@Jaeyoung-Lim and Thomas Stastny were working on a design document for fixed wing path tracking. Any feedback is welcome. Short summary: Flying fixed-wing very close to terrain is not very safe when operating with just waypoints so the goal is to have a pretty accurate and feasible path to make the fixed-wing flight predictable and safer. The first part to make it happen was to get the fixed-wing position controller be able to work in local frame. Discussion about how to structure fixed-wing control and setpoint generation together with the plans of the future of modes similar to how flight tasks work but in a more general way.
@rroche was working on the docker containers following up on the discussion last time. There’s now an in tree docker file which uses the existing setup scripts and it can build almost all targets. For sure all NuttX and simulation.
@MaEtUgR Found a bug in a rare case of handling a specific invalid multicopter position control setpoint.
ThomasDebrunner: SIH in SITL now works.
If you have any feedback or corrections please comment on this post.
