DC motor control problem

[ultrablaze]

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. 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 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

[Fr0stAngel]

I have a few questions before i may be able to answer:
1- what h-bridge are you using?
2- have you isolated the arduino from the motor driver supply (isolation beetween +5V supply to arduino and the 24V motor supply) using optical isolators?
3- if there is no isolation, is the GND for the 5V arduino and the GND for the 24V motors put together to form a common reference?

From what i can think of, this may be due to the following reasons:
1- The H-bridge is not working the way it should be (which happens sometimes when it is fabricated by students themselves instead of using an off-the-shelf solution due to some fault)
2- Arduino and the motor supply are at different reference points (no GND common)

[ultrablaze]

1. Here is the H-bridge being used : https://www.sparkfun.com/datasheets/Robotics/L298_H_Bridge.pdf
2. Yes we are using optical isolators to seperate them
3. Yes we have a common ground which is connected to the metal body of the robot

I've got 3 oscilloscope pictures, in descending quality of signal :
- 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

[ultrablaze]

Here are our Isis schematics if they are any help. We have one electronic card with 2 arduino Megas and one that handles all the power for our robot. The ground is all common with the metal hull of the robot.

[jwatte]

If you're not getting power, this means that the motors want to draw more current than what is being delivered. This could be because the power source is not capable of delivering the needed current, or because the driver limits the current, or because some wiring problem.

What you're suggesting sounds like perhaps the H-bridge is doing current limiting.
Also, if you have +/-24V, that means you have 48V total differential, which is a lot, more than the 298 is specced for.
H-bridges generally work with a ground input and a positive input, and switch around which side sees the ground and which side sees the positive.

[ultrablaze]

Yes, I was unclear in my initial post. It is indeed a +24 voltage being delivered that is switched around to -24 or +24.

It was pointed out on another forum that our sensor resistors are at 22 Ohm when the datasheet for our H-bridge seems to specify 0.5 ohm as a max. Indeed, my friend covering that part of the electronic card design may have misinterpreted 0.22 ohm (R22) as 22 ohm (22R).

This would totally explain for the massive voltage drop on the motors when we place it on the ground : the current required is higher, and limited by this sensor resistor and thus we have the voltage drop.

We will test this theory out and get back to you all with feedback, but we are open to all comments on this theory / other ideas.

Thanks for your input in any case!

[jwatte]

Yes, if it's 22 Ohms, that won't work. Anyone familiar with Ohm's law should realize that an ampere through 22 Ohm will drop 22 Volts, and thus leave nothing left for the motor.
Ohm's law: It's probably the most useful thing to remember in electronics!

[ultrablaze]

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.

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 drives slowly.
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.

[ultrablaze]

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.

The main issue here seems to be our rotary encoders that arbitrarily are extremely accurate or are way off. They were used effectively by robotics teams the last couple years with a nearly identical setup so we are very confused as to what it causing us problems. I can't find the datasheet for them currently but I will try to locate it.

We think it might be a problem with interrupts being used for the encoders as well as at set intervals to calculate the new motor command value using our PID setup based on the position error we have from our odometry.

We spent hours testing and it makes no sense. We lift the robot off the ground, and we decreased the time between each interrupt routine call that calculates new motor command, and when we turned the encoders a full turn they were extremely accurate.

We then added lots of extra heavy calculations to this interrupt routine / increased the frequency with which the routine was called, and in both cases this lead to our encoders needing more then a full circle to get to the expected value. This seems like behaviour that would be coherent with some interrupts from the encoders being dropped / missed.

We originally had a heavy calculation function based on our matlab simulation of the automatic control, which had a lot of floats and whatnot. We had the idea that maybe this was to demanding of a function in an interrupt routine, so as a test in the interrupt routine we called these calculations 3, 6, etc times and each time the amount of distance required by the encoders to reach the value of a full circle increased.
When we called the interrupt routine with no code in it, they seemed perfectly accurate again.

So we thought great, this is the issue. We then recoded in a much lighter way, with mostly ints and fewer calculations. Tested the encoders with the robot raised, seemed extremely precise, great!

Put the robot on the ground and let it drive : exactly the same, it overshoots the 30cm or whatever command we give it by a fair amount because the encoders seem to be dropping ticks....

So we're pretty stuck...
And this thing is supposed to be done and finished in about 32 hours max >.<

edit : here are the encoders we are using : http://docs-europe.electrocomponents.com/webdocs/0173/0900766b801738c2.pdf

[jwatte]

We think this might also be due to an issue with interruption handling through our arduino

Quite likely your interrupt timing is jittery, so you miss ticks on the Arduino side. Writing high-performance quadrature decoding on a stock Arduino is hard for high tick rates.
You can get a sense of the timing of your code by inverting a digital out each time through the loop function, and measuring the cycle time, as well as measuring the jitter in the cycle time of that pin.