The initialization code is redundant and incomplete (only the first sensor
is done). I verified that all drivers already set this on startup.
For the mags, they all set their maximum supported update rate.
For the baro, the call can silently fail, as for example the MS5611 which
does not support 150Hz update. But it also sets the maximum in
initialization.
Tested on Pixhawk & pixracer.
In HIL mode we do not start the sensors anymore, so this is not needed.
Also it did not work (I did not try to find the reason, just noticed the
sensors kept publishing in HIL mode)
On SITL startup we got a datalink lost failsafe message whenever home
was initialized. The reason that in standalone SITL, there is usually no
datalink connected. However, on ground, we shouldn't really failsafe,
therefore it makes sense not to enter the state in the first place.
The sensor_rest command added to the startup script for px4fmu_v4 hardware
was leaving the /dev/pwm_output0 driver open. This would prevent the
pwm_out_sim module from registering as a simulated driver. The result
would cause the system to properly boot in HIL mode, but you would not
be able to set any control surfaces.
Since sensor_rest and peripheral_reset are only used on initialization, the
drivers can be shut down after they have performed their reset functions.
Signed-off-by: zthorson <zachthorson@gmail.com>
logger will always log this topic, and a 0 timestamp will look worse in
FlightPlot. This will show a period of 0 attitude instead before ekf
is initialized.
if a parameter name was 16 characters long (which is valid), the last
character got truncated due to 0-terminated string.
This raises the param name to 64 chars, which is quite wasteful, but there
is no other length in between.
vehicle_status_flags_pub passed to publish_status_flags() was always null,
thus orb_advertise() was called each time.
Note that it did not produce a memory leak.
Beat Küng
jwilson
Julian Oes
Michael Schaeuble
Mathieu Bresciani
Lorenz Meier
zthorson
Daniel Agar