the value nav_status.altitude_offset is expected to be a correction for differences between the barometers. The user calibrates this value with a MAV_CMD_PREFLIGHT_CALIBRATION call.
Without this patch we were passing in the raw barometric pressure values for the tracker and the tracked vehicle. It seems get_altitude_difference is expecting a sea-level pressure as its first argument now, as it subtracts the field elevation from the pressure-difference altitude calculations.
Change our call to provide a sea-level-adjusted value
this fixes an issue with resetting of parameters when going between
4.4.x and 4.5.x on MatekH743, and on any other board using flash
storage where the storage size has increased from 16k to 32k between
4.4.x and 4.5.x
The problem is that when you update to 4.5.x the parameter code stored
a backup of parameters in the StorageParamBak storage region which is
in the last section of storage. When you downgrade to 4.4.x the
AP_FlashStorage::load_sector() code tries to load this data and gets
an error as it is beyond the end of the available 16k storage. This
triggers an erase_all() and loss of parameters
our CANFD timings were resulting in a lot of busoff errors. Here is an
example of master at 1Mbit/5MBit:
Getting @SYS/can0_stats.txt as -
------- Clock Config -------
CAN_CLK_FREQ: 80MHz
Std Timings: bitrate=1000000 presc=7
sjw=0 bs1=7 bs2=0 sample_point=90.00000%
FD Timings: bitrate=5000000 presc=1
sjw=0 bs1=5 bs2=0 sample_point=90.00000%
------- CAN Interface Stats -------
tx_requests: 2689
tx_rejected: 0
tx_overflow: 443
tx_success: 7
tx_timedout: 2232
tx_abort: 0
rx_received: 18470
rx_overflow: 0
rx_errors: 0
num_busoff_err: 34439
num_events: 18477
ECR: F8
fdf_rx: 18467
fdf_tx_req: 2182
fdf_tx: 0
here is an example with the new timings:
------- Clock Config -------
CAN_CLK_FREQ: 80MHz
Std Timings: bitrate=1000000 presc=8
sjw=1 bs1=8 bs2=1 sample_point=90.00000%
FD Timings: bitrate=8000000 presc=2
sjw=3 bs1=8 bs2=3 sample_point=80.00000%
------- CAN Interface Stats -------
tx_requests: 3023
tx_rejected: 0
tx_overflow: 0
tx_success: 3023
tx_timedout: 0
tx_abort: 0
rx_received: 27865
rx_overflow: 0
rx_errors: 0
num_busoff_err: 0
num_events: 30888
ECR: 0
fdf_rx: 27862
fdf_tx_req: 3016
fdf_tx: 3016
I am testing between a CubeOrange and a Pixhawk6X. I tested 1, 2, 4, 5
and 8 MBit (which are the only valid FD bitrates in our parameters)
Many thanks to Kai from Salient Motion for finding this issue and
providing the corrected timing table
Adds special storage handling for loiter turns. Fractional Loiter
Turns 0<N<1 are stored by multiplying the turn number by 256, then
dividing that number by 256 on retrieval.
Adds special storage handling for loiter turns. Fractional Loiter
Turns 0<N<1 are stored by multiplying the turn number by 256, then
dividing that number by 256 on retrieval.
Adds special storage handling for loiter turns. Fractional Loiter
Turns 0<N<1 are stored by multiplying the turn number by 256, then
dividing that number by 256 on retrieval.
Adds special storage handling for loiter turns. Fractional Loiter
Turns 0<N<1 are stored by multiplying the turn number by 256, then
dividing that number by 256 on retrieval.
Adds special storage handling for loiter turns. Fractional Loiter
Turns 0<N<1 are stored by multiplying the turn number by 256, then
dividing that number by 256 on retrieval.
