# avoid a timeout race condition where ArduPilot re-requests a
# fence point before we receive and respond to the first one.
# Since ArduPilot has a 1s timeout on re-requesting, This only
# requires a round-trip delay of 1/speedup seconds to trigger
# - and that has been seen in practise on Travis
AT-0417.0: Sending item with seq=0
AT-0417.2: Got (MISSION_REQUEST {target_system : 243, target_component : 250, seq : 0, mission_type : 1})
AT-0417.2: Got (MISSION_REQUEST {target_system : 243, target_component : 250, seq : 0, mission_type : 1})
AT-0417.2: Exception caught: Traceback (most recent call last):
File "/home/travis/build/ArduPilot/ardupilot/Tools/autotest/common.py", line 3950, in run_one_test
test_function()
File "/home/travis/build/ArduPilot/ardupilot/Tools/autotest/rover.py", line 4216, in test_poly_fence
self.test_fence_upload_timeouts()
File "/home/travis/build/ArduPilot/ardupilot/Tools/autotest/rover.py", line 4057, in test_fence_upload_timeouts
target_component=target_component)
File "/home/travis/build/ArduPilot/ardupilot/Tools/autotest/rover.py", line 4010, in test_fence_upload_timeouts_2
self.expect_request_for_item(item)
File "/home/travis/build/ArduPilot/ardupilot/Tools/autotest/rover.py", line 3958, in expect_request_for_item
raise NotAchievedException("Expected request for seq=%u" % item.seq)
NotAchievedException: Expected request for seq=1
The "AT" timestamps there are wallclock time. Since speedup for Rover
is 8 by default, that could be as much as 1.6 seconds meaning a
re-request from ArduPilot would be legitimate.
I've added some debug, too - we now emit "Sending item with seq=1"
between those two "Got" lines. That should make the problem clearer -
we've received a re-request rather than a request for the item after the
one we've already sent.
includes the following changes
winch_update called at 50hz
removed ability to set winch rate from ch6 tuning
remove wheel encoder
call winch library to log at 10hz
fix winch param prefix
includes the following changes
move WINCH_ENABLED to library
add singleton
add pre_arm_check
backend gets init_input_and_output and read_pilot_desired_rate
remove use of wheel encoder
rename servo-with-encoder to just servo
add write_log
rename control_mode
add rc input processing
add acceleration limiting
this allows for RC inputs to be ignored at low throttle, but won't
trigger failsafe. It is meant for users flying BVLOS missions, where
they want GCS failsafe enabled, but don't want RC failsafe, and want
to be sure that RC inputs will be ignored at low RC throttle values
Thanks to suggestion from Pompecukor
[451/678] Compiling libraries/AP_Terrain/TerrainIO.cpp
../../libraries/AP_Terrain/TerrainIO.cpp: In member function ‘void AP_Terrain::open_file()’:
../../libraries/AP_Terrain/TerrainIO.cpp:167:35: error: ‘.DAT’ directive output may be truncated writing 4 bytes into a region of size between 2 and 5 [-Werror=format-truncation=]
167 | snprintf(p, 13, "/%c%02u%c%03u.DAT",
| ^~~~
compilation terminated due to -Wfatal-errors.
climr
chobits
Randy Mackay
Josh Welsh
Isaac Ault
Peter Barker
Alexey Bulatov
Michael du Breuil
Iampete1
Patrick José Pereira
mhefny
Tsuyoshi Kawamura
Andrew Tridgell