ultrablaze
Hello,
We are a team of engineering students working on a robotics project about to participate in a robotics competition. We have only a few days to finish up and 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
Yes for this robot and the first smaller one, the picture of the signals on inA and inB for our left motor is img3 in the archive I attached to the previous post. It seems to be working fine.
Not sure what you want me to check exactly, but it's past midnight in France we've called it a night and gone home so all further testing will be done tommorow.
What do you mean by the motor controller? The only two circuits we have are the two pdfs I included in the archive. If you mean the automatic control system for generating motor command, we coded and simulated it in Matlab and have now coded it into C on the arduino. We're using odometry and correcting motor speed command by both position and velocity. Currently we have not hooked it up to our actual motors to try it yet, we wanted to make sure we could actually get the robot to move forward first.
Calling it a night for now, class in around 6 hours
I will be sure to get back to you all tommorow with updates and any more info you might need in case the resistor issue isn't the cause of our troubles.
Thanks to everyone for all the help!
I'm pretty sure when DJ said "Motor Controller" he meant your H-Bridge.
Definitely interested to know how you solved this one! Let us know, and good luck 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. 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 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.
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.Easy_Slave_V5.zip
Sorry I haven't had a chance to look at the code but I was going to ask if you had noise decoupling capacitors on your motors, like a 0.1uF from each motor lead to the motor chassis and one across the motor leads as well? These help to cut down motor noise, but you do have high quality motors so I'm not all that certain that it would make too much of a difference.
Are you doing any kind of averaging of the encoding values that are coming in? Taking several samples and then averaging the result out usually helps diminish spurious values.
I will ask the guys in charge of the electronic cards about the capacitors and let you know.
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
One thing that may help and something I've ran into in my previous experience with Arduinos is that you can't call delay functions such as millis() and micros() when using interrupts as the timing will be off every time an interrupt occurs, see here for more info, looks like you can use delayMicroseconds() instead as it doesn't rely on interrupts.