This fixes spuriously occuring mag spikes in the external mag of Here2.
The reason for the spikes was that the fact that the I2C registers were
not read out correctly as suggested in the datasheet.
Before we were reading out ST1, data, and ST2 in one pass and ignoring
the data ready bit (DRDY) in ST1. This meant that we could run into race
conditions where the data was not ready when we started reading and
being updated as the registers are read.
Instead, we need to check the read the ST1 register first to check the
data ready bit and then read the data and ST2 if the data is ready. By
reading ST2 we then trigger the next measurement in the chip.
Note: the author name was removed because this file has almost no
resemblence with the code written by that author 4 years ago, has been
copied to new places, and was initially commited without author anyway.
Also, my opinion is that the version control system should take care of
attribution, and not outdated comments.
- matrix in PX4/Firmware (c475bb84b7274d041065fc3fd673127ae2438f4d): 9f46483951
- matrix current upstream: 93d42947b6
- Changes: 9f46483951...93d42947b693d4294 2019-11-08 kritz - Add test for setting Quaternion to Identity (#104)
- GPSDrivers in PX4/Firmware (085bdd14b41ac3977d612a1cae27f111de7fe4fb): 011959b4da
- GPSDrivers current upstream: 085a85c48a
- Changes: 011959b4da...085a85c48a
085a85c 2019-10-15 Andreas Antener - sbf: invalidating gps position when invalid data is received We have encountered a case where do-not-use values were being reported in velocity fields without a corresponding error code or fix-type 0. This adds a check for known invalid data and sets the appropriate flags.
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.
Julian Oes
Oleg Kalachev
Daniel Agar
bazooka joe
xdwgood
PX4 BuildBot
Peter van der Perk
Beat Küng
LP
Jacob Dahl
Mike Wiatt
Tanja Baumann
JaeyoungLim
Matthias Grob