f0482935cc
# 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.
|
||
|---|---|---|
| .azure | ||
| .github | ||
| AntennaTracker | ||
| ArduCopter | ||
| ArduPlane | ||
| ArduSub | ||
| benchmarks | ||
| docs | ||
| libraries | ||
| mk | ||
| modules | ||
| Rover | ||
| tests | ||
| Tools | ||
| .dir-locals.el | ||
| .dockerignore | ||
| .editorconfig | ||
| .flake8 | ||
| .gitattributes | ||
| .gitignore | ||
| .gitmodules | ||
| .pydevproject | ||
| .travis.yml | ||
| .valgrind-suppressions | ||
| .valgrindrc | ||
| appveyor.yml | ||
| BUILD.md | ||
| COPYING.txt | ||
| Dockerfile | ||
| Doxyfile.in | ||
| Makefile | ||
| README.md | ||
| Vagrantfile | ||
| waf | ||
| wscript | ||
ArduPilot Project
Ardupilot is the most advanced, full-featured and reliable open source autopilot software available. It has been under development since 2010 by a team of diverse professional engineers and computer scientists. It is the only autopilot software capable of controlling almost any vehicle system imaginable, from conventional airplanes, multirotors, and helicopters, to boats and even submarines. And now being expanded to feature support for new emerging vehicle types such as quad-planes and compound helicopters.
The ArduPilot project is made up of:
User Support & Discussion Forums
-
Support Forum: https://discuss.ardupilot.org/
-
Community Site: https://ardupilot.org
Developer Information
-
Github repository: https://github.com/ArduPilot/ardupilot
-
Main developer wiki: https://ardupilot.org/dev/
-
Developer discussion: https://discuss.ardupilot.org
-
Developer chat: https://gitter.im/ArduPilot/ardupilot
Top Contributors
- Flight code contributors
- Wiki contributors
- Most active support forum users
- Partners who contribute financially
How To Get Involved
-
The ArduPilot project is open source and we encourage participation and code contributions: guidelines for contributors to the ardupilot codebase
-
We have an active group of Beta Testers especially for ArduCopter to help us find bugs: release procedures
-
Desired Enhancements and Bugs can be posted to the issues list.
-
Help other users with log analysis in the support forums
-
Improve the wiki and chat with other wiki editors on Gitter
-
Contact the developers on one of the communication channels
License
The ArduPilot project is licensed under the GNU General Public License, version 3.
Maintainers
Ardupilot is comprised of several parts, vehicles and boards. The list below contains the people that regularly contribute to the project and are responsible for reviewing patches on their specific area. See also the list of developers with merge rights.
- Andrew Tridgell:
- Vehicle: Plane, AntennaTracker
- Board: APM1, APM2, Pixhawk, Pixhawk2, PixRacer
- Francisco Ferreira:
- Bug Master
- Grant Morphett:
- Vehicle: Rover
- Jacob Walser:
- Vehicle: Sub
- Lucas De Marchi:
- Subsystem: Linux
- Michael du Breuil:
- Subsystem: Batteries
- Subsystem: GPS
- Subsystem: Scripting
- Peter Barker:
- Subsystem: DataFlash, Tools
- Randy Mackay:
- Vehicle: Copter, Rover, AntennaTracker
- Tom Pittenger:
- Vehicle: Plane
- Bill Geyer:
- Vehicle: TradHeli
- Chris Olson:
- Vehicle: TradHeli
- Emile Castelnuovo:
- Board: VRBrain
- Eugene Shamaev:
- Subsystem: CAN bus
- Subsystem: UAVCAN
- Georgii Staroselskii:
- Board: NavIO
- Gustavo José de Sousa:
- Subsystem: Build system
- Julien Beraud:
- Board: Bebop & Bebop 2
- Leonard Hall:
- Subsystem: Copter attitude control and navigation
- Matt Lawrence:
- Vehicle: 3DR Solo & Solo based vehicles
- Matthias Badaire:
- Subsystem: FRSky
- Mirko Denecke:
- Board: BBBmini, BeagleBone Blue, PocketPilot
- Paul Riseborough:
- Subsystem: AP_NavEKF2
- Subsystem: AP_NavEKF3
- Pierre Kancir:
- Subsystem: Copter SITL, Rover SITL
- Víctor Mayoral Vilches:
- Board: PXF, Erle-Brain 2, PXFmini
- Amilcar Lucas:
- Subsystem: Marvelmind
- Samuel Tabor:
- Subsystem: Soaring/Gliding