Fixed the velocity messages (using the correct variables)
Works for PX4FLOW mounted as described here: https://pixhawk.org/modules/px4flow
Option to use i2c or UART to get data from PX4FLOW
Sends debug messages (maybe make optional if needed).
Replaces #1533. Description over there is still accurate. Two additions:
- The user needs to manually set PAPARAZZI_HOME, PAPARAZZI_SRC and TARGET in the build environment after opening .creator file.
- The user needs to manually set the build and clean steps. Disable the check at "all" and put in "Make Arguments": -C /home/houjebek/paparazzi -f Makefile.ac AIRCRAFT=<name> <target>.compile. For example: -C /home/houjebek/paparazzi -f Makefile.ac AIRCRAFT=Iris ap.compile
This needs to happen only once, after which QT will create a .creator.user file
* pprzlink updated to master
* guidance vector field module
* sin trajectory, forgot a minus sign...
* xml files for GVF
* control/gvf.xml not needed anymore
* added some structs for settings and placing gvf_variables into structs
* demo flight plan for testing the settings of the GVF
* style fixed
* trigonometry calculations made only once
* syntax fixed
* pprzlink updated
* added defines and improved description in the module .xml
* module only works for fixedwing (so far)
AbiBindMsgX should be called only once per abi_event struct.
Regardless, this tries to make it a bit more robust if you re-use the same abi_event for consecutive AbiBindMsgX calls:
If AbiBindMsgX is called multiple times _consecutively_, the event/callback is now only added if it is different from the last one added...
This should at least fix the endless loop since the event->next can't point to itself anymore...
Should fix#1924 in a rudimentary way... but would still be possible to bind multiple times using the same abi_event if another bind for the same message happens in between.
Bottom line: make sure that your code doesn't call AbiBindMsg with the same abi_event struct multiple times!
This refactors the speed/position setting in the vertical loop in guided mode as well as added a thrust setting option which should facilitate autonomous takeoff in guided mode
ahrs_x_cmpl: add AHRS_GPS_SPEED_IN_NEGATIVE_Z_DIRECTION
AHRS_GRAVITY_UPDATE_COORDINATED_TURN assumes the GPS speed is in the X axis direction. Quadshot, DelftaCopter and other hybrids can have the GPS speed in the negative Z direction
Michal Podhradsky
Gautier Hattenberger
Hector Garcia de Marina
Michal Podhradsky
Titus
Rijesh Augustine
kevindehecker
Christophe De Wagter
Felix Ruess
Ewoud Smeur
Wilco Schoneveld
Kirk Scheper