Co-authored-by: Dr.-Ing. Amilcar do Carmo Lucas <amilcar.lucas@iav.de>
tidy message sending using templates
Calculate and enforce the minimum update period.
Disable unused features to save flash
forced time gaps between all transmits
correct ESC reset functionality
Avoid re-initialization repeatition
Make sure we stop FETtec if safety is on (ignore reverse) this reduces duplicated code
Error count calculation changed
as the telemetry error count is absolute only the overflow status can be safed and used for the percentage calculation
Update the README to add autotests information
FETtec needs a time gap between frames
This allows running at high fast_loop_rates
do not send fast_throttle data if a configuration command just got sent
Example parameter configuration file is for a Quadcopter with ESCs connected to Telem2
remove two FIXME
fix compilation in master
Fix the ESC not re-initializing issue.
Now we re-init whenever we loose connection
RVMASK parameter changes only take effect when not armed
Improve documentation
Always use the same wording when referring to fast-throttle commands
fix pre-arm check message
assure the length of the memmove is positive
Set HAL_AP_FETTEC_CONFIGURE_ESCS to 0 when no ESC hardware is available and you want to test the UART send function
make sure the SERVO_FWT_MASK is valid:
- it can have bit gaps between active channels, but channels higher than 12 are not allowed (AP_EST_TELEM limitation)
- Explain that the FETtec ESC IDs inside the FETtec Firmware need to be contiguous and start at 1.
add tests for ESC power outages
add test that safety switch zeroes PWM for FETtec ESC
This reverts commit 540a56adb8.
Polling this message caused issues on reboot - shouldn't be a problem
but is.
Retrying that showed that the Tracker GUIDED test failed reliably due to
a yaw problem.
From Andy:
Can you make this 0. The test should then pass. I'm not terribly happy about it but its better than disabling the test and I can't tell whether there is actually a problem or not.
We end up where we started, so when we start to play the mission back we
might immediately be at the first waypoint. That's a problem as we may
never see the NAV_CONTROLLER_OUTPUT mention waypoint 1 and thus we
fail the test
We're now waiting for the vehicle simulation to provide us a heartbeat
for a non-generic frame before considering it good to fly.
Unfortunately, Copter relies on the parameter file to tell it which
frame to use - and we don't apply parameters from parameter files until
after we've checked the heartbeat.
Passing the file into ArduPilot on the commandline means we don't have
this problem.
This was still relying on heartbeats coming from MAVProxy. As speedup
increased those heartbeats may not come fast enough - and they really
should be coming from autotest as that's who's doing the commanding.
autotest: set SYSID_MYGCS in AFS test
autotest: set SYSID_MYGCS before setGCSfailsafe
Stop setting MAVProxy stream rates; these are neither here-nor-there now as MAVProxy will only modify its own connection's streamrates now
Stop doing the set-streamrate dance to work around MAVProxy's
set_streamrate algorithms.
Remove useless and misleading set of streamrate in Plane test; we reset
streamrates on the reboot immediately following this set. Considering
the streamrate was never eset this was a good thing.
This appears to be another case of the fence state carrying over from one test to another. Disabling the fence at the end of the test appears to have fixed this problem
Adds tests for:
* Testing auto-enable disabled (when no autoenabling of the fence is required)
* Test auto-enabled always after takeoff (when takeoff complete condition met)
* Test auto-enabled disable floor only (when land sequence begins)
* Test auto- on arm/disarm (when vehicle is armed/disarmed)
* Tests ability to land when fence is breached
Adds corrections to enabling fence using aux function.
Correctly test fences statically. Only uploaded fences can be checked using a fence file, so we check those first. Then we add steps to check tin can, max and minm all set the fence as present, as expected.
Plane will support MAV_PROTOCOL_CAPABILITY_MISSION_FENCE, so we assert that it does support it.
To test ceiling and floor, leverage some existing functions for takeoff, change altitude and land. Check for respective breach.
Add a floor breach check to copter.