* remove unnecessary nullptr check, these are always called from an
initialized AP_DroneCAN so if it's nullptr something has gone
horrifically wrong
* pass in driver index instead of repeatedly calling function to get it
* simplify error handling; knowing exactly which allocation failed is not
super helpful and one failing likely means subsequent ones will too,
as it can only fail due to being out of memory
* remove unnecessary nullptr check, these are always called from an
initialized AP_DroneCAN so if it's nullptr something has gone
horrifically wrong
* pass in driver index instead of repeatedly calling function to get it
* simplify error handling; knowing exactly which allocation failed is not
super helpful and one failing likely means subsequent ones will too,
as it can only fail due to being out of memory
* remove unnecessary nullptr check, these are always called from an
initialized AP_DroneCAN so if it's nullptr something has gone
horrifically wrong
* pass in driver index instead of repeatedly calling function to get it
* simplify error handling; knowing exactly which allocation failed is not
super helpful and one failing likely means subsequent ones will too,
as it can only fail due to being out of memory
* remove unnecessary nullptr check, these are always called from an
initialized AP_DroneCAN so if it's nullptr something has gone
horrifically wrong
* pass in driver index instead of repeatedly calling function to get it
* simplify error handling; knowing exactly which allocation failed is not
super helpful and one failing likely means subsequent ones will too,
as it can only fail due to being out of memory
* remove unnecessary nullptr check, these are always called from an
initialized AP_DroneCAN so if it's nullptr something has gone
horrifically wrong
* pass in driver index instead of repeatedly calling function to get it
* simplify error handling; knowing exactly which allocation failed is not
super helpful and one failing likely means subsequent ones will too,
as it can only fail due to being out of memory
* remove unnecessary nullptr check, these are always called from an
initialized AP_DroneCAN so if it's nullptr something has gone
horrifically wrong
* pass in driver index instead of repeatedly calling function to get it
* simplify error handling; knowing exactly which allocation failed is not
super helpful and one failing likely means subsequent ones will too,
as it can only fail due to being out of memory
* remove unnecessary nullptr check, these are always called from an
initialized AP_DroneCAN so if it's nullptr something has gone
horrifically wrong
* pass in driver index instead of repeatedly calling function to get it
* simplify error handling; knowing exactly which allocation failed is not
super helpful and one failing likely means subsequent ones will too,
as it can only fail due to being out of memory
* remove unnecessary nullptr check, these are always called from an
initialized AP_DroneCAN so if it's nullptr something has gone
horrifically wrong
* pass in driver index instead of repeatedly calling function to get it
* simplify error handling; knowing exactly which allocation failed is not
super helpful and one failing likely means subsequent ones will too,
as it can only fail due to being out of memory
* remove unnecessary nullptr check, these are always called from an
initialized AP_DroneCAN so if it's nullptr something has gone
horrifically wrong
* pass in driver index instead of repeatedly calling function to get it
* simplify error handling; knowing exactly which allocation failed is not
super helpful and one failing likely means subsequent ones will too,
as it can only fail due to being out of memory
* remove unnecessary nullptr check, these are always called from an
initialized AP_DroneCAN so if it's nullptr something has gone
horrifically wrong
* pass in driver index instead of repeatedly calling function to get it
* simplify error handling; knowing exactly which allocation failed is not
super helpful and one failing likely means subsequent ones will too,
as it can only fail due to being out of memory
* remove unnecessary nullptr check, these are always called from an
initialized AP_DroneCAN so if it's nullptr something has gone
horrifically wrong
* pass in driver index instead of repeatedly calling function to get it
* simplify error handling; knowing exactly which allocation failed is not
super helpful and one failing likely means subsequent ones will too,
as it can only fail due to being out of memory
* remove unnecessary nullptr check, these are always called from an
initialized AP_DroneCAN so if it's nullptr something has gone
horrifically wrong
* pass in driver index instead of repeatedly calling function to get it
* simplify error handling; knowing exactly which allocation failed is not
super helpful and one failing likely means subsequent ones will too,
as it can only fail due to being out of memory
* remove unnecessary nullptr check, these are always called from an
initialized AP_DroneCAN so if it's nullptr something has gone
horrifically wrong
* pass in driver index instead of repeatedly calling function to get it
* simplify error handling; knowing exactly which allocation failed is not
super helpful and one failing likely means subsequent ones will too,
as it can only fail due to being out of memory
* remove unnecessary nullptr check, these are always called from an
initialized AP_DroneCAN so if it's nullptr something has gone
horrifically wrong
* pass in driver index instead of repeatedly calling function to get it
* simplify error handling; knowing exactly which allocation failed is not
super helpful and one failing likely means subsequent ones will too,
as it can only fail due to being out of memory
this is the loop which ensures the amount of data sent to the mavlink client (usually Python) is limited - if we don't do this then we lose vast amounts of data when running at large speedups.
By attempting to process inbound data we may realise that the TCP connection has been dropped, and in that case we will start to listen for another connection.
This allows you to terminate the sim_vehicle.py MAVProxy and have it automagically restart (when running under GDB). This is very useful for testing MAVProxy patches with SITL; it's a different workflow to opening an output and connecting a new version of MAVProxy to that outout.
- correctly fill data-ready register
- adjust for different register configuration the driver shoves in
- correct WHOAMI register length
- correct 8-bit register reads in variable-length-register i2c simulation
In particular allows the use of the gimbal using PROTOCOL2 attached to a
DroneCAN bus. ArduPilot 4.6 is recommended due to the timeout bug causing
message sends to fail regularly on 4.5.
Tested also that misconfiguring the CAN bus will result in the driver
failing to start, though the error message will be less specific.
on H730 we are overflowing the ITCM area for SPRacingH7RF and other boards are not far behind.
Step away from the edge by removing this function which should never be in a fast path
AP_ADSB: uAvionix Transponder Status V3
+ Current version of ping200X sends the v1 status message periodically and the v3 status message in response to the transponder control message, so ardupilot needs to handle both gracefully; version 1 and version 3 are very different in structure and naively assuming one version over another will cause errors.
AP_ADSB: Process additional xpdr status v3 fields
AP_ADSB: Send GCS xpdr status at least every 10s
AP_ADSB: Send ping200X estimated HPL
+ When AP sends the ping200X the GPS data GDL90 message, it needs to provide a valid HPL for the ping200X to report a valid NIC.
AP_ADSB: Don't send unsolicited transponder status
AP_ADSB: Better initialization of xpdr id/config
AP_ADSB: Better initialization of frontend status
AP_ADSB: Suggestions from review
if a user has set CAN_D1_UC_ESC_RV which is the mask of ESCs that are
reversible we were sending -8191 when disarmed, which is full reverse
throttle. This is the correct output when armed as it is treated as
full reverse at "PWM" 1000 and stopped at 1500, but when disarmed we
should always send zero or the user may find all ESCs spin up at full
reverse when disarmed if the ESC supports reverse throttle (which is
rare in DroneCAN ESCs)
the rate of CAN servo messages is controlled by the servo. Having this
streaming means we can miss logging when there is more than one CAN
servo.
In the future we will move to holding the CAN servo data in a data
structure like we do for ESCs, and then log at a regular rate, but for
now this fixes the issue
projecting onto an infinite plane can cause exceptionally long rangefinder distances - for now jsut cap the distance that the simulated rangefinder can return to avoid floating point exceptions.
the FPE is caused in the Plane FlyEachFrame autotest when flying quadplane-copter_tailsitter - which ends up with a rangefinder at yaw-minus-180.
The timeout specified for auxiliary driver frames was passed to the
driver where a deadline was expected. The transmission was then started
after its "deadline", thereby causing it to be canceled and the data
lost if the frame could not be sent immediately.
Fix by converting the timeout to a deadline before passing to the
driver. The conversion is done in the Canard interface code as it
already does other conversions from timeouts to deadlines.
- Refactor and split set_pitch_max_limit method.
- New _update_pitch_limits to encapsulate all relevant functionality.
- Automatically reset if pitch and throttle are overriden.
- nullified TAKEOFF alt_dem offset on external throttle.
- Simplify use of TKOFF_THR_MIN.
- Prevent takeoff altitude overshoot by capping the altitude setpoint offset.
- Move pitch limits after vertical acceleration limitation.
this replaces the two booleans used to mediate TX and RX buffer
protection with mutexes.
The booleans were a hangover from the very early HAL_ChibiOS code, and
can lead to a deadlock. The sequence is as follows:
- a very high CAN bus bandwidth usage, triggered by MissionPlanner
requesting CAN_FORWARD on a CAN serial port. That causes a
"infinite" number of CAN_FRAME messages which saturates the bus,
and leads to the DroneCAN thread looping with no pause
- a serial port configured as GPS type AUTO, auto-probing for a GPS
that isn't there. This calls begin() periodically
- the UART TX thread assocated with that UART not making progress as
the TX thread priority is below the DroneCAN thread priority
- this causes the begin() in main thread waiting for _in_tx_timer to
loop forever, which triggers a watchdog
This is also from the older version of the generator.
Note that as documented, some of the equations have been removed and
rearranged slightly as it is assumed their terms are zero. Additionally,
the result is taken as the sum of the diagonal entries of the matrix.
It's from the older version of the generator as well.
Update variable names in the real code to be the same as the generated
code. Skip generation of the unused alternate form of the equations.
Delete `acc_bf_generated.cpp` as we know exactly how to generate it now.
Requires digging up old versions of the generator script.
The equations have been rearranged somewhat after generation to choose
the appropriate method but they do match overall. The auto-substitution
of the power functions caused slight changes to the generated syntax so
we make those to the real code as well.
Delete `yaw_generated.cpp` as we know exactly how to generate it now.
Validated that the generated code matches exactly the code in AP_NavEKF3
(except for the early exits).
Delete `covariance_generated.cpp` as we know exactly how to generate it
now (and it was out of date anyway).
Document exactly which versions were used when generating the code.
Sympy is the most important so it is explicitly checked.
Also add an alternate generate script which uses `nix-shell` to make it
convenient to automatically use these versions.
