# PX4 Dev Call: March 16, 2022 **URL:** \ **Category:** PX4 Autopilot\ **Created:** [March 9, 2022, 6:00pm UTC](https://discuss.px4.io/t/px4-dev-call-march-16-2022/26523 "2022-03-09T18:00:51Z")\ **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 9, 2022, 6:00pm UTC](https://discuss.px4.io/t/px4-dev-call-march-16-2022/26523/1 "2022-03-09T18:00:51Z")
# March 16, 2022 ## Join us > **[Jitsi Meet](https://meet.jit.si/PX4DeveloperCallWeekly)** > > Join a WebRTC video conference powered by the Jitsi Videobridge ## Agenda - Dev Call format change suggestion discussion - Community Q&A - Project Updates - High priority queue - Release - In-Depth discussions - (Maybe) Component Update * * * ## 📢 Community Announcement ### New Blog post on PX4 Parameters is coming - Related Discuss post : [🙌 Introducing Junwoo Hwang](https://discuss.px4.io/t/introducing-junwoo-hwang/26579) - NuttX, PX4 Startup scripts, uORB messenger, etc. Confusing idea / concepts will be covered! * * * ## 🧑‍🤝‍🧑 Community Q&A Raise your questions! ### Moderation Rule Suggestion By @junwoo0914 - 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. Maybe have some small number of categories to do component update on? To prevent too much opinion. Or ask for a ‘general’ update for each individual? : Matthias It’s nice to have a call with a common topic / interest among participants, to spark new discussions, etc : Matthias How about **Project update meeting (non QnA) monthly?** : Alessandro There’s mix of developers. Casual / more involved, etc. : Daniel. e.g. VTOL doesn’t have a lot of updates, so maybe start a special VTOL call? Ramon will do a Survey on this. ### QGC taking over USB devices > > > \## 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 - Turning on SiK radio could solve the problem : david - Pico COM is running before starting QGC - Could turn on QGC Logging to debug : daniel ### Docker container SITL crashing on custom Simulation stack - Interactive shell & docker container is creating a crash : Conor - Gazebo is getting started separately ### Magnetometer-less flight - Using in offboard mode, aiming to do flight without magnetometer : Tony - Initial MAG\_TYPE\_AUTO setting, overriding with MAG\_TYPE\_NONE later creates a heading offset, causing toilet bowling. - Forcing a Yaw estimator reset could be a fix. When vehicles are all facing North, reset the EKF2’s yaw. - Application currently on swarm drones for a light show, so solution to be generic (e.g. parameter) - May create new MAG type specifically for this yaw reset use case ### UAVCAN v1 Messaging standard issue - Vendor adoption. Want to develop their own sensor : Henry - Sending actuator commands via UAVCAN has not been tried yet - Trying to figure out where Vendors are headed towards. To select the message standard for application. - Many standardized message effort has failed : Thomas - To support standardized messages, go for Drone CAN - Message standardization / bridging systems can be unnecessary : - Could use uORB bridge over UAVCAN v1, and if not possible, fall back to DroneCAN (in the future) : Alex ### Collision prevention for multiple vehicle doing separate missions - Currently in QGC, mission planning doesn’t conider different vehicle’s mission paths having potential collision : Fellow Jitster - If connected in a common network, could do a similar feature as an ADSB (for a future feature) - Before doing the mission, currently swarm flight using non-collision paths created : ### PX4 not supporting switch and button simultaneously - Use case : using RTL switch as a button while having another flight mode selection switch : Junwoo - Had different schemes before : daniel - Different controllers (MAVLink message / different RC channels, etc) exist, so would be nice to have the centralized system to handle this. - Issue created now. > > > \*\*Describe problem solved by the proposed feature\*\* > Currently, PX4 doesn't supp…ort the following setup : > \- Having one channel in RC configured for flight mode selection (e.g. Low : Position / High : Follow Me mode) > \- Having an RTL button for activating Return To Launch by just \*\*pressing on the button once\*\*. > > As the PX4 only considers 'Switches' (where you need to keep the RC signal state fixed, opposed to buttons which only changes signal momentarily), it's impossible to have the Button setup. Meaning, I need to be keep on pressing the RTL button for the RTL to stay activated throughout the RTL maneuver. > > \*\*Describe your preferred solution\*\* > A clear and concise description of what you want to happen. > > \*\*Describe possible alternatives\*\* > A clear and concise description of alternative solutions or features you've considered. > > \*\*Additional context\*\* > Testing on the Mantis drone RC controller. Which has RTL button on lower-left and Flight mode button on lower-right. > > !\[image\](https://user-images.githubusercontent.com/23277211/158647431-e0afe648-29e4-499a-9cfa-c0b78f2eb5a8.png) > > FYI @dagar @MaEtUgR ### CAN node application - CAN node : Andrew \*didn’t catch this part so well * * * ## 👷‍♀️ Project Updates Updates from the team ## ❗ High priority queue Discussion based on board: [https://github.com/orgs/PX4/projects/24](https://github.com/orgs/PX4/projects/24) ## 🌾 Release - RC selection bug needs to be fixed before release : daniel - * * * ## 🤔 In-Depth discussions For smaller groups expanding technical discussions, stay until the end and follow up. * * * ## 🙌 Feedback If you have any feedback or corrections please comment on this post! * * * ## 🔄 (Maybe) Component Updates Updates on each sectors of PX4 System ### 🛩 VTOL & Fixed Wing ### 🛸 Multicopter ### 💻 System Architecture - RTL could get triggered even when already landed. Fix PR added : Matthias > > > \*\*Describe problem solved by this pull request\*\* > The remaining battery time bas…ed RTL is triggered also when already landed (in another mode then RTL or Land). > > \*\*Describe your solution\*\* > Instead of just checking for being armed I also check if the vehicle is already in any landed stage > \`!\_vehicle\_land\_detected.ground\_contact // not in any landing stage\` > > On the way I: > \- refactored the naming of the land detection subscription in commander > \- updated a comment about land detection triggering time > \- removed an unused publication of landed state in the MAVLink module > > \*\*Test data / coverage\*\* > I tested this in SITL by making the battery simulator publish a current and configuring a battery capacity. > I think we should enable optional testing of battery current and capacity in SITL in general in another pr. ### 🌰 OS / NuttX - Log issue (NuttX Version), needs fix : Daniel - New release coming soon, changes ahead : David ### 🚘 Driver ### 👑 Commander ### 🌵 Simulation ### 🦜 MAVSDK ### 🔖 Hardware Workgroups ### 🔍 Estimation ### 🤹‍♂️ Avoidance ### 🥈 MAVROS / DDS / ROS2 ### 🃏 UAVCAN