the timing table was not correct, thanks to APD for pointing this out.
This is recalculated from
https://www.kvaser.com/support/calculators/can-fd-bit-timing-calculator,
with transmitter timing delay compensation added and tested with Salae
captures to ensure we are getting the right bit rates
if safety is on and you force arm them turn safety off then Q modes
cannot run the motors as the AP_Motors armed state will still be off.
This ensures that the motors are armed immediately we arm. This
matches what copter does when arming with safety on
when we load a VARPTR subtree we need to re-scan the parameter
defaults file from @ROMFS/defaults.parm in case there are defaults
applicable to this subtree
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
rishabsingh3003
Andrew Tridgell
Andy Piper
bugobliterator
Iampete1
yjuav
Randy Mackay
David O'Connor
Peter Barker
Hayden Donald