# PX4 Dev Call: December 02, 2020 **URL:** \ **Category:** PX4 Autopilot\ **Created:** [November 25, 2020, 6:00pm UTC](https://discuss.px4.io/t/px4-dev-call-december-02-2020/19763 "2020-11-25T18:00:19Z")\ **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:** [November 25, 2020, 6:00pm UTC](https://discuss.px4.io/t/px4-dev-call-december-02-2020/19763/1 "2020-11-25T18:00:19Z")
# December 02, 2020 ## Agenda - Status update by component/project - Roadmap, and Release discussion - Community Q&A - In-Depth discussions ## Join Meeting > **[Jitsi Meet](https://meet.jit.si/PX4DeveloperCallWeekly)** > > Join a WebRTC video conference powered by the Jitsi Videobridge * * * This is the 3rd last dev call in 2020. ## Component update ### System Architecture MTD architecture change introduced before. @david_s5 wants to talk through if we want to get it in. Bugs should be fixed. It might not fit flash. Should we make fmu-v2 multicopter only, strip down px4io flash space? > > > Ultimately we want to have a device tree like description that can be statically… compiled, and have overlays. See last section (DT Straw Man) > > The changes here-in support a migration path to remove \`mtd\` from the rcS and only call it from the board start up code. > > uorb is started from the board files (this and the mtd start can be moved to the px4\_init layer once fully fleshed out) > > \`BOARD\_MANAGED\_MTD\` is used to condition the mtd code. Once all the boards are converted (FLASH permitting) mtd.cpp can be refactored again and vastly simplified. > > The digested mtd section of DT is seen in the the board file \[mtd.cpp\](https://github.com/PX4/PX4-Autopilot/compare/pr-mtd-mgr?expand=1#diff-1b6b9fce0abee35f4fa573ce88a986254b8a8fcda2bbc3494c0b7a1a5ae4a6e5) (there is more work to be done here) > > \# DT Straw Man > The following is a file is used at compile time to build > board.h from a template > adding pin selection > DMA etc > > \`\`\` > board: fmuv5x { > cpu: stm32f7 { > main\_osc: 16Mhz, > rtc\_osc: 32khZ > } > > buses { > I2C1: { > device:INA226 { > driver:ina226 > address: 0x41 > policy { > alternate: {I2C2 : INA226} > boot: optional > arm: mandatory or alternate > } > } > device: ist8310 { > driver: ist8310@0xe > address: 0x0e > policy { > boot: optional > arm: mandatory > } > } > > device:LED { > driver: rgbled@0x55, rgbled\_ncp5623c@0x39 > address: 0x55, 0x39 > policy { > boot: optional > arm: optional > } > } > > } > I2C2: { > device: INA226 { > driver:ina226 > address: 0x41 > policy { > alternate: {I2C1 : INA226} > boot: optional > arm: mandatory or alternate > } > } > I2C3: { > device: MS5611 { > driver: ms5611 > address: 0x77 > policy { > boot: mandatory > arm: mandatory > } > } > > device: 24LC64T { > driver: mtd > partition: { > /fs/mtd\_caldata,all > } > address: 0x51 > policy { > boot: mandatory > arm: mandatory > } > } > } > I2C4: { > device: BMP388 { > driver: bmp388 > address: 0x76 > PWR: PG8 > policy { > boot: mandatory > arm: mandatory > } > } > > device: SE050 { > driver: na > address: 0x48 > PWR: PG8 > policy { > boot: disabled > arm: disabled > } > } > } > > SPI1: { > device: ICM20602 { > driver: icm20602 > paramaters: { > r > } > CS: PI9 > DRDY: PF2 > PWR: PI11 > } > } > > SPI2: { > device: ISM330DLC { > CS: PH5} > DRDY: PH12 > PWR: PD15 > } > } > > SPI3: { > device: DRV\_GYR\_DEVTYPE\_BMI088 { > CS: PI8 > DRDY: PI7 > PWR: PE7 > } > > device: DRV\_ACC\_DEVTYPE\_BMI088 { > CS: PI4 > PWR: PE7 > } > SPI4: { > PWR: PG8 > } > > SPI5: { > driver: mtd > partition: { > /fs/mtd\_params,50, > /fs/mtd\_waypoints,50 > } > policy { > boot: mandatory > arm: mandatory > } > > device: SPIDEV\_FLASH(0) > CS: PG7 > } > } > > SPI6: { > CS: PI10 > DRDY: PD11 > CS: PA15 > DRDY PD12 > } > } > > USART6: { > device: px4io > driver: px4io > TX: PC6 > RX: PC7 > > } > ETHERNET : { > PWR: PG15 > } > } > \`\`\` > > to process mtd entries: > Query the dt for all mtd. > Get's back an interator > allocate an instance table sized but iteratior.count > populate it from the interator. > then for each I of the interator call mtd\_start > \`\`\` Network manager dynamically configurable. Needs the pr just above for the separate parameter partition and will be rebased. > > > This is the same functionality as https://github.com/PX4/Firmware/pull/15873 but… against NuttX 10.0.0+ > > This will allow us to upgraded to NuttX 10.0.0+ and beyond with only a single rejected commit in nuttx/apps. > > @bkueng @dagar The first commit is in a new separate PR (https://github.com/PX4/Firmware/pull/15966) that ~~may need negotiating when #15731 comes in.~~ is based on current master. We may want to use the base EEPROM and not the FRAM. > > The netman system command will display, set and save the network > settings. > > netman show - Displays the current settings. > > netman update - Will check for a net.cfg file on the SD card. > If present, it will update the paramaters, > delete the file, and reboot. Using the new settings. > > netman save - Saves the current settings to net.cfg on the SD card. > This file shoulf be renamed to preserver it across > reboots or editited to chech networkin paramates. > > File format is name\value: > > echo DEVICE=eth0 \> /fs/microsd/net.cfg > echo BOOTPROTO=fallback \>\> /fs/microsd/net.cfg > echo IPADDR=192.168.0.4 \>\> /fs/microsd/net.cfg > echo NETMASK=255.255.255.0 \>\>/fs/microsd/net.cfg > echo ROUTER=192.168.0.254 \>\>/fs/microsd/net.cfg > echo DNS=192.168.0.254 \>\>/fs/microsd/net.cfg > > Valid values for \`proto\` are \`dhcp\`, \`static\`, \`falback\` > Both will try dhcp for CONFIG\_NETINIT\_FALLBACK times > and fall back to the static address. > > NETMASK - is the network mask. > IPADDR - this nodes ip address for static or fall back. > ROUTER - The default route. > DNS - The address of the dns server. > > > \## Background > > 5 Networking configuration deficits exist in NuttX > > 1. NuttX only supported compile time DHCP or STATIC IP addressing. > 2. The static setting are not human readable ip format. > 3. If DHCP was chosen the lease would not be renewed. > 4. If the connected network was powered on after the nuttx node (FMU) booted, the netinit would time out and not bring up the network. > 5. The ability to signal PHY state changes to use the Nuttx Net Monitor was dependent on an IRQ line from the PHY to the CPU. > > The nuttx backports fix 4. The Apps rejected backport fixes 1,2,3 > > The Upstream ipcfg non binary solution is dependent on a writable FS. It has no way to default it's setting. The pathing is rather deep to follow in a Linux like way. > > There are some issue with this approach on an FMU. > We can not use this on system without a SD card or EMMC FS. > Networking will not work if the SD card is not inserted. > > Greg did a great job in adding a binary solution as well. But we either need to > a) repartition the FRAM > b) Uses a eeprom > c) Write a character driver the to read/write the date in the param system. > > All of theses choices have consequences we should discuss. > > The network Netman add a way to default the setting, Change the setting and ensure an atomic update. ### OS / NuttX Apache team will release 10.0.0 soon. We have to discuss if we want to switch to the release, keep up with master or stay for now. It’s in voting. New boardsupport for Gumstix fmu-v6 board. It’s not exactly the same as a Pixhawk 4 in terms of connectors but it has standard JST-GH pixhawk pining for external GPS, mag, … > > > USB-HS (ULPI) support still outstanding. New boardsupport for Pixracer Pro (H7 chip, not following fmu standard strictly) > > > This is a new STM32H7 board with 3 IMUs and 8 PWM outputs from mRo (https://stor…e.mrobotics.io/mRo-PixRacer-Pro-p/m10064c.htm) that's a successor the Pixracer. > > !\[Screenshot from 2020-10-10 20-48-38\](https://user-images.githubusercontent.com/84712/95667873-fe27e180-0b39-11eb-8af3-59868f76375f.png) > !\[Screenshot from 2020-10-10 20-49-01\](https://user-images.githubusercontent.com/84712/95667883-10098480-0b3a-11eb-9e36-b2777820dda9.png) Changes for new revision of NXP board > > > Changes from ringout for nxp\_fmurt1062-v1 ### Driver No updates ### Commander Events interface 🚀 Rearchitecture improving checks and communication to the ground station @bkueng is open to review and likes to discuss version compatibility with the ground station QGC - Are calibration messages events? It’s a stretch but possible for that particular case. - Are the events in PX4 or in a submodule? Most of them are in PX4 and for a two-sided protocol like calibration would go into the submodule. - Should libevents go under the MAVLink org? It could but it’s in principle independent of MAVLink - What’s the user experience difference? Instead of sending a MAVLink string message, you can send a whole set of parameters with the event to point the user to errors, documentation, parameters, … The example in the pr’s description shows it well. - Localization? Possible, not finished in the first version but the json can be translated on a server and QGC can use that then depending on the language. - Versioning? It’s designed to work with a master version of definition and event IDs and names should be backwards compatible. - Adding custom events downstream? Need to be hosted separately or live in flash. There should be a per version and per target metadata on the server. - How many events are there? 32 Bit, will last a while > > > This brings the events interface - I've been sidetracked for quite a while but f…inally found some time to continue. > > For those not familiar: this will replace the \`STATUSTEXT\` mavlink messages. > Full details: https://docs.google.com/document/d/18qdDgfML97lItom09MJhngYnFzAm1zFdmlCKG7TaBpg/edit > > \*\*How do you use it?\*\* > From anywhere in the code, you can do something like: > \`\`\` > /\* EVENT > \* @description > \* This is the description. It can be as long as you want, contain arguments, URL's or params. > \* - value of a: {1} > \* - value of b: {2} > \* - value of f: {3:.3} > \* > \* Link: \documentation\ > \* > \* \ > \* This is only meant to be shown to developers. > \* It might contain a parameter, like \COM\_ARM\_MAG\_STR\, to disable a check. > \* \ > \* @arg1: a > \* @arg2: b > \* @arg3: f > \*/ > events::send\(events::ID("test"), "Short message describing the event", events::Log::Warning, a, b, f); > \`\`\` > From that only an event ID + arguments + log level get sent and logged at runtime. Metadata is extracted during build and gets to the GCS through the COMPONENT\_INFORMATION API. > > Some PX4 specifics: > \- There's a new submodule: https://github.com/bkueng/libevents (for common events, validation and code generation) > - the code generation allows to use events from the common namespace (e.g. for calibration protocol) > \- Required memory usage (for event buffers): 1.7KB > \- Event extraction from source takes about 300ms > \- To test I changed the accel calibration to use the events interface, see 34986c1a60c52b23d8a3116673fd27b504a1ecb2. I tested with an artifical event drop rate of 50%, and over telemetry, and it still worked. > > \### Health and Arming checks > Health and arming check results are reported over the events API. There are 2 summary messages that contain overall information about subsystem warnings and errors, and overall arming results per flight mode category + current flight mode. Flight mode categories include Mission, Autonomous, Position, which for example allows a GCS to know whether flying a mission is possible or not, independent from the current mode. Each failure/warning contains the affected subsystem (e.g. IMU) and mode category (allowing a GCS to only show problems for the current mode for example). > This and together with continously running the checks and only report on change, requires some changes to the existing code. The structure is similar, so not too big of a change. For an example I added the power + ekf2 checks: ab445394be99ee15efbcf879a6011af07ec395d7. > Some requirements: > \- For predictable results there cannot be additonal checks outside of the arming checks (similar for arming-source-dependent checks) > \- We cannot feed mode-dependent results into the checks > \- To cleanly solve cases like \`arm -\> takeoff -\> failsafe triggering\`, bigger changes are required. I could imagine a structure like this (w/o having gone through the details): > !\[commander\](https://user-images.githubusercontent.com/281593/100462020-e4cafc80-30c9-11eb-983f-866c6a37515c.png) > > > This PR is on top of https://github.com/PX4/PX4-Autopilot/pull/16039. > > \*\*Main missing things:\*\* > \- COMPONENT\_INFORMATION + translation workflow + push metadata to server > \- arming checks and sensor calibration > > \*\*Open questions:\*\* > \- how to transition? What version compatibility do we want? > > I'm sure I left out some things, so feel free to ask, provide any suggestions, ... Reevaluating RC when validity bit change > > > \- re-evaluating mode switches on altitude or position validity change can create… confusion when also relying on mode changes via mavlink > - limiting this logic to only apply when disarmed solves the original problem (respecting initial switch position) without introducing potential problems mid-flight Commander low priority thread is finally gone, there is a calibration thread but it does not need to have access to a static shared vehicle\_status anymore 🎉 > > > \- removes race conditions > \- removes dependencies on static data & methods > \- re…duces RAM usage by ~3.8KB > > Tested: > \- RC calib > \- ESC calib > \- sensor calib > \- param reset > Small logic change when takeoff is complete it switches to > > > \- only consider if in NAVIGATION\_STATE\_AUTO\_TAKEOFF to avoid confusion with fail…safes > - limit evaluation to ORB\_ID(mission\_result) updates when armed and not landed (small optimization) If you start your vehicle without RC and have a GPS lock it switches to Hold/Loiter (home position is no requirement) > > > \- auto transition to LOITER if disarmed with no RC only requires a valid global …position > > Pretty minor, but there is a difference. RC switch debouncing on hold because of not enough flash ### Estimation No updates ### VTOL No updates ### Fixed Wing No updates ### Multicopter > > > \*\*Describe problem solved by this pull request\*\* > When sending acceleration setp…oints as part of offboard position setpoints as part of \[SET\_POSITION\_TARGET\_LOCAL\_NED\](https://mavlink.io/en/messages/common.html#SET\_POSITION\_TARGET\_LOCAL\_NED) mavlink message, the vehicle would not take off. > > The reason seems to be that a downward acceleration was being copied while the vehicle was in \`flying\_but\_ground\_contact=true\` state. > > \*\*Describe your solution\*\* > This PR adds the following. > \- Enables a acceleration triggered takeoff based on the acceleration setpoint > \- Fixes the takeoff logic so that the vehicle is able to take off while acceleration setpoints are being sent > > \*\*Test data / coverage\*\* > Having acceleration setpoints do seem to improve the performance of trajectory tracking. > The below examples show a log of the vehicle tracking a circular trajectory with and without acceleration feed forward inputs. > > \- (BeforePR) Without Acceleration feedforward setpoints: https://review.px4.io/plot\_app?log=3f8f3643-991b-435e-8286-289aa2920803 > !\[image\](https://user-images.githubusercontent.com/5248102/92527345-249aea00-f227-11ea-9b63-0b526ac297d2.png) > > \- (AfterPR) With Acceleration feedforward setpoints: https://review.px4.io/plot\_app?log=7515c5b1-bfc1-4026-9a11-8eabda5134c0 > !\[image\](https://user-images.githubusercontent.com/5248102/92527377-311f4280-f227-11ea-8983-cf28ee816341.png) > > > \*\*Additional context\*\* > \- Acceleration feedforward control was added in https://github.com/PX4/Firmware/pull/14212, but was not functional for offboard control. > > > \*\*Describe problem solved by this pull request\*\* > Three reported issues from pil…ots: > 1. It takes a long time (~5 seconds) until the position lock setpoint is set. > 2. Vehicle flies back to original position when moved on the ground in position mode. > 3. Vehicle takes too long to slow down to zero at the very end. > > \*\*Describe your solution\*\* > 1. See 3. > 2. I made the \`resetPosition();\` function for exactly that purpose but in the end forgot to call it in the \`activate()\` function of the flight task -\> added \`\_stick\_acceleration\_xy.resetPosition();\` now like it was originally planned. > 3. It takes so long to brake at the end because acceleration = velocity\_dot = k \* velocity results in an exponential decay and has nice characteristics but when velocity reaches close to zero it takes an eternity to reach exactly zero. The solution I came up with is a continuous function that is linear above 1 and square root below 1. It's used to boost the brake drag in low speeds. > > \*\*Test data / coverage\*\* > I tested in SITL and it gives really nice results. I suggest we try it on a real large vehicle before emerging as well, I'll organize that. > I added unit tests for the \`sqrt\_linear()\` function. > > \*\*Additional context\*\* > Function plot \`sqrt\_linear()\` (negative input values result in zero output): > !\[image\](https://user-images.githubusercontent.com/4668506/100889427-65696e80-34b7-11eb-8b5a-31c4ad6b41e5.png) > > Brake from high velocity now starts like before but keeps more brake drag until the end: > !\[image\](https://user-images.githubusercontent.com/4668506/100889828-e294e380-34b7-11eb-8d2b-298a0b096e0d.png) @Pedro-Roque Started discussion to have the modular option to run custom controllers but have the existing PX4 controllers take over if anything bad happens. > > > \*\*A configurable low-level control chain\*\* > The objective for this WIP PR is to …modularize the low-level control chain so that it is easier to integrate different controllers for rate / attitude / position on multicopters. The framework shall be extendable to other systems afterwards, but I will start with these. We hope that this makes it easier for everyone to incorporate novel controllers into the stack, as well as provide researchers with an easy way into PX4 to test their own control approaches. > > \*\*Describe your solution\*\* > Involved devs/users: @dagar @Jaeyoung-Lim @bresch @PepMS > The solution will be a muxing of which low-level controllers are active for a specific flight. The user selects (or doesn't, hence leaving default) the controllers for MC Position, MC Attitude and MC Rate that he wishes to use on a given flight, before the vehicle is armed. For all runs, the default PX4 controllers are initiated and ready, but are not running in parallel - they stay dormant but will takeover once the user leaves OFFBOARD mode. > > Gdrive Doc (ongoing discussion moved there): > https://docs.google.com/document/d/1bexM6KeLv73wtiiRvYTqrCHi-HpvmC5YHYHy5CTjibQ/edit?usp=sharing > > On the one hand, this allows for sandboxing of controllers under test, providing a safer environment to test new research. On the other hand, I will also provide basic templates that will allow for anyone to implement their own control laws on the low-level system and test them in SITL. > > \*\*NOTE\*\*: this will be WIP for at least a few months. However, interested devs are welcome. I will be working on this at my own pace. Breaking out flight tasks into a separate flight\_mode\_manager module is the first step to have an implementation per mode with that architecture independent of the vehicle type. > > > \*\*Describe problem solved by this pull request\*\* > The FlightTasks library was de…signed to separate the core multicopter position control from the position, velocity, acceleration setpoint generation to fulfill various tasks. The separation hepled a lot in terms of modularity and debuggabilty and the main data flow is through generated message structs like \`vehicle\_local\_position\_setpoint\` (, \`vehicle constraints\`, \`landing\_gear\`) but the two pieces are not completely separate. The FlightTasks library is technically still inside the position control module. Also there are certain dependencies e.g. for landing takeoff limiting and similar cases that still lead to unexpected problems every now and then. > > \*\*Describe your solution\*\* > I strated seprating out the FlightTasks library to live in a separate module that I called \`flight\_mode\_manager\` with the plan of the Navigator Architecture planning in mind that we aim towards having flight mode classes like flight tasks for all setpoint generation in the future. It's unfinished and I'm trying to separate certain dependencies in a good way to be able to cut a clear line between the modules. > > The main pain points so far are: > > \- \[x\] \*\*Position state preprocessing\*\* - The position control module should use the state as published by the estimator and not generate its own mixed state that is not available to other modules or in the log. > \*\*EDIT:\*\* This has to be solved in a idfferent pr but I made sure it's no blocker anymore here. > \- \[x\] \*\*Emergency failsafe\*\* - I think the position control module should be able to handle the situation where setpoints are gone for a certain time or forever and the setpoint generation would stop publishing when things go really wrong. > \- \[x\] \*\*Hard limits vs specified constraints\*\* - We should get rid of specified constraints that get applied in the controller, we already started to do that. The hard limits stay to have sane execution. > \*\*EDIT:\*\* This has to be solved in a idfferent pr but I made sure it's no blocker anymore here. > \- \[x\] \*\*Land/Takeoff special cases\*\* - Out of limits, more restrictions, safety critical land detection. > \- \[x\] \*\*WeatherVane mess\*\* - It's a global object that gets instanciated dynamically and passed around by pointer. It works around the entire architecture and we should move to the local scope where it's actually used. > \*\*EDIT:\*\* This has to be solved in a idfferent pr but I made sure it's no blocker anymore here. > > > \*\*Test data / coverage\*\* > SITL flies no. Testing for correct takeoff ramp and so on still pending. > > \*\*Additional context\*\* > Discussed starting point from https://docs.google.com/document/d/1N59JHFqL\_E9X4b-U0CzxW\_eydqXUHZMxAH\_FTD30ilk/ > Bigger picture tracked in https://github.com/PX4/Firmware/projects/34 ### Rover Rover takeoff is fixed and hence missions on rover work again. > > > \*\*Describe problem solved by this pull request\*\* > Previously, rover vehicles wer…e not able to handle Takeoff waypoints. The behavior when a takeoff waypoint was passed to a rover vehicle was: > \- The vehicle would not move since the waypoint was too close > \- The takeoff waypoint would not get accepted since rovers are not able to climb and reach the altitude > > I think it might be obvious that one "should not" pass takeoff waypoints to a vehicle. However, QGroundControl only lets you plan a mission that starts with a takeoff waypoint. While this should also be an improvement on the QGC side, I think it is still useful to handle this case on the vehicle side so that the vehicle can still progress with the mission even with a takeoff waypoint > > \*\*Describe your solution\*\* > This adds a special case when handling takeoff waypoints for rover vehicles. The acceptance radius is set to only consider horizontal distance to the waypoint, if the vehicle type is rover. > > \*\*Test data / coverage\*\* > \- This was tested in SITL gazebo, with the rover model. > \`\`\` > make px4\_sitl gazebo\_rover > \`\`\` > This log shows a full mission successfully finished starting with a Takeoff waypoint and finished with a RTL: https://review.px4.io/plot\_app?log=25fe983b-44d0-4a11-a7c2-2ab9662c35d4 @bperseghetti Uploaded the CAD files for his open reference rover design for simulation and real-world model builds. It works in real world, there’s a BOM with recommended parts without affiliation. Total build cost with all features and recommended parts is \<700$ and hence orders of magnitude cheaper than off the shelf solutions. If you buy all the parts including the allen wrench and Philips head screwdriver you can put it together without any soldering. Note: The release section of the repo contains the large files. > **[GitHub - rudislabs/DevRoverCAD: Open DevRover CAD](https://github.com/rudislabs/DevRoverCAD)** > > Open DevRover CAD ### Avoidance No updates ### Simulation No updates ### MAVSDK No updates ### MAVROS / DDS / ROS2 There was some change required in serializing the datatypes to optimize for lowest bandwidth consumption. Review and documentation is still needed. > > > \*\*Describe problem solved by this pull request\*\* > On the serialization/deseriali…zation templates, \`get\_children\_fields()\` was returning the message fields ordered by the size of the data types, resulting on mismatches between the expect message structure and the received/sent message structure for nested types - this was identified by @mickey13 while using \`position\_setpoint\_triplet\` for offboard control. > > \*\*Describe your solution\*\* > Although uCDR by default does buffer alignment, we currently don't have a straightforward way of changing the field ordering of the messages without breaking the way they are serialized/deserialized in Fast-CDR. Fast-CDR though has a faster mode that allows to do serialization without byte alignment, which can be used, though Micro-CDR doesn't have this mode implemented. So for now, we assume by alignment but no bandwidth optimizations at this point. This was initially removed in https://github.com/PX4/PX4-Autopilot/pull/12025, but not for nested types. This was now removed from the \`get\_children\_fields()\` functions as well. > > \*\*Describe possible alternatives\*\* > 1. Not a reasonable solution, but still a solution: order all our msg fields in a more bandwidth optimized way. This would result in IDL files that would be common for both DDS and ROS 2 usage, and we would keep the same structure in uORB and IDL. > 2. Use \`eprosima::fastcdr::FastCdr\` instead of \`eprosima::fastcdr::Cdr\` in the agent side for disabling alignment, while looking for a clean way of doing the same in Micro-CDR (without hacking through it). The only concern here is that even though we might minimize the bandwidth consumption, this will result in an higher CPU usage due to not-aligned memory access when dealing with buffers. > > Both solutions would require some trade study and measurements to understand which one fits our needs better. In the end, these could also be made as options to people exploring the tradeoffs in different ways. > > \*\*Test data / coverage\*\* > Resulting \`serialize\_position\_setpoint()\` and \`serialize\_position\_setpoint\_triplet()\` were compared for confirmation of the correct field ordering. > > \*\*Additional context\*\* > \[PX4 Slack discussion\](https://px4.slack.com/archives/C7MTU2K17/p1606408558220300). Example to directly use PX4 offboard from ROS2, works as expected, can still be improved > > > > \*\*Describe problem solved by this pull request\*\* > \`typemask\` in the \`SET\_TARGET\_…POSITION\_LOCAL\_NED\` message is used as a tool to control the behavior of tracking a setpoint in offboard mode. However, the typemasks that are used in PX4 include more typemasks than defined in the mavlink spec. This is confusing to identify since the typemasks are written as numbers directly in the code. > > \*\*Describe your solution\*\* > This uses enums of the mavlink \`POSITION\_TARGET\_TYPEMASK\` in order to state type masks that are part of the mavlink spec more explicitly > > \*\*Additional Context\*\* > By doing this, I noticed that we have \`ignore\_alt\_hold\` which I believe will never get active. Does anybody have ideas on why this type mask exists? Do we want to keep it? > \`\`\` > offboard\_control\_mode.ignore\_alt\_hold = (bool)(set\_position\_target\_local\_ned.type\_mask & 0x4); > \`\`\` ### UAVCAN There’s new support on legacy UAVCAN 0.9 for safety buttons and buzzer and LED. So the full GPS module use case is done by CUAV. Jacob Carbill wants to discuss what comes next in UAVCAN 1.0 integration. There’s a dedicated call and the next on is next week. See [Dronecode Calendar – Dronecode Foundation](https://www.dronecode.org/calendar/) ### Hardware Workgroups > [@Hardware/Pixhawk Dev Call: Dec 01, 2020](https://discuss.px4.io/t/hardware-pixhawk-dev-call-dec-01-2020/19753): > > Dec 01, 2020 Call Moderators@rroche @JingerZAgenda Items FMUv5X - productization update by Holybro @Vincentpoont2FMUv6 update by Andrew Smith, Gumstix FMUv6X proposal and update by CUAV (Jinger) PX4 96boards Mezzanine board (Sahaj) Dail In Direct link to the meeting: Who’s on the call Jinger Zeng (Dronecode) Ramon Roche (Dronecode) Lorenz Meier (Auterion) Daniel Agar (PX4) David Sidrane (PX4) Sahaj Sarup (Linaro / 96Boards) Andrew Smith (Gumstix) Alex Klimaj (Ark Electronics) Vince… * * * ## Release Need for 1.12 release with events interface and multi-ekf. What’s the stability state of master? We can tag a 1.12 alpha and start release testing. We need to go through typical hardware setups because there was some feedback on the 1.11 release with hardware support issues. **Please use master and make sure to report the issues you face with your hardware and perspective!** ## Community Q&A - @compasi Needs review on his pr to enable the tilted camera to save survey rows because of larger fov. The MAVLink message was accepted. It was tested in simulation, video and log would help. > > > \*\*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. - Mark S: Flew master just days ago (good feedback) and converted logs from ulg to csv and is wondering about how to get Euler angles from the logged quaternions. Should we enable euler angle conversion when converting ulgs in the Python library? ## In-Depth discussions * * * ## 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:** [December 2, 2020, 1:04pm UTC](https://discuss.px4.io/t/px4-dev-call-december-02-2020/19763/2 "2020-12-02T13:04:43Z")
I would appreciate if we could add this PR to the dev-call: >