# PX4 Dev Call: October 14, 2020 **URL:** \ **Category:** PX4 Autopilot\ **Created:** [October 7, 2020, 5:00pm UTC](https://discuss.px4.io/t/px4-dev-call-october-14-2020/18933 "2020-10-07T17:00:07Z")\ **Posts on this page:** 2\ **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:** [October 7, 2020, 5:00pm UTC](https://discuss.px4.io/t/px4-dev-call-october-14-2020/18933/1 "2020-10-07T17:00:07Z")
# October 14, 2020 ## Agenda - Status update by component/project - Roadmap, and Release discussion - Community Q&A - In-Depth discussions ## Join Meeting **Meeting ID** : 946 175 205 **Passcode** : 108516 > **[Join our Cloud HD Video Meeting](https://zoom.us/j/946175205?pwd=UWwrZWwrZnVSdGxoSFpTVHVITkVUdz09)** > > 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 ### System Architecture The document shows that people who voted prefer the two repository names: “PX4-Autopilot” or “PX4Autopilot” People that have an opinion on this please prepare them for next week, we’ll cut a decision in the next dev call. > **[\[draft\] PX4 Repository Rename Project](https://docs.google.com/document/d/1-oU995ayiipjHBA_2CwPJ5XaW__qshKkqoIr4UtqLZw/edit)** > > PX4 Repository Rename Project Date: April 15th, 2020 -- Status: DRAFT This was originally proposed on the PX4 Dev call of April 15th by Matthias, as a follow-up from a discussion between Lorenz and Julian Oes. Goal We are trying to rename some of the... > > > Possible fix for https://github.com/PX4/Firmware/issues/15940. We’ve been too tolerant of flaky CI. The linked issue is probably MAVSDK crashing. But there’s multiple potential issues e.g. with timing and or lock-step. Do not tolerate CI failures!! The majority are real failures. > > > \- standard\_vtol: 'Fly forward in position control': failed > - https://github….com/PX4/Firmware/pull/15939/checks?check\_run\_id=1236860638 > - https://logs.px4.io/plot\_app?log=15eba26f-7e86-439b-b44e-188cb41c0c91 > - iris: 'Land on GPS lost during mission (GPS height mode)': failed > - https://github.com/PX4/Firmware/pull/15943/checks?check\_run\_id=1238804612 > - https://logs.px4.io/plot\_app?log=bf7c6b14-31b0-43a2-9377-88c0f99d28c7 > - \*\*SIGABRT - Abort (abnormal termination) signal\*\* > - sitl\_gazebo crashing? > - standard\_vtol: 'Continue on mag lost during mission': failed > - https://github.com/PX4/Firmware/pull/15930/checks?check\_run\_id=1248017118 > - https://logs.px4.io/plot\_app?log=3cf4b823-fdbb-4e84-8ff2-c4a79413d333 Goal: have a consistent [-1,1] range for all sticks. MAVLink spec MANUAL\_CONTROL also has [-1000,1000] range for all sticks but QGC sends [0,1000] to work with PX4. @dagar is checking the QGC scaling and we’ll need checks to ensure the safe transition. > > > \*\*Describe problem solved by this pull request\*\* > Fixes #9331 and works towards …a solution for part of https://github.com/PX4/Firmware/issues/15874 > > \*\*Describe your solution\*\* > Rescale \`manual\_control\_setpoint.z\` which represents the throttle stick value from a range of \[0,1\] to \[-1,1\]. > > \*\*Describe possible alternatives\*\* > I think for nicer usage in all the different modules it would be helpful to extend the \`Sticks\` class to provide the common scaling and gestures (is stick below minimum) from one single place. > > \*\*Test data / coverage\*\* > Not yet tested. > > \*\*Additional context\*\* > This is also useful to be able to convert between RC modes (https://www.rc-airplane-world.com/rc-transmitter-modes.html) on the fly without having to recalibrate everything. ### OS / NuttX Either we have a variable for the absolute path that is empty on NuttX or we have an invocation command other than “source” that does the job. @david_s5 will have a look and reach out for questions and testing. [https://github.com/PX4/Firmware/issues/15795](https://github.com/PX4/Firmware/issues/15795) All other known issues with the new NuttX version are sorted out. Resources are tight on some older boards. @david_s5 is trying to get our required changes to upstream NuttX such that we can sty in sync with upstream. ### Driver Fix for DPS310 barometer driver on mRo boards > > > Pressure was off by 4 millibar, took a look at the driver and found a copy/paste… bug. Fixed it and now it agrees with my other barometers. ### Commander No updates ### Estimation This might be interfering with the current Multi-EKF efforts. We’ll discuss it in the in-depth section later. > > > Instead of using a fixed mag bias variance to compute the influence of the curre…ntly estimated mag bias on the previously saved parameter, we now also save the variance of the parameter. > > The value is automatically updated and the only remaining tuning parameter is \`EKF2\_MAGB\_K\`, which is more intuitive. ### VTOL No updates ### Fixed Wing @Roman giving a heads up about a revision of TECS that has better performance in holding altitude during turns. ### Multicopter No updates ### Avoidance No updates ### Simulation > > > This is a lockstep fix. If there's a poll error (POLLERR) in \`MavlinkInterface::…pollForMAVLinkMessages()\` then another new \`HIL\_SENSOR\` message is sent before PX4 sends \`HIL\_ACTUATOR\_CONTROLS\`. > > https://github.com/PX4/sitl\_gazebo/blob/e4e32117df1d8aba00b0685ebd0cc5ffc066a970/src/mavlink\_interface.cpp#L219-L221 @Roman Does JSBsim work with lockstep? Can we specify the speed factor? @Jaeyoung-Lim Lockstep yes, speed factor is not exposed at the moment but can be added. Shoutout: We have a direct simulation with JSBsim now and it simulates fixed wing physics much better than gazebo. There’s a lot of activity currently on that topic. PX4 failure injection was extended to be able to disable specific e.g. gyroscopes. We’ll try to also leverage the failure injection on the JSBsim side in the future. ### MAVSDK > **[Release v0.32.1 · mavlink/MAVSDK](https://github.com/mavlink/MAVSDK/releases/tag/v0.32.1)** > > Bugfixes: > > Fix iOS release path in CI (#1226). > > Contributors: > @JonasVautherin ### MAVROS / DDS / ROS2 No technical updates We are participating at the ROS World with 6x 50 minute sessions. There will be a lot of people \> 2000 registrations already. ### UAVCAN Call was yesterday, you can participate looking at the calendar: [Dronecode Calendar – Dronecode Foundation](https://www.dronecode.org/calendar/) Notes from call yesterday: > [@Dev Call: Oct 13, 2020 - UAVCAN Work Group Meeting](https://discuss.px4.io/t/dev-call-oct-13-2020-uavcan-work-group-meeting/18923): > > Oct 13, 2020 Call Moderators@rrocheAgenda Items libacanard v1.0 Release DS-015 Data Types Wrap up of the initial set of data types PR and check if anyone else wants to discuss any specific part or any data type of the PR. The PR will be merged after the SIG call, if all is cleared; Nunavut C-Serialization update PR is in its final stages Needs help with contributors adding unit testing TODO: find help! (ping @PavelKirienko if you have a few minutes) DS-015 Timeline Provide a timeli… Reached a major milestone: Official drone namespace in the UAVCAN message specifications Example: Battery/BMS, ESC, Servo communication > > > This PR brings in the first iteration of domain-specific services for drones. Th…e background is explained on the forum at https://forum.uavcan.org/t/ds-015-mvp-progress-tracking/936. > > This design is optimized for CAN FD and more capable transports (such as UAVCAN/UDP or UAVCAN/serial), but it is, nevertheless, compatible with Classic CAN. See this spreadsheet for more info: https://docs.google.com/spreadsheets/d/1xSBcnnqbHBEZfFg4cqiS1weXHwX3X0MFWpW1WcEBIds/edit > > Every definition here bears version number v0.1, meaning that nothing is release-ready yet. We will start stabilizing things as soon as production systems leveraging these services will start being released. > > Related thoughts: https://forum.uavcan.org/t/on-multi-agent-services-and-design-guidelines/947 > > GitHub does not (yet) support syntax highlighting for DSDL files, so I recommend viewing the files locally using VSCode with the \[uavcan.dsdl\](https://marketplace.visualstudio.com/items?itemName=Uavcan.dsdl) extension. Just clone this repo and open its directory in VSCode, then accept all recommended extensions. > **[DS-015 MVP progress tracking](https://forum.opencyphal.org/t/ds-015-mvp-progress-tracking/936)** > > Just had a call with @TSC21, @PetervdPerk, @dagar where Nuno suggested that we describe the scope of the current effort on the forum so that we could use it as a guideline. This is the post for that. I suggest that we also use this thread for... Libcanard v1 is released and will be supported by PX4 > **[Libcanard for UAVCAN/CAN v1 is released](https://forum.opencyphal.org/t/libcanard-for-uavcan-can-v1-is-released/774)** > > Libcanard v0.100, implementing UAVCAN/CAN v1, is now available: Key features: Full test coverage and static analysis. Partial compliance with automatically enforceable MISRA C rules (compliance report not available). Detailed time complexity... * * * ## Release Minor update 1.11.1 available with accumulated bugfixes. ## Community Q&A @camposi Emulate an Oblique filter for moving the gimbal to reduce necessary survey rows by extending the field of view taking pictures in slightly changes gimbal orientations. The idea is to have a single high-level command to make the camera cover the bigger field. This reduces the number of necessary waypoints since the constantly changing camera orientations don’t require extra in between points. @Jaeyoung-Lim Don’t we lose straight down picture information by rolling it left and right? The frequency of pictures is increased e.g. by a factor of 3 to be able to take pictures left, middle and right. @bresch Does the geotagging capture the camera attitude correctly? It should work since it uses the gimbal status but most mapping tools don’t take use of the tagged camera attitude. We need to get the MAVLink spec adjustment merged first and then we can get PX4 changes and the QGC side which is also already ready in. > > > \*\*Problem\*\* > A solution commonly used to increase the coverage and efficiency in… mapping surveys is to have multiple cameras at oblique angles to capture a wider areas per flight line, this also has potential benefits of capturing more data from facades and tall objects. However, adding cameras increase cost and complexity of the equipment, on the other hand, mapping cameras are generally capable of shooting multiple frames per second and are usually triggered about once every two seconds or less frequently in mapping missions, we could better use the hardware capabilities if we moved the camera mount between shots while decreasing the shooting distance to keep the overlap settings. > > \*\*Solution\*\* > I decided to implement a solution that uses the already existing VEHICLE\_CMD\_DO\_SET\_CAM\_TRIGG\_DIST, plus some unused parameters, 4~6, to issue VEHICLE\_CMD\_DO\_MOUNT\_CONTROL between camera shots to move the camera from left to right in stages, right after it passes half the shooting distance, allowing time for mount actuation and camera exposure. To keep the frontlap the solution expects the GCS to adjust the trigger distance accordingly. The parameters usage are as follows: > > \- 4: number of oblique positions (this will generally be 2 or 3, but could be more, depending on desired frontlap, flying speed and hardware capabilities (how fast are the camera and mount)) > \- 5: the maximum angle to roll the camera left and right from the center, the solution calculates the interval angle between positions from this information and the previous parameter > \- 6: the pitch angle for mounts that support pitching > https://github.com/PX4/Firmware/pull/15882 > > \*\*Implementation\*\* > I proposed the change to mavlink standard here: https://github.com/mavlink/mavlink/pull/1508 > I added it to QGC here: https://github.com/mavlink/qgroundcontrol/pull/9103 > > \*\*Alternatives\*\* > Other way would be to add a new command, but since it has many aspects that are essentially the same as the CAM\_TRIGG\_DIST, I thought it would be better to add a few parameters to the existing command, as it would also allow it to work under Mavlink 1 with the limited number of 255 commands. > > \*\*Test data / coverage\*\* > I tested it with the gazebo\_typhoon\_h480 model and checked the outcome from the video stream in QGC. > > \*\*Additional context\*\* > Later I plan to write a paper comparing the gains in area coverage and any accuracy change from using this solution with relation to the traditional survey mode. I am feeling confident about a positive outcome. ## In-Depth discussions - Estimator stored mag bias variances saving working in Multi-EKF scenario Conclusion: Move forward with the pr for one mag bias saving and skip this saving in the initial Multi-EKF implementation until we have the right selection in place. * * * ## 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. ---
**Author:** ![camposi](https://discuss.px4.io/user_avatar/discuss.px4.io/camposi/32/7134_2.png) [@camposi](https://discuss.px4.io/u/camposi)\ **Post date:** [October 14, 2020, 3:34pm UTC](https://discuss.px4.io/t/px4-dev-call-october-14-2020/18933/2 "2020-10-14T15:34:19Z")
I would appreciate if we had the time to discuss the following PR: >