The bulk of this change was tightly coupled and needed to be deleted in one pass. Some of the smaller changes were things that broke as a result of the initial purge and subsequently fixed by further eradicating unnecessary platform differences. Finally, I deleted any dead code I came across in the related files I touched while going through everything.
- DriverFramework (src/lib/DriverFramework submodule) completely removed
- added dspal submodule in qurt platform (was brought in via DriverFramework)
- all df wrapper drivers removed
- all boards using df wrapper drivers updated to use in tree equivalents
- unused empty arch/board.h on posix and qurt removed
- unused IOCTLs removed (pub block, priv, etc)
- Integrator delete methods only used from df wrapper drivers
- commander: sensor calibration use "NuttX version" everywhere for now
- sensors: update to px4_{open, read, close} instead of DevMgr wrapper (adc open for analog differential pressure)
- battery_status: update to px4_{open, read, close} instead of DevMgr wrapper (adc open for analog differential pressure)
- cdev cleanup conflicting typedefs and names with actual OS (pollevent_t, etc)
- load_mon and top remove from linux boards (unused)
- delete unused PX4_MAIN_FUNCTION
- delete unused getreg32 macro
- delete unused SIOCDEVPRIVATE define
- named each platform tasks consistently
- posix list_devices and list_topics removed (list_files now shows all virtual files)
On Ubuntu we often saw the error
Assistive technology not found AWTError when starting jMAVSim.
This should be fixed by appending this cli argument to java.
As suggested in https://github.com/PX4/containers/issues/206
This target was never fully supported and is heavily dependent on a number of DriverFramework drivers that have no in tree equivalents (bebop bus, flow, rangefinder, etc). Deleting this will make it easier to fully drop DriverFramework shortly.
- make sure to kill all px4 instances and gazebo client when exiting
- add arguments to specify number of vehicles and vehicle model
- exit for now if vehicle model is not iris, since needs changes in
sitl_gazebo submodule
Signed-off-by: RomanBapst <bapstroman@gmail.com>
Main UAVCAN protocol handling and ESC updates run on the same thread/wq as
before. There are 2 WorkItems for separate scheduling of the 2, so that
ESC updates run in sync with actuator_control updates. UAVCAN is scheduled
at a fixed rate of 3ms (previously the poll timeout) and on each UAVCAN
bus event.
This leads to roughly the same behavior as before. CPU & RAM usage are
pretty much the same (tested on Pixhawk 4).
Testing done: Motors still work (with feedback), param changes and a
UAVCAN optical flow sensor.
The 9 seconds to erase a board probably still come from the FMU-v1 and
Pixhawks with only 1 MB flash. By now, many targets have 2 MB flash and
take a bit longer to erase. Therefore, we can increase the estimated
time a bit and don't need to resort to the timeout notice.
- jMAVSim in PX4/Firmware (a6a8877463): 3bd51e67e0
- jMAVSim current upstream: eeb23ef68e
- Changes: 3bd51e67e0...eeb23ef68e
eeb23ef 2019-10-30 bresch - magnetometer: update inclination/declination/local mag field strength of default starting locations. Set magnetometer scale factor to 1 (instead of 2) Set local mag field using DEFAULT_MAG_FIELD instead of an estimated one using inclination/declination and a norm of 1
TSC21
Daniel Agar
romain-chiap
Julian Oes
RomanBapst
JaeyoungLim
Lorenz Meier
Christian Clauss
Matthias Grob
kamilritz
bresch
PX4 BuildBot
LP
Beat Küng
CAI Dongcai
katzfey