The UART3 also have the I2C bus 2 functions so moving GPS to UART7 to
have one additional I2C.
To keep GPS working is also necessary update the FPGA RTL to version
0xC1 or higher.
Unsure what the underlying problem is, but the length of the first string in
the initilisation_blob increasing resulted in a race condition, waiting
longer before retrying the message resolves it, but we still need to identify
the underlying problem. This patch just results in the GPS working with current
configurations. Tested against AsteRx-M firmware 3.6.3
Reworked the process flow. Created the aviation vs rover themes.
Created visual operator feedback for prearm checks, GPS, EKF, gyro init,
radio failsafe, and low battery. This also includes work by Hugh Eaves
to open up the full extended properties of the Oreo LEDs. Not only are
far more functions available, but you can override and do custom things
via mavlink.
Jaime did the hard work on this one. He reworked notify device
selection to take place on init rather than on compile like before. The
notify decivces are mostly set on compile using preprocessor directives
based on board type. I created NTF_OREO_THEME. This will allow the
user to enable/disable the OreoLED driver. And it also allows you to
select between aircraft and rover lighting themes. This allows the Solo
to use the OreoLEDs, and doesn't waste the memory on vehicles not
equipped with Oreo LEDs. The OreoLED driver is restricted to Pixhawk 2
FCs by proprocessor directive due to memory constraints. So it will
never work by accident on another board.
There is also a new notify flag for GPS Fusion. This flag is true when
the EKF is happy with the GPS, actively using it for position
information.
Uses EKF filter state to set the new gps_fusion notify flag. This allows
the GCS and notify devices to specifically be notified if the GPS is or
is not usable.
Evaluated solo specific tones file vs standard px4 tones files. The
only thing the Solo had that standard ArduPilot does not have is the GPS
unplugged tone and the power off tone.
* Some tones have a different tune, which is fine. We want the Solo to
sound like ArduPilot if it is running ArduPilot.
* GPS unplugged tone abandoned. Determined to be unnecessary.
* Power off tone merged into standard px4 tones file. Smart battery
signalling a power off will make use of this tone. Has application for
any smart battery equipped vehicle, not just Solo.
* Removed all references and dependencies to `ToneAlarm_PX4_Solo.cpp`
and `ToneAlarm_PX4_Solo.h`
* Deleted `ToneAlarm_PX4_Solo.cpp` and `ToneAlarm_PX4_Solo.h` since
they're no longer needed.
Increase Roll, Pitch and Yaw IMAX from 0.444 or 0.222 to 0.5
Decrease Yaw Filter from 5hz to 2.5hz based on the results of autotunes on many vehicles which always seems to produce values between 2 and 3hz
getting to 60 was taking far too long (15 minutes or so). 45 is more
achievable.
This is a result of the fix to the invensense temperature detection
code
We are setting a termination handler for some signals which are of not
interest. Just ignore them. Ignoring SIGWINCH allows for example to
run on a screen and change the window size later without killing
ardupilot.
RPI-based boards that use RCInput_RPI need more stack space otherwise we
end up with stack corruption. This leads to crash particularly when also
using GPIO_RPI since it may change what that driver is poking on memory.
This increases stack size to 1M which is overkill for most of other
boards with a more controllable stack usage. However this exposes that
on multiple different HWs a single point for stack size decision may not
be the best. This can be improved in future.
Cache beacon positions to speed-up distance calculations
Only pass data to EKF after both hedgehog and beacon positions are known
Add license and credit Marvelmind
Re-order code around to minimize diff with upstream marvelmind code
Integrated review requests
This ensures that old yaw targets are not used in the short interval before they are initialised in advance_wp_target_along_track or advance_spline_along_track
On an invensense IMU with fast sampling we need to lower the slave
sample rate for slave sensors such as the built-in AK8963 compass on a
MPU9250.
The slave rate is set as a multiple of the main rate, so it needs to be
much lower for fast sampling. If we leave it high then it greatly
impacts on IMU sample rate.
Without this change a MPU9250 with fast sampling and a compass enabled
will give a gyro rate of around 7200Hz. With this change it gets 7760Hz
FIFO sensors produce data at a well known rate, but samples come in
bunches, so we can't use the system clock to calculate deltaT.
non-FIFO sensors produce data when we sample them, but that rate is
less regular due to timing jitter.
For FIFO sensors this changes makes us use a learned sample rate,
which allows for different clock speeds on sensor and system board.
For non-FIFO sensors we use the system clock to measure deltaT
the overall effect is a fix for sensors that produce samples at other
than the claimed datasheet rate.
