degree(100) = 1 float multiplicaiton
vector3f * degree(100.0f) = 4 float multiplications
degree(vector3f) * 100.0f = 6 float multiplications and needs new degree(vector3f) function
degree(vector3f * 100.0f) = 6 float multiplications and needs new degree(vector3f) function
These all come to the same conclusion but the one that is faster appears to be a bug but is mathematically correct.
Revert "AP_NavEKF2: Fix bug in published yaw reset value found during code review"
commit 175faf1e41.
Revert "AP_NavEKF2: use a struct for all yaw step class variables"
commit 77fad065d1.
Partially revert "AP_NavEKF2: Handle yaw jumps due to core switches"
commit 885bfd1b4e.
This is a revert of 7c3b8dceb which tried to start at index 0 of the
array of baudrates, however because of the way last_baud is used
this lead to a GPS always being reported as being 1 index off which
lead to users getting reports of baud rates that their GPS wasn't
configured for
Also renames last_baud to be current_baud as that is how it's
actuallly used and should reduce future confusion
And fixed some tabs/vs space issues around where the last_baud rate
was incremented.
this is a RCInput module for multiple R/C uart protocols running at
115200 baud 8-bit. We can decode multiple protocols in parallel with
this module, relying on frame timing and CRCs to get the right
protocol
- uart->available(); returns uint32 but was stored locally as int32 and treated as uint32. Now stored correctly as uint32
- some variables were set to zero at start of function, then reset to zero before being used. wasted work
Having a critical divide by value as a class member that could change external to the function using it is fragile. It was not very obvious that a divide by zero was not possible in the current design, now it's very obvious and safer in case the code changes later.