Before (introduced in 7b16c3482d), there was no colon after
the `R` argument in the options specification string (ab:R).
The R should be followed by a colon, because in indicates that
the R option requires an argument, which it does.
So I added a colon.
When running in HITL mode, pwm_out_sim publishes actuator_outputs.
px4io unconditionally publishes the uOrb actuator_outputs. When HITL
is configured, the px4io copy of the uOrb has all zeros.
The result is that there are two publications, one valid, and one
all-zeros. This causes the HIL_ACTUATOR_CONTROLS mavlink message
to be incorrect (all-zeros) and the SERVO_OUTPUTS_RAW mavlink
message to be inconsistent, as it takes the data from one or the
other uOrb randomly each cycle.
The fix is to let px4io know that HITL is in effect when it is
started, and modify px4io to suppress publication in this case.
This is a bigger more complicated fix than I would like, but I
think it is conceptually correct.
Signed-off-by: Nik Langrind <langrind@gmail.com>
- Startup was broken due to unnecessary cyclic check probably introduced during transition to work_queues
- Module never used other than on Teal One which had a hacky heater input GPIO, this enables usage on general boards
drivers: heater: reduce verbosity and simplify commandline options
- We prefer the linux way of only reporting errors and staying quiet when everything is functioning as designed
- Most of the commandline options just read out the values of the system parameters, and one can just check the parameter values directly.
sensor_params: make thermal control parameters system parameters
heater_params: make thermal control parameters system parameters
drivers: heater: remove pin control hacks
- px4_arch_configgpio(GPIO_HEATER_OUTPUT) directly inits the heater pin to OFF, and as a PUSHPULL (TTL totem pole) OUTPUT
drivers: heater: set default device ID to 0
This fixes spuriously occuring mag spikes in the external mag of Here2.
The reason for the spikes was that the fact that the I2C registers were
not read out correctly as suggested in the datasheet.
Before we were reading out ST1, data, and ST2 in one pass and ignoring
the data ready bit (DRDY) in ST1. This meant that we could run into race
conditions where the data was not ready when we started reading and
being updated as the registers are read.
Instead, we need to check the read the ST1 register first to check the
data ready bit and then read the data and ST2 if the data is ready. By
reading ST2 we then trigger the next measurement in the chip.
Note: the author name was removed because this file has almost no
resemblence with the code written by that author 4 years ago, has been
copied to new places, and was initially commited without author anyway.
Also, my opinion is that the version control system should take care of
attribution, and not outdated comments.
Daniel Agar