This warning happens because of the difference of datatypes between
32 and 64 bits processors.
%% libraries/AP_HAL_Linux/RCInput_UDP.o
/home/zehortigoza/dev/ardupilot/libraries/AP_HAL_Linux/RCInput_UDP.cpp: In member function 'virtual void Linux::LinuxRCInput_UDP::_timer_tick()':
/home/zehortigoza/dev/ardupilot/libraries/AP_HAL_Linux/RCInput_UDP.cpp:42:72: warning: format '%llu' expects argument of type 'long long unsigned int', but argument 3 has type 'uint64_t {aka long unsigned int}' [-Wformat=]
hal.console->printf("no rc cmds received for %llu\n", delay);
As AVR2560 is not supported anymore and do integer operations is
usually faster than float-point the _calculate() implementation was
done using only integer operations and as more close to what
datasheet says.
offset parameter units are milligauss
User settable parameters should have a User category defined. Those that should never be set by a user should not have this.
The function rotate_field() can change the values axes and the function
correct_field() applies offsets (which are already in milligauss). Thus any
sensitivity adjustment must be done for two reasons:
(1) The offsets must be applied to the values already in milligauss;
(2) The factory sensitivity adjustment values are per axis, if any rotation
that switches axes is applied, that'll mess with the adjustment.
Experiments showed that before this patch the length of the mag field reported
quite different from the expected. After this patch, the same experiments
showed reasonable values.
This is part of the transition to make all mag field values be used in
milligauss. Additionally the value of _gain_multiple is adapted to the new way
we're using it and corrected accordingly to the datasheets.
The use of _gain_multiple is not necessary because the values of
expected_{x,yz} and _mag_{x,y,z} are both in sensor raw unit (i.e., lsbs).
That wasn't fixed before in order not to make APM users to recalibrate their
compasses.
We changed from ArduCopter to APM:Copter, breaking parts of the LogAnalyzer
This change has LogAnalyzer canonicalise its output to Ardu{Plane,Rover,Copter}
Also account for change in MODE message - ThrCrs has gone away
The failure to initialise the magnetometer bias states to zero can result in a large jump in yaw gyro bias and heading when a heading reset is performed.
Fixes a potential error where changes to timing and arrival rate of magnetometer and baro data could block the fusion of synthetic position and velocity measurements, allowing unrestrained tilt errors during operation without GPS or optical flow.
Fusion of synthetic position or velocity measurements is now timed to coincide with fusion of barometer observations.
If a new barometer observation has not arrived after 200 msec then the synthetic position or velocity is fused anyway so that fusion of synthetic position or velocity observations cannot occur any slower than 5 Hz
Previous check default only checked the number of satellites and horizontal position accuracy.
Updated default value also checks HDoP and speed accuracy.
José Roberto de Souza
teddytrowbridge
Randy Mackay
Gustavo Jose de Sousa
Peter Barker
Paul Riseborough
Grant Morphett
vooon