This saves almost 2kb of RAM when using the mavlink shell. 70 matches the
size of the mavlink message. Since the pipe is blocking, a process writing
a lot of data will just wait, data will not be dropped.
The mavlink shell is the only process creating a pipe.
This saves almost 2kb of RAM when using the mavlink shell. 70 matches the
size of the mavlink message. Since the pipe is blocking, a process writing
a lot of data will just wait, data will not be dropped.
The mavlink shell is the only process creating a pipe.
This saves almost 2kb of RAM when using the mavlink shell. 70 matches the
size of the mavlink message. Since the pipe is blocking, a process writing
a lot of data will just wait, data will not be dropped.
The mavlink shell is the only process creating a pipe.
This saves almost 2kb of RAM when using the mavlink shell. 70 matches the
size of the mavlink message. Since the pipe is blocking, a process writing
a lot of data will just wait, data will not be dropped.
The mavlink shell is the only process creating a pipe.
This saves almost 2kb of RAM when using the mavlink shell. 70 matches the
size of the mavlink message. Since the pipe is blocking, a process writing
a lot of data will just wait, data will not be dropped.
The mavlink shell is the only process creating a pipe.
This saves almost 2kb of RAM when using the mavlink shell. 70 matches the
size of the mavlink message. Since the pipe is blocking, a process writing
a lot of data will just wait, data will not be dropped.
The mavlink shell is the only process creating a pipe.
This saves almost 2kb of RAM when using the mavlink shell. 70 matches the
size of the mavlink message. Since the pipe is blocking, a process writing
a lot of data will just wait, data will not be dropped.
The mavlink shell is the only process creating a pipe.
This saves almost 2kb of RAM when using the mavlink shell. 70 matches the
size of the mavlink message. Since the pipe is blocking, a process writing
a lot of data will just wait, data will not be dropped.
The mavlink shell is the only process creating a pipe.
This saves almost 2kb of RAM when using the mavlink shell. 70 matches the
size of the mavlink message. Since the pipe is blocking, a process writing
a lot of data will just wait, data will not be dropped.
The mavlink shell is the only process creating a pipe.
This saves almost 2kb of RAM when using the mavlink shell. 70 matches the
size of the mavlink message. Since the pipe is blocking, a process writing
a lot of data will just wait, data will not be dropped.
The mavlink shell is the only process creating a pipe.
This saves almost 2kb of RAM when using the mavlink shell. 70 matches the
size of the mavlink message. Since the pipe is blocking, a process writing
a lot of data will just wait, data will not be dropped.
The mavlink shell is the only process creating a pipe.
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.
Make the target EKF rate an integer multiple of the IMU rate. This slightly increases the average prediction time step for the EKF from just over 10msec to 12msec, but the variation reduces significantly which makes filter tuning more deterministic.
Improve the algorithm used to adjust the collection time criteria to reduce jitter in the correction.
This was incorrectly using the IMU (1/250 sec) timestamp instead of the EKF (1/100 sec) value.
The corresponding accelerometer limit has been made a parameter and adjusted to match previous behaviour.
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>
Beat Küng