Add DMP-use to MPU-6050

[Staars]

Addition of the DMP-use in the current driver for the MPU-6050

The MPU6050 contains a DMP (Digital Motion Processor) which combines the gyroscope and accelerometer data on the chip.  The DMP calculates quaternions from which other values (angles, acceleration forces) can be derived.

Various examples on the internet show the superior performance of the DMP regarding stability of the sensor readings.

The implementation for TASMOTA does not use interrupts and high speed data accumulation was definitely not the goal. Technically we set the data rate of the sensor to 200 Hz, then clean the FIFO buffer before every read so that the resulting delay should be at approx. 5 ms. The rest follows the example code of the library.
In order to not break existing installations the code has to be activated with an additional #define USE_MPU6050_DMP, which will replace the old calculation method. The names of the mqtt-messages stay the same, but now we getting euler angles in degrees and raw acceleration values, which are not necessary in the same range as before.

I tried to change as few things as possible.

The only other code additions are:

• Added an I2cDevice-check in MPU_6050Detect() because otherwise MPU_6050_address will always be 0x69 in the end, which is very likely only a cosmetically glitch in the debug message.
• Moved temperature conversion in MPU_6050Show() inside the loop after -if (MPU_6050_found)-
• Changed a small part of the I2CdevLib-library.

IMPORTANT NOTE:
At least on my setup the call of DomoticzTempHumSensor(temperature, 0); always crashes TASMOTA. This was also the case with the old driver.

Further considerations:
I would suggest to shorten the mqtt-messages, i.e. AccelXAxis -> AccelA (or even ->AA), but this is a personal preference.

The DMP version should be recommended as the first option and always bring superior results.
Example: http://www.geekmomprojects.com/mpu-6050-redux-dmp-data-fusion-vs-complementary-filter/

The exception from this rule could in theory be power consumption, because the DMP will draw a bit more. I do not have the equipment to test and confirm this.

The compiler warnings regarding the debug code in the I2CdevLib-library can be ignored or silenced via out commenting.

I left the extra MPU_6050PerformReading(); at the bottom after Xsns32(byte function) although the I do not really understand their necessity. At least they do not hurt.

My test setup:
TASMOTA 6.3.0.16 with the current PlatformIO and SDK 2.3 and 2.4.2 on a NodeMCU and Wemos powered via USB-Port of my laptop.

[ascillato2]

Thanks for the enhacement of the driver 👍

IMPORTANT NOTE:
At least on my setup the call of DomoticzTempHumSensor(temperature, 0); always crashes TASMOTA. This was also the case with the old driver.

Doesn't happened to me under cores 2.3.0, 2.4.2 or 2.5.0. May be you had enabled too many features and sensors that produces an exception for not enough memory.

Further considerations:
I would suggest to shorten the mqtt-messages, i.e. AccelXAxis -> AccelA (or even ->AA), but this is a personal preference.

Good idea, but will break backwards compatibility, so it is better to leave as it is.

In your modifications in the code, you add pgmspace.h. I was concerned about that because in core 2.5.0 they modify that. But after some compilation testing, this PR compiles fine under 2.3.0, 2.4.2 and 2.5.0. I don't have the sensor to test, but for the rest, seems everything ok. Thanks 👍

[ascillato]

When enabling this sensor in my_user_config.h, now it uses 188 Bytes RAM and 12KBytes of Flash

If enabled MPU6050 without DMP, it uses 3K3 of flash
If enabled MPU6050 with DMP, it uses +8K6 of flash reaching the 12K of flash for the whole driver.

[Staars]

I will have a look, if this can be avoided.

[ascillato2]

It is Ok. It was just an information. Before this PR was 2K6 of flash

[Staars]

I just tested my domoticz-issue again and it still happily crashes. At least it does not help to deactivate the default I2C-drivers, to save a bit of memory.
So we should mention it somewhere.

[Staars]

I spent the last hour with debugging and (to my best knowledge):
DomoticzTempHumSensor(temperature, 0); leads to crash in
xdrv_07_domoticz.ino:
snprintf_P(data, sizeof(data), PSTR("%s;%s;%d"), temp, hum, DomoticzHumidityState(hum)); (line 405), which seems to have problem with the agument hum=0.
I.E. if I call instead:
DomoticzTempHumSensor(temperature, temperature); -> no crash occurs.

[ascillato]

The call DomoticzTempHumSensor(temperature, 0); shouldn't make the exception, but anyway, seems to be incorrect due the Domoticz driver has also the call DomoticzSensor(DZ_TEMP, temperature); for temperature only.

If you try that one instead, your exception is solved?

[Staars]

Yes, this solves it! No more exceptions.
This sounds a bit like "undefined behaviour" to me. I will investigate later outside of this PR.

[paspo]

LGTM

As asked by @ascillato I tested this in my two setups: works like a charm.
I agree DMP should be the default, and possibly the only implementation in tasmota: at the moment, to use these sensors, you have to build your own firmware, which is a task for a small part of the user base, so (IMHO) this is a great time to break with the past...

[arendst]

Regarding domoticz: it's as designed. There are several inputs to domoticz. Just look how other drivers have been implemented using different entries for different Domoticz specific sensor types.

In case of the exception call: it's expecting chars not numbers so it's expected to get an exception if a 0 is supplied in case of a char.

[Staars]

Okay, good to know. But I am still a bit surprised, that we never got reports about crashes before, because this line of code has been there from the beginning (before I worked on that driver).

…

Am 11.12.2018 um 11:36 schrieb Theo Arends ***@***.***>: Regarding domoticz: it's as designed. There are several inputs to domoticz. Just look how other drivers have been implemented using different entries for different Domoticz specific sensor types. In case of the exception call: it's expecting chars not numbers so it's expected to get an exception if a 0 is supplied in case of a char. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#4581 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AFOiZDBwkoIOZRz_0cJZQodo6KrVIB6iks5u34qsgaJpZM4ZL3Fv>.

[arendst]

If Domoticz is disabled you won't get an exception.

BTW: Did you pay attention to the temperature in Fahrenheit? If not look how other drivers use function ConvertTemp.

[Staars]

Yes, this should be the reason. Regarding the temperature I can safely say, that I tried to leave everything as before. It should behave identically, except the changed domoticz call, which was incorrect all the time. But I will use the opportunity to have a look at the other drivers (incl. the Fahrenheit issue) and maybe I will learn a thing or two :)

…

Am 11.12.2018 um 11:47 schrieb Theo Arends ***@***.***>: If Domoticz is disabled you won't get an exception. BTW: Did you pay attention to the temperature in Fahrenheit? If not look how other drivers use function ConvertTemp. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.