Go Down

Topic: MPU6050 erratic values with MOTOR on LOAD - HELP! (Read 1 time) previous topic - next topic

MartinL

#15
Oct 18, 2020, 11:18 am Last Edit: Oct 18, 2020, 11:19 am by MartinL
Hi r0yy,

Here's a link to Pololu's webpage on dealing with motor noise: https://www.pololu.com/docs/0J15/9

As you've already tried point 1 on the linked page, it might be worth trying points 2 and/or 4.

r0yy

At this point I am able to get the I2C working at a stable rate by adding 10k resistors on SDA SCL as pull ups

The bot is working stable as intended with a single lipo battery powering the whole thing. However when I mount the electronics into the bot adruino starts freezing again sometimes it can't read the sensor any more. 


The bot works best with the following setup motor controller and arduino away from the motors as shown in the picture
https://imgur.com/KdvtUpn

with the other two setups the bot freezes within 5-10 seconds on powering on
https://imgur.com/p17sL6b
https://imgur.com/vlLfEOw

I am using fiber glass copper clad board as the base of the bot with the copper intact could that be an issue?

 can I use it as a ground shielding(i dont know how it works but was planning to solder a ground wire to the copper clad) 


MartinL

#17
Oct 21, 2020, 06:32 pm Last Edit: Oct 21, 2020, 06:36 pm by MartinL
Hi r0yy,

Thanks for the images.

It might be worth adding extra support to your MPU6050 breakout board. It's just that motor vibration can disturb the gyroscope and acceleromter, especially when the board's only physical support is a female pin header.

On my quadcopter I used two, 8mm, nylon hex threaded spacers and nuts, both with M3 threads, plus two small squares of double sided foam tape at the base of each of them, to provide cushioning from vibration:



The quadcopter also required the MPU6050's DLPF to be set to 20Hz. Note that the two 2N7000 N-Channel MOSFETs provide the I2C 5V to 3.3V level shifting.

r0yy

I built a circuit all from scratch on a perf board,
1) added spacers to support the MPU 6050
2) added power filtering with 470uf and 0.01uf caps
3) added pull up 10k resistors on the SDA SCL lines
4) shortened all the wires as much as possible
6) when through numerous arduinos and motor drivers to cross out the problems due to a faulty board
5) Changed motors to a different kind of 12v motors

after doing all this the problem still exists. THE ARDUINO STILL FREEZES ON MOTOR START!

At this point I want to give up on this project(out of frustration) but I still want to see this through the end(The bot working). I have seen videos and tutorials with people getting away with shabby wiring, no filtering, cheap motors or parts I really dunno what is wrong. ANY HELP WOULD BE REALLY APPRECIATED.

https://imgur.com/2fWI7QO


MartinL

#19
Oct 30, 2020, 07:56 pm Last Edit: Oct 30, 2020, 08:07 pm by MartinL
Hi r0yy,

Quote
At this point I want to give up on this project(out of frustration) but I still want to see this through the end(The bot working). I have seen videos and tutorials with people getting away with shabby wiring, no filtering, cheap motors or parts
I know that it's really frustrating. It doesn't seem like it now, but it's actually all a learning process. Those who have it easy, don't necessarily learn how to do it right. You've gone through most of the obvious steps that would normally solve the problem.

It took me a while until I discovered that I needed spacers on my first flight controller's MPU6050 breakout board, to stop the motor vibrations affecting the sensor.

Do you have some form of circuit diagram or schematic? It could just be a wiring issue?

Also, I noticed that the L298N has a jumper that should be removed if you're using more than +12V for the supply, in order to disable its on-board +5V regulator.

You mentioned that you were using 3S and 4s Lipo batteries. 3S batteries will supply more +12V when fully charged and 4S more than that. I'm wondering in that case what you're doing wih the +12V jumper and if you're using the on-board +5V regulator?

r0yy

Hello Martin,
I am using a 4S lipo but with a buck converter set at 12v.
Also I am using this board as my main board to minimise any sort of wiring between the motor driver and arduino.

https://robu.in/product/cytron-dual-channel-10a-motor-driver-uno-robot-controller/

i tried running the code with MPU connected to 3v3 supply and 2.7k pull up resistors. Still the same issue arduino getting stuck.

I wrote a code that scans the I2C line for new devices and also switches motor On and Off(these two function, scanning devices and motor on/off are independent of each other) to test if the motor was causing trouble to the I2C bus, but this works properly so I highly doubt anything from the I2C side or the motors are causing this issue.

Issue due to power to arduino can also be crossed out as I am using a professional quality board(as mentioned above).

however when I still run the self balancing code without the motor driver plugged in arduino never freezes, problem is with the motors being introduced into the system, arduino just freezes after couple of seconds as motors are plugged in

MartinL

Hi r0yy,

So now you're using a single Cytron combined Arudino Uno and motor driver board?

It might be best to post an image of your circuit diagram.

Also, what is the current rating of your +12V buck converter? If your motors are attempting to draw too much current at start-up, it might cause the microcontroller to initiate a brown out reset.

MartinL

#22
Nov 07, 2020, 12:31 pm Last Edit: Nov 07, 2020, 12:54 pm by MartinL
Hi r0yy,

The reason why I asked about the +12 buck converter's current rating, is that if you're using to power the motors in addition to the Arduino, but it's unable to supply the peak current required by the motors, then it will enter an over current condition. If there's an over current condition, the converter will most likely fold-back the current resulting in output voltage drop, this is known as fold-back current limiting:



(In addition to fold-back, other current-limiting schemes that can be employed are constant current or hiccup mode).

A momentary voltage drop might affect you microcontroller's operation.

One way around this, is to supply your motor controller direct from the battery and your Arduino through the a voltage regulator in the 7V to 12V range. It's possible to prevent an over voltage condition on your motors, by limiting the PWM duty-cycle so that the average (voltage) never exceeds 12V.

Although not essential, the battery voltage can be monitored on your Arduino's analog input pin, by using a voltage divider circuit (using two resistors and possibly a small capacitor), to bring the voltage down to a 0 to +5V level so that it can be measured. This information can be used to the limit the PWM duty-cycle and also to account for any voltage drop as the battery becomes depleted. This circuit has the additional benefit that it can also be used in conjunction an LED or buzzer, to act as a battery low indicator.

r0yy

Sorry for the late reply,
I finally figured out the issue. It was neither an issue with the code nor an issue with the hardware. The main issue was the wire library. Apparently in an I2C communication if the slave disconnects the master goes into an infinite loop as there is no timeouts set by default.

I found this thread on github if anyone wants to go through thoroughly
https://github.com/arduino/ArduinoCore-avr/pull/107


setting a timeout completely solved the issue. Now as soon as a timeout is detected the connection with the MPU6050 is refreshed which is almost at par(the time to refresh the connection) with the loop time so does not cause any issue. The bot is atlast able to balance without setting the motor to full rpm due to the i2c hang up.

The mechanical build of the bot is such that if tends to tip over to one side more often than the other, that is because I did not build a great structure for the bot its heavy on one side.

MartinL

Hi r0yy,

Glad to hear you've found a solution that allows your board to recover from the I2C failure.

However, the issue remains as to what is causing the I2C bus to stall, since it shouldn't be happening during normal operation. The I2C recovery is simply masking the problem, but it's one big step closer to solving what's causing it.

I suggest posting your circuit diagram even if it's just hand drawn, as it's always good to have other sets of eyes go over it. Peer review is normal practice in any engineering department, as it increases the chances of any obvious mistakes being spotted.

Go Up