- sitl_gazebo in PX4/Firmware (4e792b2487): b34a96e7e5
- sitl_gazebo current upstream: 2e80474653
- Changes: b34a96e7e5...2e80474653
2e80474 2019-02-18 Elia Tarasov - fix comment for mag strength table unit
9a9a137 2019-02-18 Elia Tarasov - fix comment for the file name
7c49b2f 2019-02-18 Elia Tarasov - add units to mag variables
c004d94 2019-02-18 Elia Tarasov - fix magnetic field calculation by using geo lookup table
e9a3940 2019-02-18 Elia Tarasov - fix comment on magnetic data source and properties
c76ac17 2019-02-18 Elia Tarasov - copy magnetic data tables and functions from ecl/geo_lookup
28f59c5 2019-02-18 Elia Tarasov - add constrain function
8c869ed 2019-02-18 Elia Tarasov - fix linker complain on multiple definitions
b5213a7 2019-02-18 Elia Tarasov - add getters for mag inclination and strength
d311233 2019-02-15 Elia Tarasov - fix D-component of magnetic field for Zurich according to WMM2015
- Accel: use cutoff of 62.5 Hz instead of 500 Hz
- Gyro: the cutoff frequency is coupled with the ODR and is fixed to 116 Hz
at 1 kHz readout rate. So this patch does not change anything for the
gyro.
Because BATT_SMBUS is using a different structure (the ModuleBase class), and `BATT_SMBUS::task_spawn` is only called for the `start` command. This is the reason why you don't need to check for it in here.
using only <px4_getopt.h> as include, cleanup related includes
added check that all the option are valid (myoptind >= argc). if there are invalid options on some script that might now lead not to run commands
My recent PR exceeded the 50 char limit (apparently the last character must be null?).
This new attempt changes: "Preflight Fail: Horizontal position estimate Error" to: "Preflight Fail: Position estimate Error"
In fact, this newest wording is more easily understood by the average user and is actually more consistent with the other COM_ARM_EKF_xxx related errors:
COM_ARM_EKF_HGT --> "Preflight Fail: Height estimate Error"
COM_ARM_EKF_VEL --> "Preflight Fail: Velocity estimate Error"
COM_ARM_EKF_POS --> "Preflight Fail: Position estimate Error"
This updates the jMAVSim submodule which includes a fix for HITL.
In order to fix HITL, a CLI argument `-lockstep` was required to enable
lockstep. This has now been added to the command in jmavsim_run.sh.
By using the uORB::Subscription API we use a separate subscription
rather than `orb_copy` on the existing file descriptor used in
sensors through `px4_poll`.
This fixes a very peculiar problem that we observed in SITL in CI for
fixedwing. The events were as follows:
1. `sensors` does `px4_poll` on the gyro topic (as normal), and gets
the latest sample using `orb_copy`.
2. A parameter update happens when the mag is initialized and triggers
`VotedSensorsUpdate::parameters_update()` where `orb_copy` happens
before the main loop in `sensors` has started a `px4_poll`.
3. `sensors` now does the `px4_poll`, however waits indefinitely because
it has already copied the latest sample.
Also, the `px4_poll` will never time out because in lockstep the
simulator waits for the next actuator control message which it never
gets and therefore it never sends the next sensor message with a new
timestamp to advance the time.
This only happens for fixedwing because there is only one "uORB path"
through the system unlike for multicopter where a gyro sample can get
picked up by either `sensors` or directly `mc_att_control`, so the
system can survive if `sensors` has "drops".
Rate changes were doing an asynchronous register reload via the EGR_UG. This could extend a PWM pulse up to 2X.
This fix removes the asynchronous update. The net effect is the the rate change will occur on the next counter expiration. The worst case is the rate change is delayed by 20 Ms.
* refactor ekf analysis part 1: move plotting to functions
* add plot_check_flags plot function
* put plots in seperate file
* use object-oriented programming for plotting
* move functions for post processing and pdf report creation to new files
* add in_air_detector and description as a csv file
* refactor metrics and checks into separate functions
* refactor metrics into seperate file, seperate plotting
* ecl-ekf tools: re-structure folder and move results table generation
* ecl-ekf-tool: fix imports and test_results_table
* ecl-ekf tools: bugfix output observer tracking error plot
* ecl-ekf-tools: update batch processing to new api, fix exception handling
* ecl-ekf-tools: use correct in_air_detector
* ecl-ekf-tools: rename csv file containing the bare test results table
* ecl-tools: refactor for improving readability
* ecl-ekf tools: small plotting bugfixes
* ecl-ekf tools: small bugfixes in_air time, on_ground_trans, filenames
* ecl-ekf-tools: fix amber metric bug
* ecl-ekf-tools: remove custom function in inairdetector
* ecl-ekf-tools: remove import of pandas
* ecl-ekf-tools: add python interpreter to the script start
* ecl-ekf-tools pdf_report: fix python interpreter line
* px4-dev-ros-kinetic: update container tag to 2019-02-13
* ecl-ekf-tools python interpreter line: call python3 bin directly
* ecl-ekf-tools: change airtime from namedtuple to class for python 3.5
* ecl-ekf-tools: update docker image px4-dev-ros-kinetic
* ecl-ekf-tools: fix memory leak by correctly closing matplotlib figures
- see 1259864 Data corruption in a sequence of Write-Through stores and loads
- if we can be certain this sequence won't occur in PX4 then the d-cache will be re-enabled
changed: "Mission rejected: land start required."
to: "Mission rejected: landing pattern required."
This new message is more clear to the average user. When using RTL_TYPE = 1, mission feasibility checker adds the requirement of a landing sequence beginning with a MAV_CMD_DO_LAND_START and ending with a MAV_CMD_NAV_LAND with at least 1 other waypoint prior to the land waypoint. The warning message "Mission rejected: land start required." is a common warning to trigger whenever the mission is blank or the mission is uploaded without a landing pattern. The wording in this message confusing to the average user as they usually do not know the inner workings of the "landing pattern" that their planning software helps them make (e.g. Qgroundcontrol). The only users who would know what a "Do_Land_Start" mission item is are advanced users already and this new message should work equally well for them as well as the non-advanced user.
Daniel Agar
PX4 Build Bot
Oleg Kalachev
mtm-oss
David Sidrane
Beat Küng
mcsauder
Alessandro Simovic
bazooka joe
Anna Dai
Matej Frančeškin
DanielePettenuzzo
Todd Colten
stmoon
Hamish Willee
Julian Oes
JohannesBrand