I had a look at the implementation of `slice`, and I found it odd that it doesn't have a copy loop. The current implementation does a raw memcpy of the underlying contiguous row-major data. As far as I can tell, this could only slice along rows. Interestingly, I found that the tests only tested for slicing along rows, so this bug would go unnoticed.
I added some tests that checks slicing along columns also. I have a feeling this would break, and we need to fix the implementation of `slice`. However I could be wrong, and hence I'm submitting these tests first to verify.
This solves a potential dead-lock when trying to shutdown: a call to exit()
stops all threads and calls all destructors for static objects.
The destructor of LockstepScheduler takes a lock. However this is not
safe, as the lock could already be taken (by any thread).
This adds support for the paparazzi autopilot to use this library as EKF.
The header order change has to be done in order to have std.h included to get certain defines at the start of the estimator_interface.h.
The simulator had hardcoded component ID and system ID (sysID was 0), ignoring what was set up in the params MAV_SYS_ID and MAV_COMP_ID. This caused an issue with multi-vehicle simulations that that rely on sysID to identify the vehicles.
Signed-off-by: Gabriel Moreno <gabrielm@cs.cmu.edu>
In CONTRIBUTING.md, the current link to the coding style leads to a
404 error. I've replaced it with a link to the Source Code Management
part of the developer documentation, which is where the style guide
seems to be now.
The cause of the stack detection fault is because of the
level of nesting in the start up script. We need to
determine the worst case configuration and set the
bar there.
This fault occurred some 42 calls deep due to script
calling script (repeat).
The HW stack check requires as a margin of 204 bytes. That is
ISR HW stacking of CPU(8) FPU(18) registers and SW stacking of
CPU(11) and FPU(16) registers. Total CPU(19) registers is
68 bytes and the total FPU(34) registers is 136 bytes. On
a system with a separate ISR stack This only needs to be 104
so there is 100 bytes of headroom. But as coded the detection
will give a false positive detection and fault. This does not
mean that the stack will be corrupted.
Adjustments to that stack can have no effect due to rounding.
A stack size of 2608 and 2616 can yield the exact same size stack.
So even when the failure is due to a 4 byte overflow, it can take
greater than a 16 bytes increase to fix it. Because the final
stack size is calculated with an 8 byte alignment after a 4 byte
decrease. So 2624 becomes 2620 at runtime and will boot
with SYS_AUTOSTART=4001.
A side-effect of the previous commit is that the integral is loaded up
during a flip, which leads to visible bounce-backs after a flip.
Reducing the I helps, but there's a trade-off and we'll need a better
solution.
dlwalter