Works by scaling the _mix matrix in the pinv conntrol allocator. This is
architecturally a bit ugly, but I think is a reasonable solution
considering the alternatives and their drawbacks:
Current version (in rate control modules):
+ simple
- Relies on FW/VTOL proxy to determine which directions of
thrust/torque need battery scaling
- introduce battery scaled thrust / torque commands that are not
physical thrust and torque but
Also modifying the torque / thrust setpoint like currently but inside of
the allocator (this one could actually reasonably work as well,
consider)
+ minimal functional change w.r.t. before, addresses the issue of
confusing scaled and unscaled torque/thrust setpoints
- FW/VTOL distinction gets hairier.
- Currently we have separate scaling implementations for MC (->
scale all thrust and torque commands, reasonably assuming that
all rotors are driven by the same battery) and FW (-> scale only
forward thrust). If we move it into the allocator,
- In the allocator we get either one torque sp (MC or FW, from the
rate controllers) or two (VTOL, from VTOL attitude controller).
In the VTOL case, we have 0 = MC and 1 = FW. To replicate the
previous logic, we have to separate these setpoints again into
clear MC and FW components.
Instead modifying the effectiveness matrix through
ActuatorEffectivenessRotors
+ VERY clean and physically consistent, the scale enters by modifying
the thrust coefficient, 1:1 modelling the decreased effectiveness of
the rotor in both thrust and torque, in one single place
- Does not work because the normalizeControlAllocationMatrix reverts
the scaling effect that entered through the effectivenss matrix.
Getting it to work would require reworking this scaling from the
ground up or removing it entirely
Modifying only the motor outputs after the allocator
+ again very simple, does not care about FW/VTOL, we just do it for all
the rotors
- Introduces wrong actuator limits: Allocator assumes that rotors
saturate based on a model unaware of battery scale, but because after
the allocator we scale (increase) the commands, the actual saturation
happens earlier.
* uavcan esc: remove unused includes
* uavcan arming_status: disarm when terminated
To stay consistent with kill.
* uavcan: publish armed during actuator tests to make it possible spinning motors
* feat: added driver for tmp102 temperature sensor
* style: removed new line
* style: adjusted date in header
* style: removed duplicated logging
* fix: moved start-up command from rc.board_sensors to rc.sensors
* style: used consexpr for expected config reg value
* feat: added retry logic to probe function
* style: added _ as prefix to global variable
* style: used make format
* fix: corrected temperature calculation
* fix: mask AL-bit in probe function
* style: removed header files from CMakeLists
* style: used correct english in comments
* refactor: return error right after failure
* style: moved init call to correct place
* fix: corrected temperature calculation (again)
* refactor: removed _curr_pr variable => always have to set PR to desired register on read
* fix: add multi logged topic
* FwLateralLongitudinalControl: publish uknown flight phase if TECS not running
* FwLateralLongitudinalControl: publish flight phase with lower rate
For this we store the new flight phase in a local variable, which is
returned by tecs_update_pitch_throttle (but initialised outside to
unknown in case TECS does not run).
* rover_mecanum: enable yaw control via MAVLink SET_POSITION_TARGET commands
* Maintain the original judgment conditions
---------
Co-authored-by: V <null>
The first test makes sure the user can take over when an RTL failsafe was triggered but degraded to a Land.
The second test rules out the easiest fix of removing the condition `_selected_action == selected_action` which causes the problem for test one but is there for a reason.
When position control is disabled, clear the setpoint properly to prevent stale values. This fixes a bug where switching to position mode in the same control loop as a hover thrust estimate update could fill up the velocity integrator.
I don't think we should change the logging profile based on the type of
airframe configured. Instead, this is an option you set based on the
phase of development/testing you're in.
This came up because the KakuteH7v2 which is 4050 by default would log
excessively which is not a good idea with only 128 MB flash storage.
* FwLateralLongitudinalControl: publish flight phase
* FwLateralLongitudinalControl: consolidate hrt_absolute_time calls
* FwLateralLongitudinalControl: Name time variables correctly
* FwLateralLongitudinalControl: pass current time as argument rather than class member
* FwLateralLongitudinalControl: use local position timestamp
Replaces the legacy pure-Python lookup table CRC32 implementation with the built-in `zlib.crc32`.
The previous implementation relied on a manual loop over bytes, which was inefficient for large firmware files (taking ~0.5s for 2MB on modern CPUs). The new implementation reduces this to ~1ms.
Implementation details:
- Removed the hardcoded `crctab` array to clean up the code.
- Adjusted `zlib` initial state (0xFFFFFFFF) and final XOR operations to ensure bit-perfect compatibility with the specific CRC32 variant expected by the PX4 bootloader.
Benchmark (2MB firmware):
- Legacy: ~0.48s
- zlib: ~0.001s
This prevents PX4 from sending out the GPS_GLOBAL_ORIGIN message
immediately when a SET_GPS_GLOBAL_ORIGIN message arrives.
Instead, we apply the new origin in the EKF, and only then send out
the new origin, which is much more intuitive and doesn't confuse a user
of the API.
* init: working towards dual-action ATMOS
* fix: update gz sim to latest
* fix: add motor number max fitting Actuator
* fix: revert non-necessary changes
* fix: ensure esc count does not exceed maximum number of ESCs
* feat: update gz to latest, includes ATMOS dual action
* fix: restore dds_topics
* fix: update gazebo model commit
Balduin