# PX4 Dev Call: January 05, 2022 **URL:** \ **Category:** PX4 Autopilot\ **Created:** [December 29, 2021, 6:00pm UTC](https://discuss.px4.io/t/px4-dev-call-january-05-2022/25598 "2021-12-29T18:00:05Z")\ **Posts on this page:** 2\ **Page:** 1
**Author:** ![rroche](https://discuss.px4.io/user_avatar/discuss.px4.io/rroche/32/17635_2.png) [@rroche](https://discuss.px4.io/u/rroche)\ **Post date:** [December 29, 2021, 6:00pm UTC](https://discuss.px4.io/t/px4-dev-call-january-05-2022/25598/1 "2021-12-29T18:00:05Z")
# January 05, 2022 ## Join us > **[Jitsi Meet](https://meet.jit.si/PX4DeveloperCallWeekly)** > > Join a WebRTC video conference powered by the Jitsi Videobridge ## Agenda - Community Q&A - Project Updates - High priority queue - Release - In-Depth discussions * * * ## Community Q&A - Question about an airframe for a coaxial quadrotor with tiltable motor planes. Example: [https://www.youtube.com/watch?v=0zNO2s58rMY](https://www.youtube.com/watch?v=0zNO2s58rMY) This should be well doable with dynamic control allocation now since every actuator has an actuation direction and it can even change mid-flight. With the old mixer system, it was only possible with workarounds. - @bresch When commanding vertical velocity for a multicopter we now use the same velocity limits for the setpoints and hard limits in the controller. That means if the setpoint is already at the cmaximum the veritcal position controller has no authority to correct anymore. ## Project Updates - @MaEtUgR Slight improvement in offtrack logic during mission gotos when altitude is not met: > > > \*\*Describe problem solved by this pull request\*\* > When sending consecutive repos…ition commands to a multicopter that contain different altitudes and not waiting until the previous target position was reached there's very strange behavior. > > \*\*Describe your solution\*\* > This solves one of the issues when switching goto target mid-flight where the altitude overshoots. Only the horizontal path between waypoints was considered in the "off-track" calculations. I'm using the exact same calculations just in 3D to also consider the altitude. > > \*\*Describe possible alternatives\*\* > Further improvements with unexpected waypoint changes require architecture changes to solve properly and are work in progress with the new mode architecture. > > \*\*Test data / coverage\*\* > I tested this in SITL and SIH and the switching has fewer issues. It still does an overshoot but converges to the right path fairly quickly while before if the altitude didn't match it could get stuck for quite some time and start wobbling back and forth. > > \*\*Additional context\*\* > SIH Example before: > !\[image\](https://user-images.githubusercontent.com/4668506/148204467-47da7ed2-5a07-460c-b27e-68f0f540a0c5.png) > > > SIH Example after: > !\[image\](https://user-images.githubusercontent.com/4668506/148204352-d0718056-e342-465b-a8ae-ad93cc013deb.png) - @JulianOes Fuzztesting over MAVLink. Old pr from 2019 that’s refurbished and almost ready to merge. It sends random bytes that pass the CRC but are garbage potentially causing parser corruption. It could be ran on prs or regularly at night. Regularly is preferred since the randomness could lead to confusion and getting ignored on prs. Here’s an example on a bug that was found using this testing method already: [generator: fix off-by-one in mavlink\_get\_msg\_entry by julianoes · Pull Request #343 · ArduPilot/pymavlink · GitHub](https://github.com/ArduPilot/pymavlink/pull/343) > > > This adds the env option PX4\_FUZZ which runs the LLVM libFuzzer which throws ran…dom bytes at mavlink\_receiver using MAVLink messages over UDP. > > The MAVLink messages that are being sent are valid, so the CRC is calculated but the payload and msgid, etc. are generally garbage, unless the fuzzing gets a msgid right by chance. > > As I understand it, libFuzzer watches the test coverage and will try to execute as much of the code as possible. > > To run this, do: > > \`\`\` > PX4\_FUZZ=1 make px4\_sitl\_default-clang && (cd build/px4\_sitl\_default-clang/tmp/rootfs && mkdir CORPUS -p && ../../bin/px4 -detect\_leaks=1 CORPUS/) > \`\`\` > > To stop it (if it never crashes): \`killall px4\`, or Ctrl+C. > > So far I've been running this multiple days on a desktop computer but have not found anything. ## High priority queue Discussion based on board: [https://github.com/orgs/PX4/projects/24](https://github.com/orgs/PX4/projects/24) ## Release No news at the moment. ## In-Depth discussions There were no in-depth topics. * * * If you have any feedback or corrections please comment on this post. ---
**Author:** ![Jaeyoung-Lim](https://discuss.px4.io/user_avatar/discuss.px4.io/jaeyoung-lim/32/10829_2.png) [@Jaeyoung-Lim](https://discuss.px4.io/u/Jaeyoung-Lim)\ **Post date:** [January 5, 2022, 11:53am UTC](https://discuss.px4.io/t/px4-dev-call-january-05-2022/25598/2 "2022-01-05T11:53:05Z")
@rroche This event is not in the dronecode calendar. Is the Dev call still happening today?