Urgent DC motor control problem - Page 1
Forum section: electronics / projects

author: ultrablaze
author_rank: Contributor
timestamp: May 25, 2014, 03:54:37 pm
content: 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 withthe DC motors for our second robot and 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 allaverage 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 turnfine, 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 previouslydrops 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 around3V.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 5Von 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 motorsand 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

author: Richard Crowley
author_rank: Super Contributor
timestamp: May 25, 2014, 04:01:34 pm
content: It will be very difficult to attempt any help without AT LEAST a schematic diagram of your motor-control circuit, including how it is connected to the Arduino, and the complete power scheme.Verbal descriptions of waveforms are a very poor substitute for actual images.A listing of the motor-control code would also be beneficial for people willing to help you.When you talk about "-24/+24 V" do you actually mean that you have a +24V supply (relative to circuit ground) and ANOTHER -24V relative to circuit ground? Or do you simply have a 24V supply with a + and - side? Again, a proper diagram would instantly resolve this ambiguity.

author: G0HZU
author_rank: Super Contributor
timestamp: May 25, 2014, 04:12:39 pm
content: Not sure if this helps but a few years ago I designed a dual motor control system for my neighbour for controlling a radio controlled paddle steamer.One of the early issues I had was with RFI from the motors. Basically, the radiated interference from the motors was getting back into the system and was corrupting the control. So it was jamming itself and the PWM waveforms went crazy. But the symptoms for this are quite obvious when it happens so maybe this isn't the same problem you have...The cure for me was to make sure the motor connections were filtered with capacitors and to make sure the motors were kept away from the other electronics.

author: ultrablaze
author_rank: Contributor
timestamp: May 25, 2014, 04:29:33 pm
content: What Gohzu said is one thing we considered, the motors are quite close to the rest of our electronics. We do have the motors encased in a thick casing that is in theory supposed to block interference but it might not be as effective as it's supposed to be. How did you mean to hook up the capacitor to power our DC motors?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 replies, 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

author: Paul Price
author_rank: Super Contributor
timestamp: May 25, 2014, 04:35:12 pm
content: Is the 24V power supply capable of supplying the required power? Does the 24V power supply voltage droop dramatically when powering the motors? Do you have sufficient voltage to turn on the top MOSFETs of your H-Bridge?

author: TopLoser
author_rank: Unknown
timestamp: May 25, 2014, 04:41:28 pm
content: What frequency are you working at? Too high and the inductance of the windings won't let the current rise to anything like the level you expect - and it's the current through the windings that matters not the voltage.

author: ultrablaze
author_rank: Contributor
timestamp: May 25, 2014, 04:47:27 pm
content: The voltage doesn't drop from the generator whether the robot is raised or placed on the ground. It would seem like the voltage is sufficient even when placed on the ground and the motor isn't able to turn the wheels since we can observe a 0 - 24V pwm signal on the motors with an oscilloscope even if the signal is kind of messed up at this pointWe are functioning at 31kHz currently. 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.

author: Andy Watson
author_rank: Super Contributor
timestamp: May 25, 2014, 04:53:54 pm
content: I would be paying particular attention to the ground and power supply arrangement. The circuit diagram suggests that arduino and motor control grounds are linked together at the opto-isolator, aside from any other ground that might exist. I would be using the opto to break at least one potential groundloop.

author: mtdoc
author_rank: Super Contributor
timestamp: May 25, 2014, 04:54:27 pm
content: As PP alludes to, perhaps your power supply is not able to deliver the required current. Have you load tested it?

author: Paul Price
author_rank: Super Contributor
timestamp: May 25, 2014, 04:56:46 pm
content: BTW, use a cellphone camera to get a quick scope screen shot. Seeing a waveform live is worth a thousand PWM's acting dead.My best guess now is you are giving the H-Bridge incorrect switching sequences.

author: rob77
author_rank: Super Contributor
timestamp: May 25, 2014, 04:59:49 pm
content: Hi there,is there a specific reason why are you trying to do 31kHz PWM ? the duty cycle matters not the frequency while driving motors. i would suggest to significantly decrease the frequency and focus on the driving circuit and software/code. to be honest i'm not getting your +24 and -24V point... usually when you drive a motor , you do it with a H bridge (the bridge switches directions) and you modulate the bridge control with your PWM signal. there is no need for negative power supply (the H bridge is reversing the polarity for the motor).sorry for saying this, but to me it looks like you are facing an issue with your design.Rob.

author: Paul Price
author_rank: Super Contributor
timestamp: May 25, 2014, 05:05:30 pm
content: Rob77:The original poster says"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."

author: ultrablaze
author_rank: Contributor
timestamp: May 25, 2014, 05:13:07 pm
content: Indeed, as Rob said. I mispoke in the initial post. We use this same system to drive a smaller robot and it functions fine with different motors, etc. We based it off a previous years card design that used an H bridge in a similar way. And we are able to power the motors fine with the robot lifted off the ground.We chose 31Khz since the H bridge is supposed to function between 20 and 40khz (according to the datasheet) and with an arduino you can't configure for any frequency, just for a few set values through a prescale register.We could modify the code to drop it to 4kHz if you think this would help?Other possible values :prescaler = 3 ---> PWM frequency is 980 Hz (default value)prescaler = 4 ---> PWM frequency is 250 Hzprescaler = 5 ---> PWM frequency is 60 Hzprescaler = 6 ---> PWM frequency is <20 Hz

author: Paul Price
author_rank: Super Contributor
timestamp: May 25, 2014, 05:17:14 pm
content: if you are using motor current feedback, it might be that a turn-on spike is exaggerating the actual motor drive current and a simple R-C filter or software time delay might fix an over reaction of the control scheme to drastically reduce the motor current.I don't think you have any problem with the PWM frequency. Leave it as it is.

author: Paul Price
author_rank: Super Contributor
timestamp: May 25, 2014, 05:27:07 pm
content: Have perhaps some problem with the enable inputs on the H-Bridge? If they are somehow floating or not pulled to their correct Enable logic level you would have big problems.

author: ultrablaze
author_rank: Contributor
timestamp: May 25, 2014, 05:39:20 pm
content: So for the different replies :We are only beginning courses based on more advanced circuit design and are not really clear on what a ground loop is and how to avoid it. We have one common ground for the entire robot in theory, which is connected to the metal body of the robot.We are not using motor-current feedback.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

author: rob77
author_rank: Super Contributor
timestamp: May 25, 2014, 05:48:27 pm
content: seems your supply is not providing enough current. can you post the waveform of the current passing through the motor ? connect a small resisitor (approx 0.1R) and hook your scope probbe acros that resistor. and do it it both cases - lifted (no load on wheels) and not lifter (wheels loaded).

author: Paul Price
author_rank: Super Contributor
timestamp: May 25, 2014, 05:49:25 pm
content: Since you do not show the power supply voltage simultaneously with the motor drive waveforms, some doubt I have about the 24V supply, but it looks to me like either you have a problem with terminating the current sense pins or the enable pins or perhaps just a bad H-Bridge chip.You can see from the waveforms that nowhere near the correct output voltage is being developed across the motors, particularly the positive excursions, that means the H-Bridge is not able to deliver the current, but since you say you measure only a small current (.2A) being delivered to the motor with the thing trying to move on the ground, the H-Bridge must be at fault if the enable and current sensing and power supply are not.

author: Paul Price
author_rank: Super Contributor
timestamp: May 25, 2014, 05:53:39 pm
content: If your input levels to the H-Bridge IC are correct, then you got a bad H-Bridge.You can connect a motor directly to your 24 volt supply and see feel the torque and loaded power supply voltage levels.

author: ultrablaze
author_rank: Contributor
timestamp: May 25, 2014, 06:11:36 pm
content: But on the first capture, the H-bridge seems to be delivering perfectly fine signals, no? So it doesn't seem like the problem is a dead H-bridge?And even if there was an issue with it, wouldn't it happen to just one output or something? we have exactly the same issue on both motors simultaneously.We are going to try and do the hook-up with the resistor and get the current with our oscilloscope.We are totally stuck here and not sure what to do to fix this problem.

author: rob77
author_rank: Super Contributor
timestamp: May 25, 2014, 06:12:05 pm
content: ok. i hade a closer look at your schematics... (it's a bit messy, but for a student it's ok).1. 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.2. minor/medium issue - the motors are rated at 0.5 Amps , but your bridge is rated at 4 amps total (2amps per bridge). the current peaks during switching on (especially under load) will be well above the rating of the bridge - probably destroying the bridge quite quickly.

author: Paul Price
author_rank: Super Contributor
timestamp: May 25, 2014, 06:20:24 pm
content: the H-Bridge is not able to deliver the current, but since you say you measure only a small current (.2A) being delivered to the motor with the thing trying to move on the ground, the H-Bridge must be at fault if the enable andcurrent sensingand power supply are not.The 22R current sensing resistors are limiting the current and causing the problem. The should be .22-ohm not 22-ohm.

author: rob77
author_rank: Super Contributor
timestamp: May 25, 2014, 06:27:32 pm
content: according to the datasheet you should use 0.5 Ohm for 2Amps limit. change those current sensing resistors and let us know the result. i think we're all curious

author: ultrablaze
author_rank: Contributor
timestamp: May 25, 2014, 06:32:02 pm
content: This seems like it could definitely be our problem or atleast part of it!However, we are currently not at our lab but working from a garage so we don't have access to a supply of resistors, etc.For now, could we get away with short circuiting the resistor with a wire and trying to see if it works? Since 0.22 ohm is so small anyway.We would atleast know if this solves the problem.For the damage to the H-bridge you mentioned, we have coded an automatic control system that in theory should prevent any large variations of the values applied to the motors (progressive increase / decrease always). That should help avoid doing damage to it and keep it functioning for a while, right?We have spares just in case though.

author: Paul Price
author_rank: Super Contributor
timestamp: May 25, 2014, 06:35:28 pm
content: The current sense resistors are not needed, they can only function as fuses if your system is not using the current sensing in your drive software, simply short them out. The IC has overtemp protection.

author: rob77
author_rank: Super Contributor
timestamp: May 25, 2014, 06:39:02 pm
content: if you correctly size the current sensing resistors it should run for a while, but for a production unit i would definitely go for a different H bridge - rated at least for 5 Amps.regrading the small resistor, if you desperately need one - just tear apart a wire resistor if you have one (some of the power resistors have a resistive wire in them) and use a piece of that wire - calculate the needed length. another good source would be a old heating element - remove the wire from it - measure the resistance & length and calculate the needed length for your 0.5 ohm.i would definitely not go for the short circuit ! you would be on the best route to blowing your bridge.

author: Paul Price
author_rank: Super Contributor
timestamp: May 25, 2014, 06:41:30 pm
content: I think it is ok to short out the sense resistors since the IC internally limits the current output so that only power dissipation can then provide a path to H-Bridge downfall..but the ic is thermally protected.

author: rob77
author_rank: Super Contributor
timestamp: May 25, 2014, 06:50:44 pm
content: agree - those are thermally protected, but that helps only in slight to moderate over-current scenarios. in case of good old short circuit the power mosfet/transistor will heat up quite quickly - destroying itself well before the thermal shutdown. i've seen a couple of thermal protected ICs silently fading out or vigorously flying across my bench

author: ultrablaze
author_rank: Contributor
timestamp: May 25, 2014, 06:52:10 pm
content: We've found some 10 ohm resistors, if we put in one of those or possibly 2 parallel for 5 would this be ok? We were hoping to all-nighter this once we got it running and do as much of the coding and AI testing as possible today.We could atleast see if this fixes the problem and know if we've solved the issue or is 5 still to high? For when we get access to the lab, you say we should "correctly size the current sensing resistors", how exactly do you mean?Just for reference the two of us working on this atm were mainly in charge of coding and whatnot but are currently stuck trying to fix an apparently electrical problem ^^'

author: Paul Price
author_rank: Super Contributor
timestamp: May 25, 2014, 06:56:50 pm
content: Sense resistors should be as low as possible. 5ohm is too large. Fractional values <.5ohm would be appropriate if you were using the current sense at all..but you are not, so short these pins to ground.Even if you keot .22 ohm sense resistors in the H-Bridge circuit, they are not large enough in value to prevent destruction of the H-Bridge output transistors, so internal current limiting is the only hope of protection anyway you look at it.The chip probably has this built-in.I use N-Chan MOSFET bridges for motor drives that can deliver 8-16amps yet safely handle short 60-amp overloads and much larger short instantaneous surges while never even getting warm. Too much power is being dissipated in a BJT bridge.

author: oldway
author_rank: Super Contributor
timestamp: May 25, 2014, 06:58:29 pm
content: Did you not forgot the 4 ultra fast diodes for free wheeling ?

author: ultrablaze
author_rank: Contributor
timestamp: May 25, 2014, 07:00:42 pm
content: We have the 4 diodes for free-wheeling, just waiting on a response about the value of resistors before taking it apart and going to work resoldering ^^We will get back to you with the test results asap after.

author: Paul Price
author_rank: Super Contributor
timestamp: May 25, 2014, 07:00:54 pm
content: Sensing resistors are used for providing some feedback that can modify drive (PWM duty cycle) to limit current, they are not intended to limit current by their own resistive value.

author: rob77
author_rank: Super Contributor
timestamp: May 25, 2014, 07:05:39 pm
content: according to the datasheet of L298 the recomended value (the reference design in the datasheet) is 0.5 Ohm for 2 Amps - therefore you should have a voltage drop of 1 Volt across the sensing resistor during the max allowed current scenario.but anyways you can try the 5 Ohms and see if you will do any better than with a 22Ohm - you should be observing at least some signs of movement when the vehicle is not lifted. but be prepared that you will have a significant power dissipation on those resistors.

author: Paul Price
author_rank: Super Contributor
timestamp: May 25, 2014, 07:14:57 pm
content: the reference design only shows these sense resistors as a suggested max. value for sensing bridge current, if you are using that function in your control loop. They may not be needed for safe operation of the chip unless the chip internally uses this sense voltage for current limiting. The spec sheet does not give any indication of this.If you have .5ohm sense resistor, then 1V volt peak will be developed across the resistor at 2-amps. An internal circuit that would sense this current limit voltage, but would likely need only .7V to fully turn on a NPN transistor to limit the base drive current to the bottom H-Bridge drive transistors. So a .33 resistor might be the optimum max value of the sense resistor(to not waste power)..if there is in fact an internal current limiting circuit getting feedback from the external sense resistor.I have not read the ap-note for this device. The spec sheet suggest the H-Bridge can deliver max 3A peak and this is not consistent with the sense resistor value.The spec sheet says,"This sense voltage can be used to control output current by chopping the inputs."This is an euphemism for PWM.

author: rob77
author_rank: Super Contributor
timestamp: May 25, 2014, 07:29:28 pm
content: i haven't read it eitherjust had a quick peek at the datasheet.in the block schematics there is "Vref" block and the pin description for the current sensing says literally "Between this pin and ground is connected the sense resistor to control the current of the load." so i assume the bridge is limiting the current itself.

author: Paul Price
author_rank: Super Contributor
timestamp: May 25, 2014, 07:34:43 pm
content: In any case a .5-ohm sense resistor value seems to be max. value needed or should be used for the H-Bridge to internally limit output current.

author: ultrablaze
author_rank: Contributor
timestamp: May 25, 2014, 09:14:35 pm
content: Right, well I'm fairly sure the lowest resistors we have are 1 ohm, I guess that will have to do? We will ask around to see if we can find something in the 0.33 - 0.5 range but I'm doubtful. You say 0.5 is max, but that should lead to a 0.5V drop per motor right? We dont need to get anywhere near 0.5V below max voltage in theory (around 18 compared to the max of roughly 22.5V), so a 1V drop from a 1ohm resistor should be ok? Please tell me if I'm misunderstanding.My friend thinks we may only have 10 or even 12 ohm as our lowest... In this case I guess we will go with cutting the wire bit from a resistor and using that? I think that's somewhere in the 1 ohm ballpark, even if we risk blowing our H bridge quickly.We will get some sleep for now, put it in tommorow and be sure to get back to you all with feedback whether this fixes it or not.Thank you so much in any case for all your help everyone, if this is the issue we were stuck on and this fixes it, you will have totally saved us!Just for some background, we're a group of 4th year engineering students who are participating in the French national robotics competition which is taking place on wednesday, so time is kind of limited to get everything up and running in time! ^^Here are the official rules in english if you happen to be curious :http://www.planete-sciences.org/robot/data/file/coupe/2014/Eurobot2014_Rules_EN_Final_Version.pdf

author: Paul Price
author_rank: Super Contributor
timestamp: May 25, 2014, 09:50:03 pm
content: A .5 ohm resistor would create a 1-Volt drop at 2 amps but that drop would have to be added to the saturation voltage of both the top and bottom driver transistors at 2-amp (approx 3.2V) leaving your 24V supply to the motor only supplying 19V P-P and the device dissipating >10W of wasted heat.If you have 1-ohm resistors, parallel a pair of them to get .5 ohm. This somehow assumes this sense voltage is being used by the H-Bridge chip to control output current, but there seems no datasheet info to show that the sense resistors do that at all.From all that I can see from the functional diagram for your existing BJT H-Bridge device,the sense resistors can be eliminatedas they seem to be only for sensing current for some method ofexternalcontrol of current. In figure 8 on the datasheet(, the sense resistor output is connected to a helper driver IC input to control output current.A good H-Bridge is not that hard to find that can really deliver the goods. See the attached.

author: tautech
author_rank: Super Contributor
timestamp: May 25, 2014, 09:53:36 pm
content: After a quick read of this thread, it would seem you have made a common error.In your reference material there was probably mention of current sensing resistor value R22.This is interpreted as 0.22 Ohms.If it was intended to read 22 Ohms, it would have been listed as 22R.Simply put, the R signifies the decimal point.EDITAnd you will have to do current calculations to select correct Wattage for this resistorHowever if was on a commercial datasheet, it may have been a misprint.I have seen it before.

author: Kremmen
author_rank: Super Contributor
timestamp: May 26, 2014, 04:39:32 am
content: I haven't read every word in this thread but as there seems to be some confusion regarding the current sense resistors, let me offer this. Sorry if i repeat something that has been stated already.The typical use of L298 bridge circuit is together with the L297 driver. This combination is intended for driving stepper motors in simple full step/half step modes. In addition to providing the sequencing signals for the bridge, the L297 includes a current limiter circuit. This is a typical combo of an oscillator, RS latch and comparator to sense max current. See the L297 datasheet for more details.The point is that the L298 bridge itself does not need the sense resistors for anything. While they can of course be included and used in the context of DC motors as well if you want or need to control the max current of the motor, they are not a required part of the circuit. Simple pwm control will do perfectly fine without any sense resistors so you can just omit them. The indicated values are strictly for achieving the nominal max bridge current when used in combination with an L297.If you do want to limit the max current then the indicated resistance has no significance unless you use the L297 (and that makes no sense in the context of a DC motor). So by all means select a lower resistance to avoid excessive power loss, and adjust you limiter circuit accordingly.

author: H.O
author_rank: Frequent Contributor
timestamp: May 26, 2014, 05:35:38 am
content: Hi,Haven't read every post in detail but I don't think this has been mentioned.Why are the anodes of D8-D11 connected to the sense outputs of the L298? They should be connected directly to GND. If you decide to short out the sense resistors (which, as has been mentioned, is perfectly fine if you don't need to, well, sense the current) then I guess it's not a problem from a pure schematic standpoint. However PCB layout is important too, especially your GND returns. You probably also want some bulk capacitance on the Vs pin of the L298, I don't think 100nF is enough. Add something like a 100uF-470uF electrolytic.

author: ultrablaze
author_rank: Contributor
timestamp: May 27, 2014, 04:37:39 am
content: Well we switched out the 22 ohm resistor for a 0.22 ohm resistor and that fixed the problemThe robot now moves forward easily. Clearly during the electronic card design R22 was misread as 22R :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 targetdistance 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 thecontrol function calculation-Interference between the twoJust 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 ourencoder wheels...We have no idea what is wrong once again.

author: H.O
author_rank: Frequent Contributor
timestamp: May 27, 2014, 05:23:17 am
content: Hi,I don't "do" Arduino and haven't looked at the code but if the encoders are read by software it's quite possible that the software isn't able to keep up, missing transitions as a result. Even if it's an interrupt driven system there's (obviously) a limit to how fast the system is able to read the encoders reliably.It sounds as if you have a timer interrupt which, when fires, poll the encoder inputs. I don't think that's a good solution. You need to implement interrupt on change on all four encoder lines so that any change on any line causes an interrupt, read the state and decode.Or, if you DO have an interrupt on change kind of thing implemented then whatever you're doing with the timer interrupt might be blocking the "encoder interrupt" from fireing.Just thinking out loud, hopefullt someone more proficient than me at reading Arduino code will be able to take a look and see if any of the above might be valid.

author: ultrablaze
author_rank: Contributor
timestamp: May 27, 2014, 05:42:42 am
content: "Or, if you DO have an interrupt on change kind of thing implemented then whatever you're doing with the timer interrupt might be blocking the "encoder interrupt" from fireing."That seems like a possibility for the issue that we have been trying to confirm but not so much luck. We have interrupt on change on all four encoder lines in place.We use flexiTimer with an interrupt driven function call at different periods (tried from 50ms to 500ms) that calculates motor command based on current position deduced from encoder values compared to the position error.

author: ultrablaze
author_rank: Contributor
timestamp: May 27, 2014, 06:15:02 am
content: 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

author: rob77
author_rank: Super Contributor
timestamp: May 27, 2014, 08:06:26 am
content: i think your problem is yet another flaw in the design... the encoders you're using are 160kHz max pulse rate - no way to handle that with arduino.and furthermore i doubt you need that level of accuracy. as a quick fix i would suggest to put frequency dividers between the encoders and the arduino - you will decrease the accuracy , but you'll be able to handle the interrupts.

author: Kremmen
author_rank: Super Contributor
timestamp: May 27, 2014, 08:14:01 am
content: One thing that comes to mind is that your interrupts will not occur at even intervals. The rising edges occur at 90 degree intervals and then there is a pause of 270 degrees until the next pair. This combined with the very inefficient way Arduino handles the interrupts plus the neighboring channel plus the relatively dense encoders (1024 ppr) could result in missed interrupts. Especially as the interrupts come from 2 mutually asynchronous sources and during the ISR other interrupts are disabled.So, i suspect timing issues in the interrupt handling. One suggestion would be to change the logic such that you only interrupt on one channel but for both rising and falling edges. That way the interrupts are spread more evenly in time. Other ways to optimize would be to bypass the Arduino interupt atachment mechanism and specify the ISR directly at source level (as specified by AVR-gcc). And lastly one could try enabling interrupts again right at the start of the ISR, although that will result in overlapping interrupt services, necessitating re-entrant data handling.

author: rob77
author_rank: Super Contributor
timestamp: May 27, 2014, 09:00:26 am
content: i think they're in hurry - so redesign is not an option for them- hooking up a couple of dividers between the encoders and MCU + adjust the code for the different timing of the divided signal would be the fastest hack how to make it work.less is sometimes much much morefor motion feedback from wheels something like 40ppr is more than enough.. the 1024ppr encoder is good for CNC but not for wheels

author: H.O
author_rank: Frequent Contributor
timestamp: May 27, 2014, 10:41:58 am
content: Simple flip flop dividers on the encoder signals won't work if the goal is to reliably track position.Reduce the encoder resolution (ie change encoders) to the minimum needed for the application and/or "outsource" the encoder tracking task to a second processor (or dedicated quadrature counter chip) and read current position off of it with the main controller chip.

author: rob77
author_rank: Super Contributor
timestamp: May 27, 2014, 11:04:31 am
content: yes, i know - that's why i mentioned to change the code as well - you can't rely on the phase shift anymore if you divide the quadrature output.but considereing the few hours deadline they have , they don't have too much options left.personally i would go for the dividers and software change. or perhaps disconnect the encoders, glue a cardboard disk to the shaft with a few holes and install a couple of optical gates to make a encoder with lower resolution.but if i was the one designing it, then i would never ever go for such a crazy precision encoders and would never try to handle those with arduino

author: ultrablaze
author_rank: Contributor
timestamp: May 27, 2014, 11:58:28 am
content: Well these same encoders have been used several times before with an arduino mega with no problems as far as we know.When we roll our robot forward by hand the precision is perfect, over a 30 or 60 cm distance it's off by a couple mm. The arduino has no problem picking up the interruptions accuratelySo really there seems to be some issue with the way we are calling interrupts when we are trying to drive the motors, or some kind of interference from powering the motors

author: rob77
author_rank: Super Contributor
timestamp: May 27, 2014, 12:15:47 pm
content: check the ringing with scope. if there is a significat ringing on the supply rail , then it might be fouling the inputs. add decoupling caps everywhere. every IC sould have it's pair of decoupling caps 100nF ceramic + 10uF tantalum or or regular electrolyte(low ESR if possible) as close to the power pins as possible. and a hefty cap to the h-bridge power pins. if you have unconnected input pins (unused gates etc...) pul them down or up - do not let them float.

author: ultrablaze
author_rank: Contributor
timestamp: May 27, 2014, 12:51:55 pm
content: Right well we are curently on the road and Will Try this as soon as possible. We have a bunch of capacitors with us, hopefully the right values/types.Would you be willing to explain why you think this is the issue? We are only now having courses on electromagnetic compatibility for card design so not to familiar with it.This would lead to us dropping encoder ticks, and more for higher currents for higher speeds? This would fit with what we observed happening

author: rob77
author_rank: Super Contributor
timestamp: May 27, 2014, 01:22:42 pm
content: ringing could cause false encoder ticks - generating lot of false interrupts

author: Richard Crowley
author_rank: Super Contributor
timestamp: May 27, 2014, 01:53:09 pm
content: Quote from: rob77 on May 27, 2014, 01:22:42 pmYes, that is true. But the presenting symptom is the opposite. The controller appears to be MISSING "encoder ticks". I agree with the theory that it is a software problem. Inability to handle all the incoming signals for whatever reason.

author: IanB
author_rank: Super Contributor
timestamp: May 28, 2014, 05:13:57 am
content: Quote from: ultrablaze on May 27, 2014, 06:15:02 amI think you've looked into this already, but as a general rule try not to doanycalculations in an ISRT. Confine the processing to setting a flag or incrementing a counter and then return. You should be in and out as quickly as possible. While you are in an ISRT you are potentially blocking other interrupts, including repeat invocations of the same one.The place to do complex calculations is in the main program loop where it is not holding anything up.