openrov / openrov-software-arduino Goto Github PK

It is possible we are saturating the I2C somehow. Or perhaps by reading the IMU on each loop we have enough activity to guarantee a lot of lockups.

Motor reverse is supposed to swap the sign of the signal sent to the motor. The current linear correction is happening after the sign is altered. It should be based on the sign before it is altered.

I suspect if you reverse one thruster it will actually go twice as fast when going forward because the modifier of 2 is applied as if it were in the reverse direction due to the sign.

There is a problem with only sending disable on both toggle commands

http://openrov.com/forum/topics/ms5803-14ba-pressure-sensor-code-issues

This register is supposed to be set before init of the wire library
TWBR=400000L

https://github.com/OpenROV/openrov-software-arduino/blob/master/sketches/OpenROV2x/CCommand.cpp#L110

This should be changed to use strcmp. Currently, cockpit is sending "throttle" as a command, but "thro" is satisfying the check. This could easily cause problems if new commands are added that happen to have a common substring.

This issue covers all of the current investigation that is going in to the MPU9150 issue.

The problem is that after a few seconds, the MPU9150 appears to stop responding which originally then cause the Arduino's watchdog timer to trigger because the I2C library was hanging waiting for a response.

We have since updated the I2C wire library to include timeouts on those operations which will then reset the I2C bus if it happens. We have seen that when we reset the bus a lot the MPU9150 can get in crazy staight (reporting massive roll or freezing and no longer initializing)

We noticed that the library was pounding the I2C bus, presumably for requests for new data every time the Arduino looped. We added a timer to match the data rate of the MPU9150 DMP checks. This did lower traffic and seemed to reduce the lockups. Further reading suggests we need to be careful as you can overflow the fifo buffer in the MPU9150 if it is not serviced fast enough which would create similar behavior to what we are trying to solve.

We confirmed that hardware package has not had any revision since we introduced the device.

We have also observed some IMUs seem to consistently be trouble free. Others not so. No idea what the difference might be. We do see general slow down on the number of loops the Arduino is able to process with certian IMUs, which may be an indicator of longer wait states for some reason.

There are comments in the 'NET' that say the current MPU9150 library we are using has known I2C issues, but I have not found any concrete reports of these.

Related issues:
#6

OpenROV/openrov-software#278
OpenROV/openrov-software#246

Moved from: OpenROV/openrov-software#254
It is with great pleasure to announce our latest software release to the Developers Corner, Embedded MotionDriver 6.0 (eMD 6.0). This is our first ever 9-axis solution that is NOT locked to a particular MCU. eMD 6.0 is supported across all ARM Mx core architectures allowing for increased platform flexibility and is compatible with the InvenSense MPU-6000, 6050, 6500, 9150, and 9250 devices. This solution will allow you to now easily leverage and configure numerous features of the DMP and also take advantage of and benefit from dynamic features in the MPL software library.

Your collective voice was heard loud and clear as we strive to meet your current and future needs. We could not have done this without your feedback. Similarly, please provide any additional feedback on this beta version of eMD 6.0 by sending an email to [email protected].

eMD 6.0 can be downloaded from our Developers Corner.