Status update by component/project
Roadmap, and Release discussion
Community Q&A
In-Depth discussions
This is the 3rd last dev call in 2020.
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.
PX4:master ← PX4:pr-mtd-mgr
opened 09:49PM - 16 Nov 20 UTC
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.
PX4:master ← PX4:pr-nuttx-next-pr-dhcp
opened 04:47PM - 15 Oct 20 UTC
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<space>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.
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, …
PX4:master ← smithandrewc:master
opened 09:21PM - 01 Dec 20 UTC
USB-HS (ULPI) support still outstanding.
New boardsupport for Pixracer Pro (H7 chip, not following fmu standard strictly)
PX4:master ← PX4:pr-mro_pixracer_pro
opened 12:49AM - 11 Oct 20 UTC
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.
Changes for new revision of NXP board
PX4:master ← PX4:nxp-revb
opened 09:41PM - 25 Nov 20 UTC
Changes from ringout for nxp_fmurt1062-v1
No updates
Events interface @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
PX4:main ← PX4:events_interface_prototyping_comp_info
opened 03:33PM - 27 Nov 20 UTC
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: <a href="https://docs.px4.io/master/en/config/firmware.html">documentation</a>
*
* <profile name="dev">
* This is only meant to be shown to developers.
* It might contain a parameter, like <param>COM_ARM_MAG_STR</param>, to disable a check.
* </profile>
* @arg1: a
* @arg2: b
* @arg3: f
*/
events::send<uint8_t, uint32_t, float>(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):
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
PX4:master ← PX4:pr-commander_switch_update
opened 03:31PM - 24 Nov 20 UTC
- 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
PX4:master ← PX4:commander_rm_lp_prio_thread
opened 07:56AM - 27 Nov 20 UTC
- 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
PX4:master ← PX4:pr-commander_static_state
opened 04:26PM - 01 Dec 20 UTC
Small logic change when takeoff is complete it switches to
PX4:master ← PX4:pr-commander_auto_takeoff_transition
opened 04:03PM - 01 Dec 20 UTC
- 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)
PX4:master ← PX4:pr-commander_auto_loiter_requirement
opened 04:08PM - 01 Dec 20 UTC
- 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
No updates
No updates
No updates
PX4:master ← PX4:pr-acceleration-setpoints
opened 09:02PM - 08 Sep 20 UTC
**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
- (AfterPR) With Acceleration feedforward setpoints: https://review.px4.io/plot_app?log=7515c5b1-bfc1-4026-9a11-8eabda5134c0
**Additional context**
- Acceleration feedforward control was added in https://github.com/PX4/Firmware/pull/14212, but was not functional for offboard control.
PX4:master ← PX4:acceleration-task-improvements
opened 03:05PM - 02 Dec 20 UTC
**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):
Brake from high velocity now starts like before but keeps more brake drag until the end:
@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.
PX4:main ← Pedro-Roque:pr-mc_ctl_muxing
opened 10:47PM - 24 Apr 20 UTC
**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.
PX4:master ← PX4:separate-flight-tasks
opened 12:52PM - 14 Apr 20 UTC
**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 takeoff is fixed and hence missions on rover work again.
PX4:master ← PX4:pr-handle-takeoff
opened 03:45PM - 28 Nov 20 UTC
**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.
Open DevRover CAD
No updates
No updates
No updates
There was some change required in serializing the datatypes to optimize for lowest bandwidth consumption. Review and documentation is still needed.
PX4:master ← PX4:pr-micrortps_fix_byte_ordering
opened 11:53AM - 28 Nov 20 UTC
**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
PX4:master ← mickey13:offboard-example
opened 05:02PM - 30 Nov 20 UTC
https://github.com/PX4/PX4-Autopilot/pull/16296
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
Dec 01, 2020
Call Moderators
@rroche @JingerZ
Agenda Items
FMUv5X - productization update by Holybro @Vincentpoont2
FMUv6 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…
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!
@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.
https://github.com/PX4/PX4-Autopilot/pull/15882
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?
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.
Rearchitecture improving checks and communication to the ground station