the SRTM download page now redirects to https
so enable support for TLS
needs the Debian/Ubuntu package libocamlnet-ssl-ocaml-dev
only load tls lib if netclient version > 4
- add temperature control module for Bebop2
- add usb dual cdc board to Bebop2 for serial modem and payload
- Sparkfun FIO v3 board adds simultaneous XBee serial modem and SHT75 humidity payload sensor.
make sure the autopilot implementation init which sets the STARTUP_MODE is called after the guidance module init has run.
This should fix a regression from #1977 and #1978
This PR adds Paparazzi support for the [Pixracer](https://pixhawk.org/modules/pixracer) board. Basically, the Pixracer is a Pixhawk without the FBW side and with another set of sensors. Internally (in the PX4 stack as well), it is called the px4fmu_4.0, whereas the normal Pixhawk has the px4fmu_2.4.
The Pixracer has been mounted in the Splash drone, and by means of the MPU9250 IMU, a Spektrum RC, 3DR power module and a XBee datalink it has been tested to fly nicely in ATT mode. NAV test flight is on the todo list, but should work as well.
Not supported:
- The ICM-20608 IMU
- The temp compensation on the HMC5983 magneto
- Usage of the microSD
- ESP8266 flashing over wifi
Known problems:
- The Spektrum soft binding does not seem to work yet. All the pins and powers are cycled correctly, still the binding won't take.
Big thanks to @OpenUAS for laying the foundation for this PR.
Convert control, guidance and navigation subsystems to modules.
In most cases, the proper documentation and settings are included in the modules.
Fixedwing, rotorcraft and test config are updated. Other conf files are still using the old settings files but since they are not deleted (yet), they can still be used.
Some parts were automatically included (guidance and nav for rotorcraft) so as a temporary hack, it is autoloaded from stabilization modules. This can be improved in the future with dependency and autopilot generation systems.
Dual video stream
Adds Auto White Balance and Auto Exposure for front camera on the Bebop (needs a small change to the exposure, found some inconsistencies when performed together with subsampling).
Adds dual video streaming capabilities for the bebop and update the rtp viewer (naming convention may be still changed).
Also updates to the ISP configuration which allows for subsampling and image scaling of the bebop front camera, replaces #1856
Reads IMU_MAG_RAW messages from ivy and does an "online" min/max calibration and final calibration upon CTRL-C.
If the plot option is given, it plots the raw mag data and when the plot window is closed, calibration is performed
support generated autopilot, based on rotorcraft firmware
- By default the original static autopilot is used. A config flag can enable the use of the generated AP code.
- A basic autopilot description is provided (4 modes + failsafe modes).
- The server is capable of using the list of generated mode to properly display mode names.
- Tested in NAV and GUIDED mode in sim, and direct attitude control on real aircraft.
Some extra features:
- add `--norc` option to NPS simulator
- group all system (generated) settings (AP, telemetry, modules, flight plan) under the same tab (first position)
The `call` primitive of the flight plan can be used to repeatedly call a function until it returns false.
In most cases the function is only supposed to be called only once though...
This has led to a state where a lot of functions that are supposed to be called from the flight plan have an additional `return false` to make them `call`-able.
From just looking at the flight plan it is hard to determine if a function will indeed be only called once or is actually called each time the flight plan navigation is run until it is "done" (returns false).
To make this distinction more explicit and hopefully more clear (and the code cleaner), one should use `call` only when really needed and `call_once` otherwise.
This PR removes the "dummy" `return false` from a lot of functions, hence mandating that `call_once` is used for them. Eventually we shouldn't have any cases like that anymore...
All flight plans were updated accordingly.
The most common case where `call` still has to be used are navigation routines a la `nav_x_run`.
This should be "backwards safe" (not backwards compatible) in the sense that if you try use `call` for a function that needs to be called with `call_once` (since it now returns void), you will get an "invalid use of void expression" error:
```
In file included from firmwares/rotorcraft/navigation.c:40:0:
/home/flixr/code/paparazzi/var/aircrafts/Quad_LisaMX/ap/generated/flight_plan.h: In function 'auto_nav':
/home/flixr/code/paparazzi/var/aircrafts/Quad_LisaMX/ap/generated/flight_plan.h:129:9: error: invalid use of void expression
if (! (NavKillThrottle())) {
^
```
Only run adaptive throttle estimation if we are in flight and
the desired vertical velocity (zd) was updated (i.e. we ran hover_loop before).
This means that the estimation is not updated when using direct throttle commands.
This should fix#1857
Use the main periodc freq timer for modules if the freqs are the same
This is e.g. useful to log the important values every time the control loop runs.
should fix#1923
- While the STM32F411 can run at up to 100MHz, this is not supported out-of-the-box with libopencm3 yet.
So we use the 84MHz clock setup from the STM32F401.
- ADC pins not set up yet
This makes the 'until' attribute of `heading`, `attitude` and `manual` consistent with the rest:
So until will always behave like:
- do something
- check if again
E.g. `<attitude ... until="some_condition"/>` will now create
```
NavAttitude(...);
if (some_condition) NextStageAndBreak();
break;
```
Fixes#1903
This was just so that they could be called with `call`, you should use `call_once` instead.
Also change some macros to static inline functions for better debugging.
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!
convert AHRS subsystems to modules
So far there should be no functional changes, except that the respective settings are now loaded with the module. "Internal" refactoring to get rid of the calls from main will be done later.
Felix Ruess
