sra-board-hardware-design
sra-board-hardware-design copied to clipboard
SRA-VJTI
Solve the noise issue in PCB due to motors
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.
@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.
HOW TO REPRODUCE THE ISSUE:
- Place no ferride bead and capacitor on the Motor drivers
- 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.
- Read the MPU6050, and look for readings when the above situations has been created.
WHAT TO DO:
- Currently we are using TB6612FNG, so first step will be to reproduce the issue as mentioned above.
- 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.
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:
-
The I2C bus when observed on DSO looked pretty fine. Both the lines go high while reading data.
-
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.
-
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.
- 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
@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.
@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.
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.
I will be taking up this task, though a small meet before getting started would be helpful.
@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 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
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.
@omsheladia
- This is nothing new but already known.
- If you didnt have walle kit why didnt u get it asap when the task was assigned?
- 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.
@dhairyashah1 I was told just to reproduce the results first and then test it with the new motor driver.
@omsheladia was this tested on drv8833 or tb6612fng Also testing must not have taken this much time.
@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.
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?
I was informed in person today to carry out the same thing on a breadboard i.e. without using the sra board.
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.
@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.
@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.
@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.
@omsheladia pls specify what was that some solution ? Be clear, talking with links, demos, results or conclusions is desired.
@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.
@dhairyashah1 @gautam-dev-maker
Updates:
- 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:
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:
-
Typical application diagram of TB6612FNG:
-
Additional capacitor:
-
Output without additional capacitor:
-
Output with additional capacitor:
@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:
- Maximum current consumption of single motor at 9V on 90% duty cycle:
