The device number in /dev may not be reliable from one boot to another due to the initialization order of each bus. For example, in Minnow Board Max, the exposed I2C buses may be i2c-7 and i2c-8 or i2c-8 and i2c-9 depending if the platform driver in the kernel is initialized before or after the PCI. It also may change with different version and configuration of the DT or UEFI used making another kernel driver to bind to the device. This means that for Minnow Board Max we need to use something like below to pass to the constructor: static const char * const i2c_devpaths[] = { /* UEFI with lpss set to ACPI */ "/devices/platform/80860F41:05", /* UEFI with lpss set to PCI */ "/devices/pci0000:00/0000:00:18.6", NULL }; The devpath here is the one returned by udev with the following command: udevadm info -q path /dev/<i2c-device> In contrary to the device number in /dev/i2c-N, this path in sysfs is stable across reboots and can only change if there's a change in the UEFI firmware or the board's device tree. This patch assumes the currently supported boards don't have this problem so it's not touching them. |
||
---|---|---|
AntennaTracker | ||
APMrover2 | ||
ArduCopter | ||
ArduPlane | ||
docs | ||
libraries | ||
mk | ||
modules | ||
Tools | ||
.editorconfig | ||
.gitattributes | ||
.gitignore | ||
.gitmodules | ||
.pydevproject | ||
.travis.yml | ||
CONTRIBUTING.md | ||
COPYING.txt | ||
Doxyfile.in | ||
Makefile | ||
README.md | ||
reformat.sh | ||
uncrustify_cpp.cfg | ||
uncrustify_headers.cfg | ||
Vagrantfile |
#ArduPilot Project#
The ArduPilot project is made up of:
User Support & Discussion Forums
APM Forum: http://ardupilot.com/forum/index.php
Community Site: http://diydrones.com
Developer Information
Github repository: https://github.com/diydrones/ardupilot
Main developer wiki: http://dev.ardupilot.com
Developer email group: drones-discuss@googlegroups.com
Contributors
Dronecode.org
ArduPilot is part of Dronecode.org, a Linux Foundation collaborative project.
Dronecode encompasses projects that control flight, enable mission planning, and otherwise make drone flight and advanced functionality possible.
Dronecode development is done at the project level with coordinating and resource allocation performed by the TSC and the Board.
For information on the foundation please visit https://www.dronecode.org and https://github.com/Dronecode for further information or contact celder@dronecode.org
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.
Helping other users with log analysis on diydrones.com and the APM forums is always appreciated:
There is a group of wiki editors as well in case documentation is your thing: ardu-wiki-editors@googlegroups.com
Developer discussions occur on drones-discuss@google-groups.com
License
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 CONTRIBUTING.md for more information.
- Andrew Tridgell
- Vehicle: AntennaTracker, Plane
- Board: APM1, APM2, Pixhawk
- Randy Mackay
- Vehicle: Copter
- Robert Lefebvre
- Vehicle: TradHeli
- Grant Morphett:
- Vehicle: Rover
- Matthias Badaire
- Subsystem: FRSky
- Paul Riseborough
- Subsystem: AP_NavEKF
- Lucas De Marchi
- Subsystem: Linux
- Peter Barker
- Subsystem: DataFlash
- Víctor Mayoral Vilches
- Board: PXF
- Mirko Denecke
- Board: BBBmini
- Emlid
- Board: NavIO
- Emile Castelnuovo
- Board: VRBrain
- Mike McCauley
- Board: Flymaple
- [Jonathan Challinger] (https://github.com/3drobotics/ardupilot-solo)
- Vehicle: 3DRobotics Solo ArduPilot maintainer
- [Craig Elder] (https://github.com/CraigElder)
- Administration: Dronecode Technical Community Manager