Main UAVCAN protocol handling and ESC updates run on the same thread/wq as
before. There are 2 WorkItems for separate scheduling of the 2, so that
ESC updates run in sync with actuator_control updates. UAVCAN is scheduled
at a fixed rate of 3ms (previously the poll timeout) and on each UAVCAN
bus event.
This leads to roughly the same behavior as before. CPU & RAM usage are
pretty much the same (tested on Pixhawk 4).
Testing done: Motors still work (with feedback), param changes and a
UAVCAN optical flow sensor.
esc_setpoint in UAVCAN was just wrong, this is what it really is:
uint7 power_rating_pct # Instant demand factor in percent
(percent of maximum power); range 0% to 127%.
Currently actuator offboard control interferes with SITL lockstep.
Therefore, the least we can do is to warn a user and inform them how to
workaround the issue.
* PreFlightCheck: remove unused reportFailures flag
* Commander: pull all pre flight checks together on the PreFlightCheck class
* PreFlightCheck: separate checks into their own files
This fixes the case where the mixer_module would subscribe and use its
own test_motor publication which was created only to make sure the
topic is advertised and subsequent updates will work properly.
This happened in SITL lockstep because the timestamp would be 0 at the
very beginning, and hence elapsed time would be 0 as well.
This lead to an actuator publication which would then get lockstep out
of sync causing poll errors on the Gazebo side.
The plot of the attitude setpoint in the log did not show any values
because the message timestamp that the position control module sets
was overwritten by the PositionControl attitude generation.
by applying it directly to the attitude setpoint which is the output of
the position controller.
The problem was that before the input to the attitude setpoint generation
was adjusted to generate a level attitude with zero thrust keeping the
heading. I refactored the PositionControl class in #13262 to directly
generate the attitude setpoint output. So here I'm adjusting the attitude
setpoint to do the exact same thing as before but without interleaving
with the PositionControl logic.
getLockGuard relies on copy elision to work correctly, which the compiler
is not required to do (only with C++17).
If no copy elision happens, the mutex ends up being unlocked twice, and the
CS is executed with the mutex unlocked.
The patch also ensures that the same pattern cannot be used again.
This fixes the battery failsafe for the following corner cases:
- Battery failsafe set to Return but we can't do RTL because we don't
have a global position or home position. In this case we now switch to
Land. Land might end up in Descend in the failsafe state machine
later.
- Battery failsafe set to Land but we can't land because we don't have a
local position. In this case we switch to land anyway and then fall
back to descend in the failsafe state machine later.
The "fix" involves ignoring using the main_state_transition and
implementing the guards in place. This is a hack for now but should
cover the corner case until a more thorough refactor.
The different failsafe state machines have involved over time from
requirements and learnings based on developed solutions and products.
The implementations in various places will need to get consolidated in
the future.
Tested in SITL for Return and Land with and without GPS.
* Use position instead of last setpoint
This calculates the target velocities better taking into account disturbances along
the flight route. Previously entry angles and more were calculated assuming the flight path
originates directly from the direction of the previous waypoint. This corrects this assumption
to instead make the direction come from the vehicle location.
* Allow to specify a final speed given a braking distance.
This is to allow planning to not stop at a waypoint, but instead
to reach the waypoint while maintaining a certain velocity
* Updated src/lib/matrix
* Account for speed at target when determining constraints
* Separate constraints into x/y components
* Use setpoint position, not vehicle position
* Fix whitespace, add documentation
This should fix spikes in the mag data on MPU9250 found inside Drotek
Pixhawk 3Pro.
The problem turned out to be that we are not checking the DRDY bit
before reading the data. We presumably threw away most of the stale data
by doing a duplicate check, however, sometimes we might have run into a
race where the mag data was already being updated in the chip while
still being read.
* Draco-R sensor orientation correction
* LL40LS sensor is not stable during I2C probing. More trials have been implemented.
* px4flow execution has been removed as rc script already running it
* GPS LED script repaired
* Off ICM20608 due to some bug?
* Removed i2c speed adjustment due to SMBUS.
* ms5611 test2 does not exist
* Baud rate has changed.
* Draco-R airframe parameters are updated.
* IFO and Draco parameters are updated
* Draco-R sensor orientation corrected
* Draco-R DSHOT supports
When flying POSCTL and ALTCTL the throttle stick is usually spring
loaded and therefore centered. Therefore, it makes more sense to check
for above center instead of above low.
PX4 BuildBot