No need to repeat the same comments on 3 different places. Instead add a
single comment to explain how start_measurements() and read_raw() are
related.
Don't use a state machine in AK8963: the start_measurements() method
should be called only once. Even if there's a magnetic sensor overflow
the only thing we should do is to discard the new data.
This also moves the _collect_samples() method to be inside _update()
since it's the only place it should be called from, the one running on
the timer thread.
We need to check the AK8963's id before anything else Here we are
reordering the calls to _calibrate() and _check_id(). After that we
don't need to read and write again the AK8963_CNTL1 register.
While at it do some renames as well:
- _configure() -> _setup_mode(): since now there's a
_bus->configure() it became confusing what actually it's
doing.
- make error messages say what we were actually trying to do but
couldn't. Also remove PSTR since this is linux-only.
- start_conversion() -> start_measurements(): We are instructing the
bus to start to get the samples, not to tell the chip to start an
analog->digital conversion like in other sensors.
The MPUREG_PWR_MGMT_1 defines were used when we cared about the MPU9250
initialization code. Now all initialization is done by the MPU9250 class
itself, so remove these defines.
Also remove AK8983_SELFTEST_MAGNETIC_FIELD_ON that is never used and let
the defines always with 2 bytes to improve readability.
Similar code was added in the read_raw() implementation for each bus.
Add a new POD struct read_raw to contain the registers from the AK8963
and use it instead as argument.
DMA is getting stopped in the separate method now. This is the best we
can get at the current time. It does yield slightly better experience
and works in the majority of cases.
The patch is a no bulletproof solution, though.
There's a possibility of corruption in case of e.g. a SIGKILL. There's
no signal framework at the time and the commit doesn't add one. That's
why all signals are handled in the same erroneous way. This is not a
good nor a final solution to the issue.
For the issue at hand a better fix might be porting the code to kernel
space but it's a rather tediuos task that we cannot undertake in the
couple of weeks.
The issue has already come up. There's no deinitialization mechanisms at the moment. As APM is rather software than firmware on Linux, there're some clean-up work that needs to be done. This commit triggers deinitialization of RCInput on a panic.
Add a deinit() counterpart. This is needed for some ports that require some deinitializtion logic. The default implementation is empty. I'm not sure whether we need to inforce it for all.
Ublox 7 and 8 seires use a UBX-CFG-GNSS message to enable satellite constellations. The default value does not enable any additional ones, and any constellations the reciever doesn't report knowing about are not configured.
Remove race condition on sending intial blob to the GPS, it was possible to send a blob that got the GPS configured enough to allow the autodetect to take over (and then some drivers like ublox would not finish sending the blob, which has potential details that the driver might have needed to send)
Limit the delay to checking for NMEA gps to only checking after all the available baud rates have been checked
Since a UBlox will actually report having DGPS (due to SBAS or RTCM data) actually report this as the highest supported mode
The symptom was that if the very first command in the mission was a
do-command, it would be run after every nav-command that didn't have
another do-command before it.
Now that the initialization of MPU9250 is shared between the
AP_InertialSensor and other drivers using it as a backend, we can reset
the MPU9250 in order to put it in a known state.
Now we have the initialization code split in 2 parts:
1) Making sure the MPU9250 chip is alive and working: this is now in a
static function that may be called by other drivers that use MPU9250 as
backend.
2) The configuration of gyro and accel. Once the first part is completed
successfully the AP_InertialSensor_MPU9250 finishes the configuration of
the sensors it uses.
The only change in behavior here is that before we would try 25 time (5x
inside _hardware_init time 5x inside _init_sensor() that calls the first
function) to "boot the chip" and now we are doing "only" 5.
Add static methods to do the SPI transactions and provide the wrapper
methods when we have an instance of the object. This is useful so these
methods can be called from other contexts when the AP_InertialSensor
hasn't been initialized yet.
Allowing to change the SPI device state allows us to save the
information whether the device was already initialized and avoid 2
separate drivers to initialize it.
Uses reimplemented AK8963 driver. There's also no need trying to detect this
compass twice. Actually, it might even be bad, because the current code can
allocate an AK8963 object twice.
If a badly conditioned covariance matrix causes negative innovation variances, then the filter will diverge. The previous approach of increasing process noise was not effective in some cases, so a hard reset of the covariance matrix has been adopted to guarantee recovery.
This fixes a numerical error observed using the replay on flight log which had significant periods of compass rejection.
The Compass library is initialized before the InertialSensor. AK8963 with
MPU9250 as backend already takes care of resetting MPU9250. The problem with
also resetting it in the MPU9250 initialization code is that if the reset
happens during an internal I2C transaction, the AK8963 may hang. So here we
remove the reset inside MPU9250. There still a possibility that the first
MPU9250 initialization is not successful and it resets the chip, but it's not
happening in tests.
new param: BRD_SERIAL_NUM
// @Description: User-defined serial number of this vehicle, it can be any arbitrary number you want and has no effect on the autopilot
// @Range: -32767 to 32768 (any 16bit signed number)
The value for LINUX_STORAGE_SIZE was defined inconsistently against the one
defined for Linux boards in HAL_STORAGE_SIZE. That led to some values not
being written to the storage when running the test binary built at
libraries/StorageManager/examples/StorageTest.
As we intend to eventually get board related parameters from a configuration
file, this commit makes the GPIO numbers for data-ready pins be instance
variables instead of from C constant macros.
Another advantage of using instance variables in this context is the
possibility of using more than one LSM9DS0.
If the data-ready polling is done entirely on GPIO pins, it isn't necessary to
hold the semaphore before we now we have data to consume. In that case, only
take the SPI semaphore if there's new data available.
On the other hand, if at least one SPI transaction is done in order to check
for new data, then it makes sense to take the semaphore beforehand.
This commit makes accel and gyro initialization routines use bitfield macros
instead of hardcoding the literal value when wrinting on registers. That is
less prone to typos and a lot of times self-explanatory. Also, due to the
latter, the long comments explaining each register field were removed (any
detail can be checked on the datasheet).
This adds the backend driver for LSM9DS0. This implementation is based on the
legacy driver coded by Víctor Mayoral Vilches (under folder LSM9DS0) and makes
some necessary adaptations and fixes in order to work properly. The legacy
driver folder was removed.
The calibration on LSM9DS0 was giving offsets between 4.0 and 4.2 on x-axis and
around 3.6 on y-axis. It turned out that those offsets were actually right.
The maximum absolute values of calibration offset should be a sensor
characteristic rather than a constant value for all sensors.
The constant value previously used (3.5 m/s/s for all axes) is set here as a
default maximum absolute calibration offset for every instance to keep it
working.
The device number in /dev may not be reliable from one boot to another
due to the initialization order of each bus.
For example, in Minnow Board Max, the exposed I2C buses may be i2c-7 and
i2c-8 or i2c-8 and i2c-9 depending if the platform driver in the kernel
is initialized before or after the PCI.
It also may change with different version and configuration of the DT or
UEFI used making another kernel driver to bind to the device. This means that
for Minnow Board Max we need to use something like below to pass to the
constructor:
static const char * const i2c_devpaths[] = {
/* UEFI with lpss set to ACPI */
"/devices/platform/80860F41:05",
/* UEFI with lpss set to PCI */
"/devices/pci0000:00/0000:00:18.6",
NULL
};
The devpath here is the one returned by udev with the following command:
udevadm info -q path /dev/<i2c-device>
In contrary to the device number in /dev/i2c-N, this path in sysfs is
stable across reboots and can only change if there's a change in the
UEFI firmware or the board's device tree.
This patch assumes the currently supported boards don't have this
problem so it's not touching them.
Jean-Baptiste Dubois
Andrew Tridgell
Lucas De Marchi
Staroselskii Georgii
dgrat
Randy Mackay
Tom Pittenger
Vladislav Zakharov
Michael du Breuil
Arthur Benemann
Robert Lefebvre
Peter Barker
Julien BERAUD
John Hsu
Andy Piper
Paul Riseborough
mirkix
kozinalexey
dzollo
tcr3dr
Gustavo Jose de Sousa
Víctor Mayoral Vilches