# PX4 Dev Call: June 01, 2022 **URL:** \ **Category:** PX4 Autopilot\ **Created:** [May 25, 2022, 5:01pm UTC](https://discuss.px4.io/t/px4-dev-call-june-01-2022/27635 "2022-05-25T17:01:40Z")\ **Posts on this page:** 4\ **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:** [May 25, 2022, 5:01pm UTC](https://discuss.px4.io/t/px4-dev-call-june-01-2022/27635/1 "2022-05-25T17:01:40Z")
# June 01, 2022 ## Join us > **[Jitsi Meet](https://meet.jit.si/PX4DeveloperCallWeekly)** > > Join a WebRTC video conference powered by the Jitsi Videobridge ## Agenda - Community Announcement - Community Q&A - Project Updates - General Discussions - Weekly Overview - High priority queue - Release ## 📢 Community Announcement * * * ### Dev Summit 2022! 🇺🇸 - You can purchase a virtual ticket! - 2 Full Days of Workshops & Keynotes - On the first day, there will be a 300 **drone light show** ⚡ - On the second day, there will be some yummy **cakes** 🍰 ## 🧑‍🤝‍🧑 Community Q&A (No deep technical discussions) * * * ### ❗ Guideline for asking a Question 1. Specify what you are trying to **achieve** 2. Specify what environment / **platform** you are using 3. Prepare a **Link** or **Document** to help understand if possible 4. First, ask the question on the **Slack** or [create a **Github Issue**](https://github.com/PX4/PX4-Autopilot/issues/new/choose)! 5. If you take over 5 minutes for the question, please continue in Slack or a Github Issue. ### Q.1 : Raspberry Pi Pico Issue - Vatsal > > > Hi, I build firmware for rp2040 with make raspberrypi\_pico\_default - it's OK. I… convert .elf file to .uf2 with elf2uf2 tool. > Then, I take pi pico board, connect to this board module G-91 with MPU9250 and BMP280, and upload firmware. > After that, the LED on the board lit up. But the board has ceased to be defined as a usb device. And not connect to QGC. > What could be the problem? What am I doing wrong? - The fix was merged to NuttX yesterday. When will it come into effect in PX4? [https://github.com/apache/incubator-nuttx/pull/6347](https://github.com/apache/incubator-nuttx/pull/6347) - Answer: Cherry-pick the changes from NuttX and open the PR to PX4 ### Q.2 : UAVCAN Servo Support status - Dave - in the [Doc](https://docs.px4.io/master/en/uavcan/), it states: > PX4 does not support UAVCAN servos (at time of writing). - It was implemented in PX4 in this commit (Ramon): [uavcan: implement servo outputs · PX4/PX4-Autopilot@3ff6014 · GitHub](https://github.com/PX4/PX4-Autopilot/commit/3ff6014a3c8189ce1ae41da232456cbd0abd323a) - Another PR related: [Introduce actuator output function parameters by bkueng · Pull Request #18265 · PX4/PX4-Autopilot · GitHub](https://github.com/PX4/PX4-Autopilot/pull/18265) - Answer : You can join Slack via this link: [http://slack.px4.io/](http://slack.px4.io/) ### Q.3 : OpenMV - Patrick - PX4 Flow - Answer: Optial sensor is better than the Sonar one ## 👷‍♀️ Project Updates * * * ### P.1 : Precision Landing PR merge discussion - @potaito > > > @ndepal FYI > > \*\*Describe problem solved by this pull request\*\* > Partially solve…s https://github.com/PX4/PX4-Autopilot/issues/14320 > > Precision landing is congesting navigator when it's actually better suited to be a flight task. The navigator based precision landing implementation is quite tedious as it's constantly converting between local and global coordinates. This is a limitation of Navigator. By moving it to the flight task library, precision landing can directly interface with the local position and velocity setpoints. It's also easier to create new search patterns in the future for those who need it. Last but not least the implementation as a FlightTask should make it possible to use precision landing without a global position (GPS), which is a requirement in the previous implementation. I have not tested precision landing without GPS, but in theory it's possible to use it with only a local frame. > > \*\*Describe your solution\*\* > Precision landing was moved from navigator to the flight task library. It's running in parallel to navigator's RTL mode. Initially the precland flight task will listen to Navigator setpoints while Navigator thinks it's returning home. Once the drone either detects the landing target, or is above home and starts descending, the flight task will take over and land on the target instead on home. It it does not see the target, it will pause during Navigator's landing sequence, wait and see if it can still detect the target within a timeout. > > The advantage of "hijacking" the navigator's RTL is, that all Navigator features and parameters are functional (return altitude, geofences etc.) until the drone enters the landing phase. > > I tried to maintain the previous functionality of precland in Navigator as good as possible. One feature is now a bit different though: If the target is lost while it's being approached, the drone will now continue with the original Navigator RTL until it sees the target again. Originally the drone would freeze mid-air and just wait for the target to re-appear. Despite this fact, the refactored implementation does not violate the flow described in the PX4 docs: \[http://docs.px4.io/master/en/advanced\_features/precland.html#precision-landing\](http://docs.px4.io/master/en/advanced\_features/precland.html#precision-landing > ) > > !\[Precland Refactor\](https://user-images.githubusercontent.com/3762382/164458774-89af9668-6c10-47ee-98a1-eb7c2ff99f1e.svg) > > > > In summary, the drone will either land on the target, or it will land on home. Those are the only options. > > \*\*Test data / coverage\*\* > Testing is a bit tricky, as MAVSDK currently does not have the IR\_beacon message implemented and it's therefore not possible to create SITL tests. What I did is send the land\_target message from within PX4 and run manual tests. > > \----- > > The following log shows how RTL is executed and the drone lands on a target at (x,y) = (3,1.5) > > !\[image\](https://user-images.githubusercontent.com/3762382/148576044-5b96082d-8844-4e91-bb03-a78f767d7b82.png) > > source: https://logs.px4.io/plot\_app?log=30855969-ae58-48a9-b06e-b33599a202eb > > \----- > > Here we see the configuration where precision landing is required, but the target not visible. The drone will wait and "search" for the target where the time marker is located in the graphs. After the configurable timeout of 10 seconds is reached, the drone proceeds with the usual landing as instructed by Navigator: > > !\[image\](https://user-images.githubusercontent.com/3762382/148576452-210e39d8-1a56-493f-906d-7956799d1b35.png) > > source: https://logs.px4.io/plot\_app?log=f8da0f50-69e3-40f2-a687-d0520e74a6db > > > \*\*TODO\*\* > > \- \[\] Fix flimsy land detection in simulation > \- \[\] Prevent flight task from being activated over and over again between land detected and disarm. This happens with all flight tasks currently. > \- \[x\] Implement switching to precland as part of the mission, where \`nav\_state == AUTO\_MISSION\` > \- \[x\] Fix opportunistic landing in RTL: Currently precland witll switch to fallback right away when the beacon is not visible, instead of flying back to HOME first before abandoning search. [Discussion topics](https://github.com/PX4/PX4-Autopilot/pull/18973#issuecomment-1092779052) from the PR: - **What is / should be the role of navigator in general?** I think we all agree that currently it is doing too much. Should it be a state machine? Or should it only be an array of mission items? - How can flight modes such as precland, orbit or follow-me become part of a mission? - If we allow custom flight modes as flight tasks to be used in missions, the flight tasks will have to contain the criteria that determine when the task is complete. For example, if the vehicle is supposed to fly orbit for three resolutions, then the orbit flight task should track this and report when it’s done. - **What are AUTO modes?** Is AUTO = mission? Or is AUTO a superset that contains mission along other modes? ![Precland Refactor](https://user-images.githubusercontent.com/3762382/164458774-89af9668-6c10-47ee-98a1-eb7c2ff99f1e.svg) - Moved the ‘Precision Landing’ from Navigator to Flight Task - Want to discuss: “Mission triggering certain flight modes” - Currently, **executing the ‘orbit’ mode in the middle of the mission for 60 seconds, and then resuming the mission is a missing** feature in PX4. - Implemented ‘Main mode’ and ‘Sub mode’, to implement this. - Feedback: It would be great for the Navigator just to handle the flight modes / handle mission state machine (Thomas) ### P.2 : Rewrite of the Failsafe state machine > > > I was working on preflight check reporting with the events interface and wanted …to check how it could fit into the whole structure. So I came up with this: > !\[commander drawio\](https://user-images.githubusercontent.com/281593/169977325-5cf1068e-08ad-42a9-9dc9-45599e615754.png) > > > The basic idea is that the arming/health checks do the GCS reporting, prevent all or individual modes from arming, and can set flags that are then used in the failsafe state machine (the checks run and report during arming as well). > This PR is about implementing the failsafe state machine part. > > \### Failsafe state machine > \- As one of the basic requirements, there needs to be a way to generate user documentation from the code. > I ended up using Emscripten, which allows to compile the C++ code directly to webassembly and run it in the browser. So any possible failsafe combination can be checked directly, and the logic corresponds 1:1 to what runs on the vehicle. > This allows to implement arbitrary logic in the C++ code. > At the same time it is very convenient for development (testing and debugging) as well. > The condition flags are extracted from the msg file directly, and there's a minimal parameter storage. The accessed parameters are added to the UI (using the parameter json metadata). > The implementation of this PR can be tested under https://logs.px4.io/plot\_app/static/failsafe\_test/index.html. > Use \`make run\_failsafe\_web\_server\` to build & run it locally. > \- The implementation is split into a generic framework (base class) and class that implements the actual checks (this could be vehicle-specific). > - The framework maintains a set of active actions and an action becomes active when a condition is triggered. Action can have additional settings (e.g. if user takeover is allowed). The selected failsafe is then the most severe active action. > So it's well-defined what happens when multiple failsafes trigger. > Then there's fallbacks to the next option, should the desired failsafe not be available. > - clear condition: by default, when the failure condition clears, the vehicle goes back into the user intended mode. An action can change this to e.g. clear only on disarming or on mode switch. > - user takeover: the default behavior is when an action is triggered, the vehicle first goes into Hold for N seconds (configurable, and disabled for N=0), with a user notification. During that time the user cannot take over. After that the action is triggered and the user can take over by switching into any mode or moving the sticks. > - \`can\_run\`: this is a bitset for each mode if it can be executed (basically what \`main\_state\_transition\` currently does). This is used by the failsafe state machine for mode fallback. We probably need more granularity here later on (e.g. which modes require position). > - The behavior generally matches closely what we have now, apart from generically handling multiple failsafes. It can generally be changed as we need it. > \- state machine inputs: minimal state (armed, vehicle type, user intended mode, user takeover request, etc), \`vehicle\_status\_flags\` (conditions) and param configuration > \- output: failsafe action (if any), updated user intended mode > \- Not everything is done yet, for testing I implemented the core of the existing failsafe state machine, \`set\_nav\_state\`, user takeover and a few other things. > \- I'm also suggesting to change the lockdown action to disarm. > > Feedback is welcome, also unexpected or unintended behavior (there's generally various details that can be done one way or another). > Thanks to @KonradRudin & @MaEtUgR for testing & support. > > Screenshot of the web sim: > !\[image\](https://user-images.githubusercontent.com/281593/169977907-cd060eff-674f-44d3-94b9-ab3883218c6e.png) ![image](https://discuss.px4.io/uploads/default/original/2X/c/c9452f2df5a208df3c7c501889dab2c17870cdb1.png) - Now you can ‘simulate’ the Failsafe state machine on the web browser here: [https://logs.px4.io/plot\_app/static/failsafe\_test/index.html](https://logs.px4.io/plot_app/static/failsafe_test/index.html) ## 🤔 General Discussions * * * ### D.1 : ## 📅 Weekly Overview * * * ### 🐁 Github > [Recently updated Issues / PRs in PX4-Autopilot Link](https://github.com/PX4/PX4-Autopilot/issues?q=sort%3Aupdated-desc) **Pull Requests** \* **Issues** \* ### 💻 Slack #### Daniel’s Null Island 🏝 ![image](https://discuss.px4.io/uploads/default/original/2X/b/bcf0e7bee4fdbb86a91e0c5db7eac87d623d3ecc.jpeg) ### ☎ Last Dev-Call > [PX4 Dev Call: April 27, 2022](https://discuss.px4.io/t/px4-dev-call-april-27-2022/27066) - ## ❗ High priority queue * * * Discussion based on: [https://github.com/orgs/PX4/projects/24](https://github.com/orgs/PX4/projects/24) ## 🌾 Release * * * ---
**Author:** ![Devansh\_Agr](https://discuss.px4.io/user_avatar/discuss.px4.io/devansh_agr/32/10843_2.png) [@Devansh\_Agr](https://discuss.px4.io/u/Devansh_Agr)\ **Post date:** [May 30, 2022, 12:24pm UTC](https://discuss.px4.io/t/px4-dev-call-june-01-2022/27635/2 "2022-05-30T12:24:07Z")
Hi Ramon, I am interested to join - what time is this developer call? Thanks, Dev ---
**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:** [May 30, 2022, 2:54pm UTC](https://discuss.px4.io/t/px4-dev-call-june-01-2022/27635/3 "2022-05-30T14:54:55Z")
The call is at 5pm CET every Wednesday, you can see/download the calendar invite from this link [Dronecode Calendar — Dronecode Foundation](https://www.dronecode.org/calendar/) ---
**Author:** ![DMarsell65](https://discuss.px4.io/letter_avatar_proxy/v4/letter/d/278dde/32.png) [@DMarsell65](https://discuss.px4.io/u/DMarsell65)\ **Post date:** [June 1, 2022, 3:31am UTC](https://discuss.px4.io/t/px4-dev-call-june-01-2022/27635/4 "2022-06-01T03:31:35Z")
Ramon, I would like to bring up the still unanswered topic of the status of PX4 support for UAVCAN servo actuators. Online documentation states they are not supported ([UAVCAN | PX4 User Guide](https://docs.px4.io/master/en/uavcan/)). Would like to confirm that is still the case and any plans to add servo support on UAVCAN vs PWM output. Thanks, Dave