Hello,

We are a team of engineering students working on a robotics project about to participate in a robotics competition. We are currently having a problem with the DC motors for our second robot and we don't have much time left.

We are trying to drive two DC motors to move the robot using PWM signals sent from an arduino card. Using an H bridge we are able
to deliver PWM signals with a controllable duty cycle from the arduino card, which are -24V/+24V. Thus in theory at 50% the motors are at 0V, and close to +24V or -24V
at 100% or 0% respectively by average voltage.
When the cables we use to connect to the motors are checked with an oscilloscope, the signals are fine and as expected.

When we connect our motors to them, the signals are significantly degraded (can tell its supposed to be a PWM cycle but it's not as clean as before) and the over all
average voltage is lower then what we had before. In this situation, with the robot lifted off the ground and the wheels not touching anything, the motors seem to turn
fine, at a decent speed etc. However the torque seems quite low, not as much as we should be getting from our motors.

The real issue is as soon as we place the robot on the ground, the wheels can not move. In this situation the expected rough 21.5V average voltage we measured previously
drops to around 3 to 3.2V. If observed at this point the PWM cycles are totally degraged, can barely make out a square signal, and the average voltage is around
3V.

We can not figure out what is causing this problem. When we connect our generator directly to the motors without going through our electronic card, as soon as we go above 5V
on a motor the wheel is able to move the robot easily, and at a decent speed above 7 or 8V. What adds to our confusion is another team last year used these motors
and drove them with a -24/+24 V PWM signal in the same way as far as we know.

We are totally stuck, and are available to answer any questions or provide any data that could help debug our issue.

Thanks so much for any help!

We are using the 2322G/GP022C motors from this datasheet, the last one (24V/1621) : http://store.mdpmotor.fr/media/documents/pdf/2322g_gp022c.pdf

 

We can not figure out what is causing this problem. When we connect our generator directly to the motors without going through our electronic card,

It sure would help if we knew what was on your electronic card.
Can you post a schematic?

 

The current for 2Nm output is trivial so I would expect you have some high impedance some where on the outputs maybe?
Are you measuring across the motor?
Max.

 

We are thinking it might be interference from the motors with the rest of our electronics because they are close, we do have a very thick specially designed casing around them however.

I've attached the ISIS schematics of our two electronic cards, the only link between them is the power supply connections. We are delivering 30V to our system from a generator for now for debugging, but we will be powering it with two 14,8V batteries which are connected in series if it eventually works.

We are going to take pictures of the waveforms on the oscilloscope now and add them ASAP. Thank you for your reply, we will try to provide you with all the information you need.

Without going into the detail of the code, we have configured the registers to generate 2 opposite-phase PWM signals at 31khZ generated from the same timer which we send to a H bridge powered with 24V. So we do not have a +24 and -24 source, we apply one or the other based on whether we want to move forwards or backwards.

Here is the H-bridge being used : https://www.sparkfun.com/datasheets/Robotics/L298_H_Bridge.pdf

 

We just measured 40mA being delivered to a single motor when the robot is raised, and 200mA being delivered to the wheels with the robot placed on the ground. The total vehicle weighs around 4-5kg currently.

 

If it wasn't for the fact you tested with a fixed DC voltage I would say your application is not supplying enough torque, So Check the current when supplying DC direct.
Max.

 

U6 is a quad opto that can do 50 ma all day but it has 680 ohm resistors protecting each output. At 31Khz, 680 ohms can interact with cable capacitance to degrade the fast edges.

I'm guessing you need less impedance on your driver.

 

We are going to check the currents with direct power applied to the motors and post it.

#12 : not really clear on what you mean / what we should try and do? I'm more in charge of the code side of things (only one who speaks english), but from what I understood the resistances and such were tested extensively and values based off a previous schematic that worked with the same components and motors.

I've attached 3 oscilloscope pictures, in descending quality :
- signals that arrive to the motors with them disconnected (after passing from the Arduino, through the optocoupler and leaving the H-bridge)
- signals with the motors attached but the robot raised from the ground (wheels turning with low torque)
- signals with the robot placed on the ground and wheels unable to turn

 

When we power with the generator on the motors, when we go over 5-6V the robot begins to move when its placed on the ground. The current is around 600mA.
So we are clearly not getting the current we need but we can't figure out why.

 

I don't know the voltage driving U6 so I was thinking about using less resistance than 680 ohms, as long as it won't burn up U6.

However, the scope pictures seem to say that the signal out of the H-bridge falls apart when you attach the motor. That seems to indicate a bad chip L298.

 

We got this response on another forum :

"major issue - the 22R current sesnsing resistors - thet bridge will never ever let you pass enough current with such a current sesing resistors. considering your motors (rated at 0.5 Amps @ 24V) you would loss 11 volds on those 22R sensisng resistors.
change those for something more suitable. according to the datasheet you should use 0.5 Ohm for 2Amps limit."

This seems like this might be the issue, we are going to try and test this now but are open to all opinions on this verdict / other ideas!

 

I don't think you posted the details of the H-bridge on this site, so I can't find those resistors.

 

I didn't see them?
Max.

 

You're right, didn't think to post it here.
Here is the H-bridge being used : https://www.sparkfun.com/datasheets/Robotics/L298_H_Bridge.pdf

 

That's the chip but it's not YOUR circuit.

 

I attached the PDF of our two circuits in my second post I'm pretty sure.
Anyway we will try this solution tommorow and get back to you with feedback! thanks for all your help!
They were way in the bottom right corner of the Alim card.

 

Ah. There we go. R12 and R13 on U7 which is an L298. And, yes, those 2 resistors limit the drive current. The datasheet shows those as 1/2 ohm. I think, "other forum" is on to the right answer.

 

I would say that if the H-bridge can drive the motor forward and reverse, there's no failure there. If it couldn't work at all, or only went one way, that would be different.

So I'd check the digital input to the PWM drive. Is it actually being driven with more than a tiny duty cycle?

Those scope pictures are hard to make sense of. If the scope has the ability to add and subtract signals, it would be more useful to see a single trace which shows the voltage across the motor, rather than two traces for the two sides (if that's what they are).

Edited to say, that question about the sense resistor seems to be the right one. 22 ohms when it should be 0.5 ohms will make a lot of difference!

 

Well we switched out the 22 ohm resistor for a 0.22 ohm resistor and that fixed the problem!
The robot now moves forward easily. Clearly during the electronic card design R22 was misread as 22R

We have however encountered a new issue we are once again puzzled by...
If we have the robot drive extremely slowly, the encoders are extremely accurate for our odometry when the robot.
However, as soon as we try to go at even a medium speed they are very far off from what we expect and so our robot ends up overshooting the target
distance by a considerable amount (thinking it has covered 30cm from the odometry when it has actually gone 35cm).

We are thinking this is from some kind of interference from the motors functioning at a higher speed and messing up the encoders ability to pick up values...?

It is odd though, these encoders + these motors were used last year and seemed to have no issue remaining accurate when moving at high speeds.

Hard to describe everything in detail that could be contributing to this issue...
We are trying to test many things and see what could be causing the problem. Any ideas are welcome.

Possible ideas we are pursuing to try and debug this problem :
-We think this might also be due to an issue with interruption handling through our arduino (4 interrupts from the 2 encoders + flexi_Timer_2 using one interrupt for the
control function calculation
-Interference between the two

Just now we had the robot raised, wheels turning full power, and if we turned the encoder exactly 1 full circle we got nearly exactly the right value, every time.
Depending on the sampling speed we use (as in how many times per second the interrupt control function is called), it seems to directly impact the accuracy of our
encoder wheels...

We have no idea what is wrong once again.

 

Here is one version of our code we are trying to use to function with the encoders to control our motors, not sure how clear it will be to someone trying to understand it. In this version we reduced the amount of calculations in the isrt by going with just tick values and sticking to ints as much as possible.

Ignore all the parts with EasyTransfer and data structures, that it just for sending values to our screen for debugging purposes.
You need FlexiTimer2 library in order for this to function.