Solve the noise issue in PCB due to motors

[gautam-dev-maker]

In Wall-E 2022, we faced the issue of noise in I2C line , which was caused by static noise in motors. This forced us to add capacitors and ferrite bead on the motors. Since we have never faced this issue before with BO motors, we can assume that motor driver might not be working well in filtering the noise.

We can test it by using different motor drivers like DRV8833 to see if the problem persists.

[gautam-dev-maker]

@Jamm02 @ChinmayLonkar @Sidshx kindly assign someone for this testing and post the results here and treat it as priority since we need to make changes to SRA board hardware design wrt to the post.

[ChinmayLonkar]

@gautam-dev-maker I'll take this task👍

[gautam-dev-maker]

HOW TO REPRODUCE THE ISSUE:

1. Place no ferride bead and capacitor on the Motor drivers
2. The issue only comes up when BO motors draw lot of current. So in situation when BO motors are obstructed it will produce the issue. Also when BO motors are run on duty cycle above 50 the issue becomes consistent.
3. Read the MPU6050, and look for readings when the above situations has been created.

WHAT TO DO:

1. Currently we are using TB6612FNG, so first step will be to reproduce the issue as mentioned above.
2. Then proceed to replacing TB6612FNG with DRV8833 (ofcourse temporarily) and test if the issue persists

Based on the result of the above test we can debug the actual solution of the issue.

[Jamm02]

@omsheladia will be taking up the task

[dhairyashah1]

More details on the issue -

Current Consumption by single Bo motor
12v, 300 rpm
Conversation on i2c packet drop and solving mpu6050 issue:

Reddit post 1: https://www.reddit.com/r/embedded/comments/srgqlz/i2c_communication_not_working_properly_when_motor/

Reddit post 2: https://www.reddit.com/r/ECE/comments/srgpyk/i2c_communication_not_working_properly_when_motor/

Reddit post 3:
https://www.reddit.com/r/arduino/comments/srgova/i2c_communication_not_working_properly_when_motor/

Reddit Post 4:
https://www.reddit.com/r/PrintedCircuitBoard/comments/srvaxa/pcb_review_i2c_communication_not_working_properly/

Solution and Conclusion:
Noise suppression of brushed motors
https://youtu.be/O39inZIscOI

After many test runs, the following is the conclusion until now:

1. The I2C bus when observed on DSO looked pretty fine. Both the lines go high while reading data.

2. Even after isolating Mpu6050 or using shorter / isolated i2c paths, the error persisted. Although the frequency of those errors happening was somewhat controllable to an extent.

3. Different capacitor combinations were tried across the motors and voltage lines:
   Currently - 0.3 uF ceramic across each motor
   220uF 25V across 12V line
   0.1uF ceramic each across 3V3, GND of Motor driver (Vcc), and OLED PORT
   Although this eliminated the low-frequency noise of the motors which was evident in the DSO waveforms. The problem was yet to fetch a fix. But high-frequency noise generated due to brush sparks inside brushed motors was the uncaught culprit.

Layer 0.1uF(<=100uF) was installed across the terminals of all Bo motors still no change in results.

4. Finally adding (0.1uF ceramic capacitor across motor terminals & ) ferrite beads across the motor wires and using twisted cable pairs seemed to have done the trick and reduced rf noise to a great extent for our application!!!
   This is a boon for brushed motors.

For more reference view discord #wall-e channel

[gautam-dev-maker]

@dhairyashah1 I am not so sure about the second point of the conclusion, because we were only able to control the error if we manually reduce the duty cycle (and hence reduce the current consumption).

Let's see if the issue can be reproduced.

[dhairyashah1]

@gautam-dev-maker if we could have an economical alternative to the motors that would be great too. BO motors get stalled with ease momentarily.

[gautam-dev-maker]

I agree, but then my dilemma is why didn't we face this issue with L298N motor driver, why with TB6612FNG. If motor driver is the real culprit then we will need to make serious changes.

[omsheladia]

I will be taking up this task, though a small meet before getting started would be helpful.

[gautam-dev-maker]

@omsheladia I would recommend you read all the material posted above and go through the reddit post provided by @dhairyashah1 , I think that is way more than enough to explain things.

[Jamm02]

@omsheladia any updates on the task?

[omsheladia]

@Jamm02 Gone through the resources, and am coming to the college tomorrow since I do not have Walle at the moment and will update how it goes tomorrow

[omsheladia]

So, I tried running the self_balancing in 2 situations,
1: With ferrite core and the capacitors
And the readings are:

2: Removed just the ferrite core
And the readings are:

Although it lost its stability.

I will remove the capacitor and post it as soon as I get my hands on a soldering iron. In the meanwhile I will go through the documentation of DRV8833 motor driver.

[dhairyashah1]

@omsheladia

1. This is nothing new but already known.
2. If you didnt have walle kit why didnt u get it asap when the task was assigned?
3. This is no close to a solution just reproducting the results. Solution can be found even by searching online, asking on forums, testing with suitable hardware (cap) configurations etc.

[omsheladia]

@dhairyashah1 I was told just to reproduce the results first and then test it with the new motor driver.

[dhairyashah1]

@omsheladia was this tested on drv8833 or tb6612fng
Also testing must not have taken this much time.

[omsheladia]

@dhairyashah1 The kit available in SRA when I went was not in the best condition, so had to reassemble it again. Then even while testing the esp32 mounted on the sra board was throwing errors until I replaced it with a different one which took some time. And I was testing it on the current tb6612fng driver.

[dhairyashah1]

@omsheladia so it took 8 days to reassemble and solve errors right?

[omsheladia]

So, this was the output on obstructing the motors to a greater extent without the the core and the capacitor.
@gautam-dev-maker Does it satisfy the reproduction of issue?

[Jamm02]

@omsheladia Have you tested this on DRV8833 instead of tb6612fng?

[omsheladia]

I was informed in person today to carry out the same thing on a breadboard i.e. without using the sra board.

[dhairyashah1]

Wasn't this already obvious @omsheladia? You can't plug a DRV8833 into the existing slot on the SRA board. Options - testing on a perf board/ breadboard. This was conveyed and self-understood well in advance as per my knowledge.

[omsheladia]

@dhairyashah1 I had to try the same thing with DRV883 and I never said anything about plugging it into the existing slot directly, was gonna use jumpers. But there was a risk about the difference in voltage levels of both the drivers which could destroy either the DRV8833 or the SRA board which I told Gautam. So he told to continue with TB6612FNG without the sra board.

[dhairyashah1]

@omsheladia how is it different to try it on sra board vs externally on breadboard? The solution was to look up and research on some solution online/ask on reddit/ try different stuff. I dont see anything like that. Consider using Drv8833 changing voltage level as we have a lot of buck converter MODULES at SRA. Converting 12v to 10v and trying could have been done.

I want to know what different has been done/tested clearly.

[omsheladia]

@dhairyashah1 it was not my decision to do the current task on the breadboard. As far as solution is concerned, I did try to run by some solution but was told to do the task first and then will see about the solution. And for hooking up the DRV8833 with the SRA Board, I did consider using the buck converter for the change in voltage and also ran it by Gautam before setting it up in SRA yesterday but I was told to do the task first which I wrote above.

[dhairyashah1]

@omsheladia pls specify what was that some solution ? Be clear, talking with links, demos, results or conclusions is desired.

[Jamm02]

@gautam-dev-maker @dhairyashah1 @omsheladia, @Premraj02 will be following with this task ahead. @Premraj02 it is expected that a brief update is given by the end of this week. Feel free to ask queries regarding the task after going through the thread.

[Premraj02]

@dhairyashah1 @gautam-dev-maker

Updates:

1. I reproduced the issue using self balancing code to understand the error and the conditions required to reproduce the error.

2)Implemented the MPU and TB6612 system on breadboard instead of SRA board. But the issue still occurs. Thus the issue is related to motor driver and not the design of SRA board.

3)Next I replaced the TB6612 with DRV8833 (on breadboard) and the issue did not occur. So I connected the DRV8833 on the SRA board using jumper wires. And it seems to work fine.

4)The only issue with DRV8833 is that it requires less voltage (Currently using 9V, Max is 10.8V) and also it supplies less current than TB6612. Max current with TB6612 was 600mA whereas with DRV8833, max current is 500mA. Due to this, the motors are slower with DRV8833 and when the pitch error is less (±1) the motors don’t respond to lower values of PWM.

Conclusion: DRV8833 solves the noise issue but with limitation of current. In future if we decide to shift to DRV8833, we will have to add on more voltage regulator on the SRA board (12V to 9V) or use a 9V adapter instead of 12V.

Next I will try to get same output current by increasing motor PWM above current limit of PWM values.
Attachments:
Maximum current consumption of single motor at 9V:

[Premraj02]

As per the datasheet of TB6612FNG motor driver, VM as well as Vcc should have 2 bypass capacitors of 10uF and 0.1uF. But the motor driver module has only one 10uF capacitor on VM line. So I tried adding one more 10uF capacitor between Vcc and Gnd. But this doesn't solve our problem and the issue is still there with the TB6612FNG motor driver.

References: https://www.sparkfun.com/datasheets/Robotics/TB6612FNG.pdf

Attachments:

1. Typical application diagram of TB6612FNG:
   

2. Additional capacitor:
   

3. Output without additional capacitor:
   

4. Output with additional capacitor:
   

[Premraj02]

@dhairyashah1 @gautam-dev-maker
On DRV8833 system when continuous PWM duty cycle of 90% is provided, each motor draws 100mA current on no obstruction and 700mA when fully obstructed. So far there is no issue with MPU readings.
When tested with varying PWM, TB6612FNG starts responding at 57% PWM duty cycle whereas DRV8833 starts responding at 63-65% PWM duty cycle.
Thus TB6612FNG can be replaced with DRV8833 with some modifications in code such that each value of duty cycle is increased by some constant value to compensate decreased voltage and current .

Attachments:

1. Maximum current consumption of single motor at 9V on 90% duty cycle:
   

[gautam-dev-maker]

@Premraj02 what do you mean by "starts responding at"?

Try 12 V with DRV8833 and see if it works, only then we can determine if the problem is with motor driver or routing.

Also if we are looking at solutions, we can use ferrite Bead on PCB. But to use ferrite bead we must know the upper range frequency of noise generated.

[Premraj02]

@gautam-dev-maker
Those are the duty cycle values at which motors start rotating.

Tomorrow I will try DRV8833 at 12V.

Also, I will try to check the noise frequency using oscilloscope.

[gautam-dev-maker]

@Premraj02 kindly post all the updates here.

[Premraj02]

@dhairyashah1 @gautam-dev-maker
Updates:

1. Tested DRV8833 at 12V supply:
   At 12V DRV8833 seems to operate normally without any heating. But the total output current is limited to 1A only. Thus the motors are still slow. I2C issue did not occur.

2. Noise frequency:
   Checked the noise frequency on oscilloscope and it was found to be 6.25 MHz on average and 7MHz max. After this test I also tested SMD ferrite beads (UPZ2012E121-4R0TF) but these ferrite beads aren't designed for 6.25-7 MHz frequency range, so no significant difference was observed.

Next I will be testing effect of PWM frequency on motor noise.

Attachments:

1. Oscilloscope reading of input to motors (yellow) and noise due to motors (blue):
   

[dhairyashah1]

https://youtu.be/fGtXZA5SEDI
@Premraj02 we can test and try -

1. Ferrite core inductors across motor terminals
2. Rc filter
3. Snubber circuit ( rc in series ) || diode

[dhairyashah1]

@Premraj02 post the updates, findings, conclusions and test performed so far here

[Premraj02]

Updates:

1. I tried various inductors (in range of 22uH to 220uH) in series with motor as well as power supply of motor driver. But the error still occurs.
2. Then I tried different RC, LR, LC filters inline with motors. But these filters didn't work.
3. After this I tried shielding the MPU wires. It eliminates the noise on some SRA boards but the results are inconsistent and it doesn't work on every SRA board.
4. Yesterday I tried connecting MPU directly on SRA board using short wires. I tried connecting MPU on OLED port as well as on MPU port and the results were positive. It completely eliminates the error and works on every SRA board. If we proceed with this solution then self balancing code should be modified to compensate the offset in MPU position.

Conclusion: Connecting MPU direcly on SRA board was the best solution found. To test this solution deeply, we will need to prototype one SRA board with onboard MPU connector.

Attachments:

1. MPU connected on OLED port:
   

2. MPU connected on MPU port using short wires:
   

[Premraj02]

Summary of tests performed till now:

<style type="text/css"></style>

Test	Error status	Remark
Implemented motor driver and mpu system on breadboard	error still occurs	issue is not related to noise on SRA board or routing
Replaced TB6612FNG with DRV8833(at 9V)	error did not occur	DRV8833 supplies less power to motors. Thus motors become slower. If we proceed with this configuration, one more voltage regulator will be needed on SRA board.
Replaced TB6612FNG with DRV8833(at 12V)	error did not occur	DRV8833 did not heat up but it still delivers less power to motors.
Added extra bypass capacitor on VM pin of TB6612	error still occurs	no effect on noise
Measured noise frequency on oscilloscope	-	noise frequency is around 6.25-7 MHz
Tested SMD ferrite bead (UPZ2012E121-4R0TF) on motor wires	error still occurs	no effect on noise
Tested inductors (22uH to 220uH) in series with motor wires	error still occurs	no effect on noise.
Tested inductors (22uH to 220uH) in series with ground pin of TB6612 FNG	error still occurs	no effect on noise
Tried RC, RL, LC filters on motor wires	error still occurs	motors don't get enough power when 50 ohm resistor is added in series (RC filter), no effect on noise.
Tested aluminium foil shielding on motor wires	error still occurs	no effect on noise
Tested aluminium foil shielding on MPU wires	inconsistent observations on different SRA boards	not reliable method
Connected MPU on oled port using short wires	error did not occur	this method solves the problem but transformations MPU readings will be needed
Connected MPU on MPU port using short wires	error did not occur	this method solves the problem but transformations MPU readings will be needed

[Premraj02]

Updates:

1. Tested 6 core shielded cable to connect MPU with SRA board. When the shield is properly connected to ground, it eliminates the effect of noise. This method solves the issue but does not eliminate noise. Thus other components can still malfunction due to noise.
2. Tested 4 core shielded cable to connect motors with SRA board. This method eliminates the noise completely and solves the issue. It also ensures that other components won't get affected by noise. I have performed rigorous testing and no error occurred. I also tested self balancing and the bot is able to balance perfectly.
   Currently I have connected the cable shield to ground by using terminal block on SRA board.

Conclusion: By using 4 core shielded cable to connect motors, we can completely eliminate the noise.

Attachments:

1. 4 core shielded cable:
   

2. Motors connected to SRA board using 4 core shielded cable: