# PX4 Dev Call: December 07, 2022 **URL:** \ **Category:** PX4 Autopilot\ **Created:** [November 30, 2022, 6:01pm UTC](https://discuss.px4.io/t/px4-dev-call-december-07-2022/29945 "2022-11-30T18:01:08Z")\ **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:** [November 30, 2022, 6:01pm UTC](https://discuss.px4.io/t/px4-dev-call-december-07-2022/29945/1 "2022-11-30T18:01:08Z")
# December 07, 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 * * * ### Ryan’s Podcast Episode up in PX4 Channel! [![](https://img.youtube.com/vi/BBBWO2yEAvI/maxresdefault.jpg "Ryan Johnston, Chief Executive Officer, Applied Aeronautics | Behind The Tech Episode #7") ](https://www.youtube.com/watch?v=BBBWO2yEAvI) ### uORB Explained Part 4 is out! > **[PX4 uORB Explained : Part 4, ULog flight logging system - PX4 Autopilot](https://px4.io/px4-uorb-explained-part-4-ulog-flight-logging-system/)** > > Welcome to the final episode of the uORB Explained Series: Part 4! In the past posts, we discussed the following: Part 1: Why we need uORB and its basic functionality Part 2: What uORB is really about, how uORB topics are instantiated, ORB Metadata... ## 🧑‍🤝‍🧑 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 : adding namespaces to microdds\_clients > > > \## Describe problem solved by this pull request > > 1. The \`microdds\_client\` did …not add the namespace to the participant name. As a result when working with multiple vehicles and ROS2 all microdds\_agent had the same name. > 2. in \`sitl\` the \`microdds\_client\` was automatically started on \`udp\` and port \`8888\`. With multiple vehicles this caused having all the clients connected to the same agent with the same key identifier, breaking the bridge regardless the presence of the namespace. > > \## Describe your solution > > 1. The \`participant\_xml\` is created taking into account the desired namespace. > 2. The parameter \`XRCE\_DDS\_KEY\` is added and used to specify the session key. > 3. In \`sitl\` the \`microdds\_client\` is automatically started on \`udp\`. ~~Depending on the \`px4\_instance\` variable the port and the namespace are selected: > \`microdds\_client start -t udp -p "$((px4\_instance+8888))" -n "px4\_${px4\_instance}"\`~~ > If \`px4\_instance\` is zero, no multiple clients are expected: \`XRCE\_DDS\_KEY\` is untouched and no namespace is defined. > If \`px4\_instance\` is greater than zero, multiple clients are expected: \`XRCE\_DDS\_KEY\` is set equal to \`px4\_instance\` and the namespace follow the convention \`px4\_${px4\_instance}\`. > 4. Regardless the value of \`px4\_instance\`, if the environment variable \`PX4\_MICRODDS\_NS\` is set, then it is used as namespace. > > \## Describe possible alternatives > Have the namespace in the form of a parameter (requires string parameters) > > \## Test data / coverage > > \### Single client scenario > This solution has been tested in ingnition simulation. For two vehicles: > \*\*terminal 1\*\* > \`make px4\_sitl gz\_x500\` > \*\*terminal 2\*\* > \`ros2 run micro\_ros\_agent micro\_ros\_agent udp4 --port 8888\` > > \#### Expected Output on terminal 3: > \`\`\` > $ ros2 node list > /px4\_micro\_xrce\_dds > $ ros2 topic list > /fmu/in/obstacle\_distance > /fmu/in/offboard\_control\_mode > /fmu/in/onboard\_computer\_status > /fmu/in/sensor\_optical\_flow > /fmu/in/telemetry\_status > /fmu/in/trajectory\_setpoint > /fmu/in/vehicle\_attitude\_setpoint > /fmu/in/vehicle\_command > /fmu/in/vehicle\_mocap\_odometry > /fmu/in/vehicle\_rates\_setpoint > /fmu/in/vehicle\_trajectory\_bezier > /fmu/in/vehicle\_trajectory\_waypoint > /fmu/in/vehicle\_visual\_odometry > /fmu/out/failsafe\_flags > /fmu/out/sensor\_combined > /fmu/out/timesync\_status > /fmu/out/vehicle\_attitude > /fmu/out/vehicle\_control\_mode > /fmu/out/vehicle\_global\_position > /fmu/out/vehicle\_gps\_position > /fmu/out/vehicle\_local\_position > /fmu/out/vehicle\_odometry > /fmu/out/vehicle\_status > /parameter\_events > /rosout > \`\`\` > > \### Multi-client scenario > This solution has been tested in ingnition simulation: > \*\*terminal 1\*\* > \`\`\` > make px4\_sitl > PX4\_SYS\_AUTOSTART=4001 PX4\_GZ\_MODEL\_POSE="0,0" PX4\_GZ\_MODEL=x500 ./build/px4\_sitl\_default/bin/px4 -i 1 > \`\`\` > \*\*terminal 2\*\* > \`PX4\_SYS\_AUTOSTART=4001 PX4\_GZ\_MODEL\_POSE="0,1" PX4\_GZ\_MODEL=x500 ./build/px4\_sitl\_default/bin/px4 -i 2\` > \*\*terminal 3\*\* > \`ros2 run micro\_ros\_agent micro\_ros\_agent udp4 --port 8888\` > > \#### Expected Output on terminal 4: > \`\`\` > $ ros2 node list > /px4\_1/px4\_micro\_xrce\_dds > /px4\_2/px4\_micro\_xrce\_dds > $ ros2 topic list > /parameter\_events > /px4\_1/fmu/in/obstacle\_distance > /px4\_1/fmu/in/offboard\_control\_mode > /px4\_1/fmu/in/onboard\_computer\_status > /px4\_1/fmu/in/sensor\_optical\_flow > /px4\_1/fmu/in/telemetry\_status > /px4\_1/fmu/in/trajectory\_setpoint > /px4\_1/fmu/in/vehicle\_attitude\_setpoint > /px4\_1/fmu/in/vehicle\_command > /px4\_1/fmu/in/vehicle\_mocap\_odometry > /px4\_1/fmu/in/vehicle\_rates\_setpoint > /px4\_1/fmu/in/vehicle\_trajectory\_bezier > /px4\_1/fmu/in/vehicle\_trajectory\_waypoint > /px4\_1/fmu/in/vehicle\_visual\_odometry > /px4\_1/fmu/out/failsafe\_flags > /px4\_1/fmu/out/sensor\_combined > /px4\_1/fmu/out/timesync\_status > /px4\_1/fmu/out/vehicle\_attitude > /px4\_1/fmu/out/vehicle\_control\_mode > /px4\_1/fmu/out/vehicle\_global\_position > /px4\_1/fmu/out/vehicle\_gps\_position > /px4\_1/fmu/out/vehicle\_local\_position > /px4\_1/fmu/out/vehicle\_odometry > /px4\_1/fmu/out/vehicle\_status > /px4\_2/fmu/in/obstacle\_distance > /px4\_2/fmu/in/offboard\_control\_mode > /px4\_2/fmu/in/onboard\_computer\_status > /px4\_2/fmu/in/sensor\_optical\_flow > /px4\_2/fmu/in/telemetry\_status > /px4\_2/fmu/in/trajectory\_setpoint > /px4\_2/fmu/in/vehicle\_attitude\_setpoint > /px4\_2/fmu/in/vehicle\_command > /px4\_2/fmu/in/vehicle\_mocap\_odometry > /px4\_2/fmu/in/vehicle\_rates\_setpoint > /px4\_2/fmu/in/vehicle\_trajectory\_bezier > /px4\_2/fmu/in/vehicle\_trajectory\_waypoint > /px4\_2/fmu/in/vehicle\_visual\_odometry > /px4\_2/fmu/out/failsafe\_flags > /px4\_2/fmu/out/sensor\_combined > /px4\_2/fmu/out/timesync\_status > /px4\_2/fmu/out/vehicle\_attitude > /px4\_2/fmu/out/vehicle\_control\_mode > /px4\_2/fmu/out/vehicle\_global\_position > /px4\_2/fmu/out/vehicle\_gps\_position > /px4\_2/fmu/out/vehicle\_local\_position > /px4\_2/fmu/out/vehicle\_odometry > /px4\_2/fmu/out/vehicle\_status > /rosout > \`\`\` > > \## Additional context > I used ignition fortress source compiled for this test. And even if #20319 is fully functional, as the associated PR in gz has been merged, I had to manually modify the gazebo version to overcome #20342. ### Q.2: Flash overflowing, how do we fix this? - Jay For example in this PR: [Add fixed wing rate control module by Jaeyoung-Lim · Pull Request #20237 · PX4/PX4-Autopilot · GitHub](https://github.com/PX4/PX4-Autopilot/pull/20237) ### Q.3: Pixhawk 6C not receiving RC data > [@Pixhawk 6C flight tests](https://discuss.px4.io/t/pixhawk-6c-flight-tests/28977/7): > > I am testing latest master based on what had a chat about last meeting. The very first issue is I have no RC (13.2 is ok). My Pixhawk 5X is ok with RC. I am using Radiolink RS12 with SBUS by the way. cc: @dagar Some outputs are below: nsh\> dmesg HW arch: PX4\_FMU\_V6C HW type: V6C000000 HW version: 0x000 HW revision: 0x000 PX4 git-hash: 45b390b0bfe21fc591b36ec898f6fc0791fc4729 PX4 version: 1.13.0 80 (17629312) OS: NuttX OS version: Release 10.2.0 (167903487) OS git-hash: 6bafcb22b7d62184fd1158c… ### Q.4: HITL Fixed wing takeoff not working > > > I used the pr-hitl-support branch code, I show the detail: > the command as follo…ws: > !\[98638c5f8a6a0e4f517ab517b100e17\](https://user-images.githubusercontent.com/55626173/198946374-00508f2c-3d32-49a8-90a8-e4eb96a2f757.png) > then the px4 connect the qgc via udp, I inserted those code to read the accel and gyro in the file of sensor\_imu\_plugin.cpp in realtime. Like this: > !\[image\](https://user-images.githubusercontent.com/55626173/198946531-8819103e-8a61-473e-a469-efada2ada027.png) > I load a fly plan into px4 and run the mission mode, but it can't runaway takeoff. And the accel and gyro data flow Like this: > !\[0bcc2212f50244746a3d5cc8d3dfd13\](https://user-images.githubusercontent.com/55626173/198946999-77b4a16a-e67f-48c6-9f01-f32c467239c0.png) > I don't konw where the problem is. - Probably because the actuator output mapping isn’t correct between the PX4 and Simulation - Probably not supported now. There is a hanging PR to support HITL with jMAVSim, but it isn’t done yet. > > > \*\*Describe problem solved by this pull request\*\* > Currently the \`px4-jsbsim-brid…ge\` can only be used to run Software-In-The-Loop(SITL) simulations. While this is useful for evaluating the software changes in firmware, it may not reveal issues that may appear only deployed on hardware. PX4 also supports \[Hardware-In-The-Loop(HITL) simulation\](https://dev.px4.io/master/en/simulation/hitl.html#hardware-in-the-loop-simulation-hitl). However, this was not exposed to the jsbsim-bridge > > \*\*Describe your solution\*\* > This commit adds configuration options for running HITL simulation with the PX4 JSBSim bridge. > > The device path / baudrate can be passed with the command line when running the binary directly with flag \`-d\` and \`-b\`. > e.g. > \`\`\` > HEADLESS=1 ./jsbsim\_bridge rascal -d /dev/ttyACM0 -s ~/src/Firmware/Tools/jsbsim\_bridge/scene/LSZH.xml > \`\`\` > or to set the baudrate > \`\`\` > HEADLESS=1 ./jsbsim\_bridge rascal -d /dev/ttyACM0 -b 921600 -s ~/src/Firmware/Tools/jsbsim\_bridge/scene/LSZH.xml > \`\`\` > The bridge is configured to be run with a HITL when the device path \`-d\` is provided. The baudrate is configured to be \`921600\` by default, but can be also configured through a \`-b\` flag. > > \*\*Test data / coverage\*\* > \[WIP\]() > > \*\*Additional context\*\* > \- Fixes https://github.com/Auterion/px4-jsbsim-bridge/issues/27 ## 👷‍♀️ Project Updates * * * ### P.1 : Arbitrary Mag orientation feature - Junwoo > > > \## Describe problem solved by this pull request > Previously, the rotations for t…he magnetometer was confined to MAVLink defined \[MAV\_SENSOR\_ORIENTATION\](https://mavlink.io/en/messages/common.html#MAV\_SENSOR\_ORIENTATION), which doesn't allow setting non 45-degree multiple sensor orientation. > > This was a limiting factor for drones with magnetometer that has Magnetometer installed in Euler angles of something like 37 degrees, 58 degrees, etc. > > \## Describe your solution > Enables setting arbitrary euler angle for magnetometer orientation, which would allow users to set angles like 37 degrees in yaw, which is useful for Alta X for example > > \### Added parameters > Parameters that defines the Euler angle for the orientation the Magnetometer is at were added: > > \- CAL\_MAG${i}\_ROLL > \- CAL\_MAG${i}\_PITCH > \- CAL\_MAG${i}\_YAW > > \## Describe possible alternatives > Quaternion? > > \## Test data / coverage > TODO > > \## TODO > \- \[\] Add QGC UI to dynamically visualize this Euler angle setting for custom rotation > > \## Discussion > Currently, due to bringing in the MAV\_SENSOR\_ROTATION\_CUSTOM enum, which breakes the sequence of numbers, and bumps up the value to 100, the \`ROTATION\_MAX\` can no longer be used to calculate the number of rotations we support in PX4. > > You can read more about enum members number count issue \[here\](https://stackoverflow.com/questions/14989274/is-it-possible-to-determine-the-number-of-elements-of-a-c-enum-class). > > Would there be a good solution for this? Before [sensors: prefix mag config param SENS instead of CAL by bresch · Pull Request #20723 · PX4/PX4-Autopilot · GitHub](https://github.com/PX4/PX4-Autopilot/pull/20723) goes in, shouldn’t we get this in first? @bresch ### P.2: State estimation wrong with VICON based real flight - Salvatore > [@Differences between simulation and real drone](https://discuss.px4.io/t/differences-between-simulation-and-real-drone/29923): > > Hi guys, I have customized the firmware to add the control of tilting multirotors, like voliro [https://youtu.be/Sgd0i87r9-0](https://youtu.be/Sgd0i87r9-0) and this one [https://youtu.be/tZ\_93HusKnI](https://youtu.be/tZ_93HusKnI). I have created the simulator in Gazebo for both types and it works in different flight modes (tested in stabilized, altitude, position, mission and offboard). This is an example of a simulation of a flight in position flight mode ([Flight Review](https://review.px4.io/plot_app?log=c323d9f3-d3ce-48ff-8160-bfc686f10f26)). Today we tested the firmware on the real drones (the same kinematic as the simulat… - State estimation issue: Should check the VICON data coming in (Frame of Reference, especially) \> Probably not the case, since the stable release works well with VICON (Position mode). - Also, in Firmware side, MAVLink Enums have been changed, so the frames may have been changed (this custom firmware) - Possibly related: [ekf2 EV overhaul (incremental), move EV velocity to new state machine and introduce EKF2\_EV\_CTRL by dagar · Pull Request #20497 · PX4/PX4-Autopilot · GitHub](https://github.com/PX4/PX4-Autopilot/pull/20497) ## 🤔 General Discussions * * * ### D.1 : HITL Support in PX4 ### D.2: Learnings from Discord call - With more than 25 ppl, we can’t get the video selfie stream working - Calender needs to be updated to use the Discord server - 🪒 Sharp image resolution (can u read this 😏) ## 📅 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 ### ☎ Last Dev-Call > [PX4 Dev Call: November 30, 2022](https://discuss.px4.io/t/px4-dev-call-november-30-2022/29868) - Seems like it is empty. Did no-one log the meeting last week? ☹ ## ❗ High priority queue * * * Discussion based on: [https://github.com/orgs/PX4/projects/24](https://github.com/orgs/PX4/projects/24) ## 🌾 Release * * *