# PX4 Dev Call: September 30, 2020 **URL:** \ **Category:** PX4 Autopilot\ **Created:** [September 23, 2020, 5:00pm UTC](https://discuss.px4.io/t/px4-dev-call-september-30-2020/18725 "2020-09-23T17:00:33Z")\ **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:** [September 23, 2020, 5:00pm UTC](https://discuss.px4.io/t/px4-dev-call-september-30-2020/18725/1 "2020-09-23T17:00:33Z")
# September 30, 2020 ## Agenda - Status update by component/project - Roadmap, and Release discussion - Community Q&A - In-Depth discussions ## Join Meeting **Meeting ID** : 946 175 205 **Join using your mobile/desktop** > **[Join our Cloud HD Video Meeting](https://zoom.us/j/946175205)** > > Zoom is the leader in modern enterprise cloud communications. **Call in using your phone, find your local number** : [https://zoom.us/u/aetSYKbiMF](https://zoom.us/u/aetSYKbiMF) * * * ## Component update ### Hardware @JingerZ: Board support guide is up! Outlines different support levels of autopilot boards depending on them being completely compliant to the standard, supported by the manufacturing company or contributors. > **[Manufacturer’s PX4 Board Support Guide - PX4 Autopilot](https://px4.io/ecosystem/compatible-hardware/board-support-guide/)** > > \[et\_pb\_section fb\_built=”1″ \_builder\_version=”4.9.7″ background\_color=”#000000″ background\_image=”https://px4.io/wp-content/uploads/2020/03/hero.svg” background\_enable\_image=”off” height=”350px” global\_module=”6813″ saved\_tabs=”all”... The resulting autopilot support list is here: [Autopilots - PX4 Autopilot](https://px4.io/autopilots/) Definition of quality acceptance criteria still has to be clarified by providing a reference to tests. ### System Architecture Before this there were different numbers of sensor supported for different types. Now it’s unified 4 maximum each. And a separate rotation per external sensor can be set by the user. > > > There isn't a huge need for this, but occasionally someone tries to use an exter…nal IMU and hits the limit. Four seems like a good magic number because it's the current ORB multi limit and what we already have for mag. > > The 2nd change here is to start handling external accels and gyros like magnetometers where each instance has a configurable rotation parameter (CAL\_ACCx\_ROT/CAL\_GYROx\_ROT) that's only applicable to externals. > > In contrast to external magnetometers, the default priority for an external accel or gyro is lower than an internal. A common example is the external icm20948 (with ak09916 mag). In most cases even if we only want the included ak09916 mag at a minimum we must also run the icm20948 to put it into i2c passthrough mode. This change allows us to actually use the IMU in some capacity (logging, analysis, etc), but at a much lower priority where it's never going to be used by the estimator or controllers. > > TODO: set external for each accel/gyro or automatically determine from device id (preferred). Per sensor rotation and offset that depends on a device ID and not the startup order. The instance of the sensor depends on slots that are available on the board and there needs to be a user interface showing > > > We need to overall the current parameter metadata handling for a number of use c…ases (Multi-EKF, GPS blending, collision prevention with multiple range finders, etc). > > > Some of this we already have, but it needs to be moved and generalized per instance, other sensor types are completely missing the concept of per instance configuration. > > - IMU > - EKF2\_IMU\_POS\_{X,Y,Z} > - \*\*TODO:\*\* Move to per instance \`SENS\_IMUx\_POS{X,Y,Z}\` or lump in with existing calibration \`CAL\_ACCx\_POS{X,Y,Z}\`? > - magnetometer > - external rotation, priority > - barometer > - priority, maybe an offset > - \*\*TODO:\*\* Create barometer calibration (\`CAL\_BAROx\`) and populate somehow > - range finders > - orientation > - \*\*TODO:\*\* Move to per instance \`SENS\_RNGx\_ROT\`? > - EKF2\_RNG\_POS\_{X,Y,Z} > - \*\*TODO:\*\* Move to per instance \`SENS\_RNGx\_POS{X,Y,Z}\`? > - optical flow > - SENS\_FLOW\_ROT > - \*\*TODO:\*\* Move to per instance \`SENS\_FLOWx\_ROT\`? > - EKF2\_OF\_POS\_{X,Y,Z} > - \*\*TODO:\*\* Move to per instance \`SENS\_FLOWx\_POS{X,Y,Z}\`? > - differential pressure > - per instance calibration > - what about model (CAL\_AIR\_CMODEL), tube length (CAL\_AIR\_TUBELEN), tube diameter (CAL\_AIR\_TUBED\_MM)? > - GPS > - device ids needed > - \*\*TODO:\*\* extend device ids to GPS and UARTs as a bus option? > - EKF2\_GPS\_POS\_{X, Y, Z} > - \*\*TODO:\*\* Move to per instance \`SENS\_GPSx\_POS{X,Y,Z}\`? > > > > For all sensor types without an explicit calibration step how/when do we have the system scan everything that current exists and populate the parameters? > > Another idea is that each sensor instance could have a configurable optional/required parameter that would roll into preflight checks. ### OS / NuttX Issues were reported: - Memory constraints - Windows Cygwin toolchain compatibility - a lot of smaller issues @david_s5 is trying to solve as they are found Networking configuration mechanism. We have to figure out how we want to enter the data like with parameters. ### Driver No updates ### Commander > > > Sometimes, the mission\_result timestamp is the same as the > internal\_state times…tamp which would meant that we would not switch to > LOITER even though the takeoff is clearly done at that point. > > \#15808 but for master. ### Estimation WMM (world magnetic model) lookup improvement to have an earlier correct mag inclination lookup. > > > Long before the full GPS checks pass the fix is sufficient to lookup the magneti…c declination from the geomagnetic tables. The tables only have data every 10 degrees (~1000 km) and the change is gradual. > > This PR adds a fallback in GPS collection before both NED origin is initialized and GPS checks pass to set the declination (\_mag\_declination\_gps) as soon as there's at least a 2D fix with eph \< 1 km. When GPS checks finally do pass the declination is set again from that lat/lon. GPS blending that was introduced to EKF2 is moved to the general system sensors module. This was caught because > > > Brought the work from this PR https://github.com/PX4/Firmware/pull/13584 up to d…ate with current \`master\` > > Need to test still. > > FYI @dagar @JacobCrabill ### VTOL/Fixed Wing Logic quite often flies directly through the loiter point which leads to the tangential velocity being far off when initially entering the loiter. We have to check with @Paul_Riseborough why these lines are there and if the change breaks anything. > > > Based on \[discussion in slack\](https://px4.slack.com/archives/C3B9NSHRQ/p1601298…551006900?thread\_ts=1601131103.003900&cid=C3B9NSHRQ). > > \*\*Describe problem solved by this pull request\*\* > The current L1 logic often makes the vehicle first fly through center of loiter waypoint, instead of tracking the loiter circle as soon as it is close to it (or after already being inside the circle). > > \*\*Describe your solution\*\* > Remove check for the tangential velocity to "prevent PD output from turning the wrong way". AFAIK this causes the vehicle to fly straight to the loiter center if the tangential velocity is only slightly in the wrong direction (e.g. because it's hitting the loiter circle at a 91° angle). > > \*\*Describe possible alternatives\*\* > Instead of removing check completely, allow small tangential velocities in the wrong direction, e.g. tangent\_vel \< 1.0f. > > \*\*Test data / coverage\*\* > Basic SITL testing. > > \*\*Additional context\*\* > Before: > !\[image\](https://user-images.githubusercontent.com/26798987/94483601-68a45d80-01db-11eb-8081-2396767c73ad.png) > > With this PR: > !\[image\](https://user-images.githubusercontent.com/26798987/94483562-5d513200-01db-11eb-9e1b-6247329a96ed.png) > > @priseborough can you shed some light why it is there? What are the conditions where it could turn the wrong way? Airspeed pre-flight check improvement got finalized. Review is welcome. Question: Does it work if there’s no GPS. Answer: Yes there should be no problem > > > Some updates to the airspeed preflight checks. > > \*\*Describe problem solved by t…his pull request\*\* > \- airspeed validity information given by the airspeed selector/validator is checked for preflight checks > \- user can set maximal allowed airspeed during arming (new parameter ASPD\_MAX\_ARM) > > \*\*Describe your solution\*\* > \- ~~listen to airspeed\_validated instead of airspeed in the airspeed preflight checks~~ > \- ~~don't allow arming if airspeed\_selector is down (as we then have no airspeed\_validated data)~~ > \- ~~add confidence value to the airspeed\_validated message, such that this can be checked at instant of arming (later we can also think about how to include it in the general airspeed validation checks)~~ > \- ~~add new parameter ASPD\_MAX\_ARM to set maximal allowed airspeed during arming (instead of hard-coded 4 m/s like now)~~ > \- ~~rename subsystem DIFFERENTIALPRESSURE to AIRSPEED as airspeed source doesn't need to be a differential pressure sensor~~ > > > \*\*Test data / coverage\*\* > SITL and bench tested. > > Edit: I reduced the scope of this PR, now: > \-check for valid airspeed\_validated (declared valid plus updated less than 1s ago) > \-add param for max airspeed for arming instead of hardcoded 4m/s > > It removes the check for the airspeed.confidence, which I anyway haven't seen working properly, and instead listens to what the airspeed selector says (airspeed valid or not). We may want to add additional checks in the airspeed selector at some point for failure detection on the ground (like for detecting a stuck sensor). ### Multicopter Important bugfix contribution sign of velocity controller derivative: We should have a look at using the estimators NED acceleration output as the derivative state for velocity control. Also we should add a position control status messages logging how much P, I and D contribute to the final controller output. > > > \*\*Describe problem solved by this pull request\*\* > It seems that z velocity deriv…ative part off multi-copter position controller has a sign error. > > > \*\*Describe your solution\*\* > Change sign > > \*\*Test data / coverage\*\* > On master with SIH, try to set MPC\_Z\_VEL\_D\_ACC to 2 : vertical oscillations begin. Then try to set it to -2 or even -4 : the drone stabilizes. > > !\[acc\_z\_sign\](https://user-images.githubusercontent.com/59083163/94403567-ea5da200-016d-11eb-9873-583160d6ba43.png) > > > \*\*Additional context\*\* > As MPC\_Z\_VEL\_D\_ACC default value is 0, it has no impact. > > @MaEtUgR: this regression seems linked to this commit: 38093e4 ### Avoidance No updates ### Simulation Deprecated xacro model definitions are finally gone from the gazebo simulation: > > > \*\*Describe problem solved by this pull request\*\* > Multivehicle simulations in ga…zebo was run using xacro macros to generate sdf files in the \`/tmp\` directory with the necessary port assignments to enable it. > > However, there are several problem with this infrastructure > \- xacros do not support some of the syntaxes that were added in recent sdf versions (e.g. nested models) > \- PX4 uses \[xacro.py\](https://github.com/PX4/sitl\_gazebo/blob/master/scripts/xacro.py), which is deprecated > \- xacro based macros were not on the same path with the models that they represent, therefore got outdated whenever the models were updated. (see below for the current state of \`standard\_vtol\`) > !\[ezgif com-video-to-gif (4)\](https://user-images.githubusercontent.com/5248102/91224554-913fc000-e722-11ea-8f97-0579839cdfef.gif) > > \*\*Describe your solution\*\* > jina2 templates are now used to generate sdf files at build time. This PR moves the multivehicle script to use jinja templates instead of xacro files. After this is merged, xacro macros will be completely removed from \`sitl\_gazebo\` > > \*\*Test data / coverage\*\* > Tested in Gazebo SITL: > !\[image\](https://user-images.githubusercontent.com/5248102/94373588-9ec3dd80-0106-11eb-8e01-5c1199d51d01.png) > > > \*\*Additional context\*\* > \- This requires the following changes in the \`PX4/sitl\_gazebo submodule: https://github.com/PX4/sitl\_gazebo/pull/609 https://github.com/PX4/sitl\_gazebo/pull/612 > \- Fixes: https://github.com/PX4/Firmware/issues/15609 ### MAVSDK #### Release 0.31 > **[Announcing MAVSDK v0.30](https://px4.io/announcing-mavsdk-v0-30-2/)** > > The MAVSDK team is happy to make the v0.30 release available to the community. Find out what is new, and download the packages. ### MAVROS / DDS / ROS2 #### ROS World 2020 > **[ROS World 2020](https://roscon.ros.org/world/2020/)** > > The annual ROS developer conference. 90 minutes slot at convention, 3 different presentations, we’ll get ROS & PX4 developers closer. ### UAVCAN Yesterday there was the UAVCAN dev call (see [Dronecode Calendar – Dronecode Foundation](https://www.dronecode.org/calendar/)): - @PavelKirienko moving forward with DS-015 implementation e.g. ESC messages. See meeting notes for more details: > [@Hardware/Pixhawk Dev Call: Sep 29, 2020](https://discuss.px4.io/t/hardware-pixhawk-dev-call-sep-29-2020/18705): > > Sep 29, 2020 Call Moderators@rrocheAgenda Items DS-015 Discussion Dail In [https://bit.ly/3gNLZ4F](https://bit.ly/3gNLZ4F) Meeting Minutes There was a major shift in the development of DS-015, we are moving from targeting Classical CAN implementations to CAN FD, we believe this is the way to go and to future proof the spec. The PR below from Pavel, is a major refactor from the messages included in DS-015, into publicly regulated data types, this is on-going work, and so far only covers some of the basics on actua… * * * ## Release What’s the timeframe for the 1.12 release? We want a faster release cycle as we discussed. We should build a team/group to help with the release. There are some good examples of other open-source projects for how to handle it such that not all the additional load falls on @dagar. ## Community Q&A Kalyan Siriam: Has a crash log: [Flight Review](https://logs.px4.io/plot_app?log=1b25a08f-7254-4230-8f24-bfbdf044ed8a) and didn’t figure out why it crashed. It might be because it was overloaded with weight but Manual was flying fine. It was hard to pilot but worked. In position mode it crashed. Any log analysis and input would be welcome. Kal is available on slack and will create an issue to keep track. @JingerZ : What do we do about Hacktoberfest [https://hacktoberfest.digitalocean.com/](https://hacktoberfest.digitalocean.com/)? We wanted to participate before but missed the deadlines to register before. We should participate. The idea is to bring in new contributors and celebrate the existing ones by focusing on contributions and reward them for one month. It’s open to all open-source projects. Let’s have a public meeting next week to get this started. * * * ## Errata and Feedback Let me know below if we failed to capture anything the right way, and if there are any updates (not present here), or you have feedback you would like to share with the dev-team.