This commit changes the way libraries headers are included in source files:
- If the header is in the same directory the source belongs to, so the
notation '#include ""' is used with the path relative to the directory
containing the source.
- If the header is outside the directory containing the source, then we use
the notation '#include <>' with the path relative to libraries folder.
Some of the advantages of such approach:
- Only one search path for libraries headers.
- OSs like Windows may have a better lookup time.
This commit changes the way libraries headers are included in source files:
- If the header is in the same directory the source belongs to, so the
notation '#include ""' is used with the path relative to the directory
containing the source.
- If the header is outside the directory containing the source, then we use
the notation '#include <>' with the path relative to libraries folder.
Some of the advantages of such approach:
- Only one search path for libraries headers.
- OSs like Windows may have a better lookup time.
in copter if you try to set RATE_RLL_D to 0 when you haven't
prevviously changed it then it would set it, but would revert on the
next reboot. This is because of the special case handling of a set to
the "default" value. That default value is unaware of the PID
constructors
this fixes that behaviour by forcing a save if the parameter changes
value
We were previously leaking the AP_MPU6000_BusDriver if the
~AP_InertialSensor_MPU6000::detect*() failed. In order to avoid the
leak move the repeated code in a single private _detect() member that
receives everything as argument. Then this method takes ownership of the
objects.
By a adding a destructor to AP_InertialSensor_MPU6000 it becomes easier to
free the objects it takes ownership of.
Different detect() function might need different arguments and passing a
pointer to function here is cumbersome. For example, it forces to have a
method like "detect_i2c2" rather than allowing hal.i2c2 to be passed as
parameter.
The methods actually use the enum from AP_HAL::SPIDeviceDriver, so don't
declare a new one. The I2C implementation is empty; if we actually start
to use it we'd better move the bus abstraction to HAL.
Provides a stable fallback, and can be considered fairly safe from the perspective that it provides a worse value then the hDOP under almost all scenarios.
When writting or reading a block, if the block doesn't fit the area where it begins, the next base address is always zero. Thus the calculations to define the next value of addr are unnecessary.
Here's a quick validity proof using the previous calculations:
First: Considering the case where the block doesn't fit it's first area:
That means that (count + addr > length), what makes:
count = length - addr; (1)
So the following operations:
addr += count;
addr -= length;
Are the same as doing:
addr = addr + count - length; (2)
Using (1) and (2) we have:
addr = addr + length - addr - length = 0
Second: When the block fits the area where it's at:
That means that variable count is not changed,
thus (n -= count) evaluates to 0, which makes the loop exit.
Another change was (b += count;) being moved after the condition to break the loop, since we just need to move the block pointer when it doesn't fit the first area.
remove PANICs from init
return semaphore if init fails
add successful initialisation check before attempting to read from sensor
structure made private where possible
formatting fixes
check I2C reads succeed
add request_measurement to request sensor to produce measurement
quit after 20 of previous 40 reads fail
throttle reads to 10hz max
Fixed this bug
https://github.com/diydrones/ardupilot/issues/840
If a Rover was in AUTO and the user moved the throttle stick into
reverse past 50% the rover would increase. Basically the throttle
nudge behaviour was the same regardless of whether you moved the
throttle forward or backward.
In case of error or zeroed data, the i2c semaphore wasn't given.
It happened at first startup on Bebop and caused a failure:
"PANIC: failed to take _bus->sem 100 times in a row..."
If someone mistakenly puts all 0's in their LAND command then
total_distance will be calculated as 0 and cause a divide by 0 error
below thus crashing ArduPilot. Lets avoid that.
