# PX4 Dev Call: March 23, 2022 **URL:** \ **Category:** PX4 Autopilot\ **Created:** [March 16, 2022, 5:01pm UTC](https://discuss.px4.io/t/px4-dev-call-march-23-2022/26615 "2022-03-16T17:01:23Z")\ **Posts on this page:** 1\ **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:** [March 16, 2022, 5:01pm UTC](https://discuss.px4.io/t/px4-dev-call-march-23-2022/26615/1 "2022-03-16T17:01:23Z")
# March 23, 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 ## Moderation - After **5 seconds of silence, move onto the next topic** - **Community Q&A : Maximum 3 - 5 min limit for each question**. If the discussion isn’t finished, ask the Questioner to create a Github Issue about it and continue discussion there. - **Limit discussions to maximum 5 min** , then it should be continued in In-Depth discussions. * * * ## 📢 Community Announcement ### PX4 Dev Summit 2022 is back in Austin Texas! 🎉 > [@police\_car\_light The #PX4DevSummit is back in-person!](https://discuss.px4.io/t/the-px4devsummit-is-back-in-person/26643): > > [[2400x500 Sched Header copy]](https://events.linuxfoundation.org/px4-developer-summit/)megaphone Community, we have been busy working behind the scenes to bring back our flagship event, and it’s my pleasure to announce our plans for the (In Person) [PX4 Developer Summit 2022](https://events.linuxfoundation.org/px4-developer-summit/). It seems like the first #PX4DevSummit in Zurich was only yesterday, but two whole years have passed, and it’s about time we get together to celebrate all of our achievements as a (really big) family! We are bringing the show to beautiful Austin, Texas, on June 23 & 24, hoste… > **[PX4 Developer Summit | LF Events](https://events.linuxfoundation.org/px4-developer-summit/)** > > The annual flagship conference hosted by the Dronecode Foundation for the drone development community. **Timeline:** - CFP Open: March 18th (Today!) - CFP Closes: April 19th - CFP Notifications: Week of May 2nd - Schedule Announcement: Week of May 9th - Presentation Slide Due Date: June 13th - Event Dates: Thursday, June 23rd - Friday, June 24th, 2022 Since we are back in person, we are pushing for increased content diversity, and we welcome any of the below: - Session Presentation: 30-min - Panel Discussions: 30-min - Birds of a Feather: 45/60-min - Lightning Talk: 5/15-min - Workshop: 1.5/2-hours [**Apply to the CFP directly on our Website**](https://events.linuxfoundation.org/px4-developer-summit/) ## 🧑‍🤝‍🧑 Community Q&A Raise your questions! ### Tests > > > @dagar - I imagine the whole test could be removed if it is tested on any CM4 > > > Added Sensor Set 3 > > !\[image\](https://user-images.githubusercontent.com/194582…1/157926965-76d925df-9848-4892-8287-3cda33b7023a.png) - Holybro sensor set - Holybro : F7 / H7 few available in stock, 100 pin version in stock ### QGC Taking over USB > > > \## Expected Behavior > If there is not a CommLink automatically configured to use… a serial device, nor a box selected under General settings to automatically connect via \`Pixhawk\`, then that serial device should never be opened by QGC. > > \## Current Behavior > \- Opened QGC with two serial interfaces connected on host device: > - /dev/ttyUSB0 (USB serial adapter being used to monitor PX4 debug output on console pins via \`picocom\`) > - /dev/ttyACM0 (USB connection to FMU intended for use by QGC > - QGC opened /dev/ttyUSB0 despite all auto connections being unchecked and no comm links specified for it (there was one specified for manual, non-auto connection to /dev/ttyACM0 > - Garbage starts spewing out of the console, almost as if the flight controller has been reconfigured for a different baud rate by QGC > - Upon trying to close and re-open picocom, I am informed \`Device or resource busy\` as /dev/ttyUSB0 is being held by QGC > - Close QGC > - Re-open picocom and the device is available and comms are back to normal > > \## Steps to Reproduce: > Steps are provided above, but the strangest thing is that the behavior appears to be random. Sometimes it happens, sometimes it doesn't. > > Out of 10 tries, 7 didn't cause the issue and 3 did. > > \## System Information > When posting bug reports, include the following information > \- Operating System: Ubuntu 20.04 > \- QGC Version: 4.2.0 > \- QGC build: Daily AppImage from a few weeks/months ago > \- Flight Controller: Matek H743 Wing v1 > \- Autopilot (with version): PX4 master - Same behavior, suspected bug. Platform on Ubuntu * * * ## 👷‍♀️ Project Updates Updates from the team ### Follow Target project > > > \*\*Describe problem solved by this pull request\*\* > Refer to the document : https:…//docs.google.com/document/d/1E04Rn6sxYNqKve4-KZYdC2-9LExKmHKuYjWZlwf61rA/edit > > \*\*Describe your solution\*\* > > \*\*Describe possible alternatives\*\* > A clear and concise description of alternative solutions or features you've considered. > > \*\*Test data / coverage\*\* > This change log : https://logs.px4.io/plot\_app?log=6561ce69-e2e3-46c3-9e13-e29f2dbc11c7 > Alessandro PR log : https://logs.px4.io/plot\_app?log=fa76985d-87c6-4c4f-9164-fa2f2c15338b > > \*\*Additional context\*\* > \* This PR is to be merged to a pre-existing PR : #18026 > \* Depends on library added from #19246 and #19249. > \* Proposal brainstorming issue : #19251 > \* User Doc Update PR : https://github.com/PX4/PX4-user\_guide/pull/1810 > \* Scripts I used for testing the algorithm : https://github.com/junwoo091400/Follow-Target-Algorithm-Scripts > \* Script used to test Follow-Me in SITL : https://github.com/junwoo091400/PX4-Followme-Sim-Script > \* Visualizer script that was used for drone's orbit angle set-point overshooting problem : https://github.com/junwoo091400/Follow-Target-uLog-Visualizer > > \### Discussions > 1. Should we just change the 'follow perspective' into a single number parameter (0 ~ 360 degrees), instead of using an enum / selection of : "Front, Back, Right, Left, etc."? > 2. Google Astyle for the member variables : Do we need to add the \_ suffix? > > \### TODOS > \- \[x\] Reduce follow\_target\_status logging rate to 200ms interval or 400ms > \- \[x\] MAVSDK Param update > - https://github.com/mavlink/MAVSDK-Proto/pull/287 > - https://github.com/mavlink/MAVSDK/pull/1770 > \- \[\] Later on implement the Multcopter Rate Controller not directly applying acceleration setpoint -\> Issue at #19543 > \- \[\] Maybe move onto \[YAML based\](https://docs.px4.io/master/en/advanced/parameters\_and\_configurations.html#parameter-metadata) Parameter definitions? > \- \[\] Add the Leash mode (as if drone was hovering and the user was connected to the drone, so it would follow around like as if it was leashed) > \- \[\] Add fixed orbit angle mode (staying always on the north side, etc. No orbit angle transitions) > \- \[\] \[Check if I get a more stable yaw setpoint if I use the heading from the position setpoint to the target estimate, instead of the real position.\](https://github.com/PX4/PX4-Autopilot/pull/19260#discussion\_r869034921) [![](https://img.youtube.com/vi/myPFVJJkm04/maxresdefault.jpg "Follow-Me v2 Demo") ](https://www.youtube.com/watch?v=myPFVJJkm04) - In the review process & addressing comments ### Sign function fix > > > \*\*Describe problem solved by this pull request\*\* > Fixes #19361 thanks to @tstast…ny ! > \- The sign function has no documentation > \- There are no unit tests for the sign function > \- The sign function has a bug where unexpectedly sign(0) = -1 and sign(FLT\_EPSILON) = 0 > > \*\*Describe your solution\*\* > Add documentation and unit tests. > For the bug, I'm really not sure why the putative deadzone was added here: https://github.com/PX4/PX4-Autopilot/pull/12905/files#diff-b76fc4ece0dac2e83a0e972fbea85372175487ed12f9146ee211252e51da3494R51 > It never worked before. It would need to be \`(T(FLT\_EPSILON) \< val) - (val \< -T(FLT\_EPSILON))\`. > > \*\*Describe possible alternatives\*\* > We could add another sign function that has a configurable deadzone with a default parameter value if there's the need. Also we should move it back to the PX4 math::Functions. > > \*\*Test data / coverage\*\* > New unit tests. > > \*\*Additional context\*\* > \- The sign function was added in https://github.com/PX4/PX4-Autopilot/pull/6638/files#diff-9c4d6427fcd835e10b4d068f53389a16801aac8628578944e0e88b8747e2798fR50 > \- used for quaternion conjugation corner cases in https://github.com/PX4/PX4-Autopilot/commit/e81483a808ce7b0217c11d3dc0fce90685f44353#diff-1de2137691523f51e9a4a2a3f5fdaed75974729fd912cda6f0612bab751d3993R82 > \- duplicate in PX4 math removed in https://github.com/PX4/PX4-Autopilot/pull/14374/files#diff-b76fc4ece0dac2e83a0e972fbea85372175487ed12f9146ee211252e51da3494L49 ### Orbit mode PRs > > > \*\*Describe problem solved by this pull request\*\* > When flying an orbit with the …yaw behavior \`ORBIT\_YAW\_BEHAVIOUR\_HOLD\_FRONT\_TANGENT\_TO\_CIRCLE\` where the vehicle is facing tangential to the circle and hence facing the direction of travel it's unintuitive to change the radius and velocity of the orbit with the usual stick mapping. This is because usually the stick input is mapped in the body yaw frame. > > \*\*Describe your solution\*\* > I changed the stick input to also act 90° offset compared to when flying with the vehicle facing the center of the circle. Such that's intuitively in body yaw frame. > > Doing that I found the direction of where the vehicle is facing and hence also how the stick input is mapped would change 180° when switching rotation direction. This makes direction switches by stick unusable. To work around the problem I made the vehicle go backward when the rotation direction is switched by stick input. > > \*\*Test data / coverage\*\* > This was tested in SITL and on a real vehicle that mostly uses \`ORBIT\_YAW\_BEHAVIOUR\_HOLD\_FRONT\_TANGENT\_TO\_CIRCLE\`. > > > \*\*Describe problem solved by this pull request\*\* > For certain use cases the limi…t is just too low and if the limit is exceeded currently there a bug where the radius is just pruned instead of not executing the out of range orbit command. > > Note: Not rejecting out of range radiuses is a regression: > https://github.com/PX4/PX4-Autopilot/commit/9bd46be1242535d5ec3da04c11d274aa22a2f805#diff-89127f427c1fc4e2fb02b97822ec75dc1bc7a4690ae4cd3aba8bc4f811250717L61 > > \*\*Describe your solution\*\* > \- \> the orbit radius is limited to 100m. If flying in open areas this limit is too strict. > > Makes it configurable by parameter. I'm open to suggestions for the default. > > \- \> When commanding a larger radius in AMC, it gets resized to 100m. > > Fixes the bug by not acknowledging the command and stopping instead of executing the Orbit. > This is already better than just changing the radius and then starting to execute but it should be further improved with e.g. an error message and possibly by switching mode. > > \*\*Test data / coverage\*\* > SITL testing with out-of-range radiuses and hitting the limit by stick input. ## ❗ High priority queue Discussion based on board: [https://github.com/orgs/PX4/projects/24](https://github.com/orgs/PX4/projects/24) ## 🌾 Release * * * ## 🤔 In-Depth discussions For smaller groups expanding technical discussions, stay until the end and follow up. ### CI Discussion > > > Initial work to have one container for CI and Development within tree > > In orde…r to build you have to be at the top of the firmware directory and run: > \`\`\` > ./Tools/docker\_run.sh make all\_variants\_px4\_fmu-v5x > \`\`\` > > Thanks to @julianoes for the great work on https://github.com/PX4/PX4-containers/pull/288 I based this PR on his work ### Stick scaling discussion > > > \*\*Describe problem solved by this pull request\*\* > 'Sticks' utility library is us…ed by Flight Tasks. While implementing a Follow-Target feature (#19260) with RC-controllable behavior, I found that \*\*it is unclear as to which 'user input' each input vector corresponds to.\*\* > > \*\*Describe your solution\*\* > Added functions each returning user input values in a clear, intuitive naming. > > + Also renamed the 'checkAndSetStickInputs' function name to 'checkAndUpdateStickInputs', since 'set' doesn't imply that the stick values are update, which is the most important aspect of this function, thus avoiding possible confusions ;) Matthias : getThrottle() function was ambiguous, wasn’t obvious that it’s 0 centered : [-1, 1] - Is the throttle [0, 1] range or [-1, 1]? - How do we differentiate the spring-loaded self-centering throttle controllers & non-spring loaded controllers? - ### Parameter Naming Convention > > > There was this discussion 3 years ago exactly about this issue. And it removed a…ll these 'readable' parameter variable names in the code, and reset them to match exactly the parameter name. Could you review this as well for the final decision? thinking @tstastny @potaito > > https://github.com/PX4/PX4-Autopilot/pull/11686 - 3 years ago a PR renamed the Parameter objects in the code to : \_param \_\< name\>. [New naming convention of variables linked to a parameter by bresch · Pull Request #11686 · PX4/PX4-Autopilot · GitHub](https://github.com/PX4/PX4-Autopilot/pull/11686/) - Maybe increase the parameter name length limit (currently 16). - ROS2 consideration as well ### Mode Switching / Commander architecture refactor - Thomas - Thinking about how to create a better API for flight modes - Have compiled a document for proposal > **[Google Docs: Sign-in](https://accounts.google.com/v3/signin/identifier?continue=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1-yY803-fFlyjIBfz-w3KRG3ntzwGlDG8kqy2HIK9OFs%2Fedit&dsh=S-717601453%3A1774377368998236&followup=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1-yY803-fFlyjIBfz-w3KRG3ntzwGlDG8kqy2HIK9OFs%2Fedit<mpl=docs&osid=1&passive=1209600&service=wise&flowName=GlifWebSignIn&flowEntry=ServiceLogin&ifkv=AT1y2_XrOKyBkNsznrcO9J2LPjoTRCJX7SwzuHvUTNprqrNAc1mSVwHa3kjnmENz0EdDY_UAufid7w)** > > Access Google Docs with a personal Google account or Google Workspace account (for business use). > Feel free to visit the document above and leave your comments / thoughts! - Enable compile time selection of including specific flight modes for each vehicle / board targets - Ultimate goal is to have an offboard computer send over the flight mode (even python scripts!) to the FMU, and dynamically register as a new flight mode. - Let’s build a nice API on FMU side - Will be uploaded to the Github Issue * * * ## 🙌 Feedback If you have any feedback or corrections please comment on this post! * * * ## 🔄 Component Updates Updates on each sectors of PX4 System ### 🛩 VTOL & Fixed Wing ### 🛸 Multicopter ### 💻 System Architecture ### 🌰 OS / NuttX ### 🚘 Driver ### 👑 Commander ### 🌵 Simulation ### 🥈 MAVROS / DDS / ROS2 ### 🃏 UAVCAN