Arduino encoder wheel missing counts at startup.

Go To Last Post
72 posts / 0 new

Pages

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0
Datasheets PEC12R Series
Standard Package ? 75
Category

Sensors, Transducers

Family

Encoders

Series PEC12R
Encoder Type Mechanical
Output Type Quadrature (Incremental)
Pulses per Revolution 24
Voltage - Supply -
Actuator Type 6mm Dia Flatted End
Detent No
Built in Switch No
Mounting Type PCB, Through Hole
Orientation Vertical
Termination Style PC Pin
Rotational Life (Cycles Min) 30K

 

 

Not very suitable  for the OP's application.

 

Letting the smoke out since 1978

 

 

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

And the answer is...

Lab results are complicated, dammit.

 

Part of the problem is motor run over. It doesn't stop when I tell it to stop. I put in two steps reverse and that fixes the run on for my particular motor at a particular speed. I'll need to instrument several motors and see if I can come up with a table to stop the motor at various speeds. And since these motors are so cheap, it may be necessary to calibrate each one. 

 

Another part is that Arduino, does in fact seem to be doing something in the background that is causing missing steps. I will need to write the code entirely in C to make sure this is a real software problem but I'm part of the way there so we'll see in a couple of days.

 

The circuit was rock solid as originally shown. Nard's suggestions made it rock solider, if there is such a thing, but there doesn't appear to be any significant noise in the system even at its simplest.

 

The Arduino is indeed plenty fast even doing polling in the loop. I generated an on off digital pulse and it's width is less than 1% of the rise/fall coming from the photo interrupter.

 

What I am going to do next is rewrite the code entirely in C and then scope that to see if it gets rid of the odd random missing steps that seem to be caused by the AVR going off and doing something in the background.

 

If that fixes the random missed step problem, then I'll just encapsulate the motor driver hardware with an ATmega328p with no Arduino code on it. I'll then communicate with it via I2C from an Arduino as an overall system controller.

 

After that, I'll see if I can get more data on motor run on and how to stop it in my particular case and maybe determine some more general methods for calibrating these cheap motors.

 

Joey - thanks for the code. Once I can get this thing working in regular C, I'll go back and try it again with the Arduino, so your code will come in handy at that time. My first task is to get it accurate, and then I'll put in some time to see if I can pinpoint the Arduino problem since it would be ideal if this could be made to run with the Arduino code. 

 

BTW, while it is great to have folks all over the world willing to help; nothing really beats having a smart guy with a well equipped lab sitting with you for an hour to scope out and discuss issues. He loaned me a digital scope that is far better for this application than my old analog beast. Thanks Rob.

 

 

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

Well, I just lost my whole post (f**cking stupid forum software!).  I'll try to recreate it but I'm pretty pissed :(

 

Part of the problem is motor run over. It doesn't stop when I tell it to stop. I put in two steps reverse and that fixes the run on for my particular motor at a particular speed. I'll need to instrument several motors and see if I can come up with a table to stop the motor at various speeds. And since these motors are so cheap, it may be necessary to calibrate each one.

I think you'll find that it will also depend upon the load placed on the motor i.e. mass of the robot, slope of the floor, type of surface (carpet v.s. hardwood), condition of the batteries driving the motor, etc.

 

This seems ripe for a more sophisticated control solution, perhaps PID.

 

Another part is that Arduino, does in fact seem to be doing something in the background that is causing missing steps.

The only things happening in the background are the servicing of the TIMER0 overflow interrupt, and the USART TX and RX interrupts.

 

The overflow interrupt runds every 1,024 us.  With Arduino IDE 1.0, AVR GCC 4.3.4, AVR Libc 1.6.7, Binutils 2.20, the WCE is 103 cpu cycles, or less than 7 us.

 

The RX interrupt shouldn't come into play at all since you're not sending anything to the Arduino.  Even so, the WCE is 83 cpu cycles, a little over 5 us.

 

The TX interrupt, which curiously calls __divmodhi4 to compute modulo 0x40 (with stated toolchain), has a WCE of 369 cpu cycles, or 23 us.  A more recent version of the toolchain might more sensibly use a mask instead of a call to __divmodhi4 and cut that down to ~100 cpu cycles, or ~6 us.  Even at 23 us it certainly shouldn't be an issue when counting edges which are no less than a few ms apart.  And bear in mind that the TX interrupt only fires while there are bytes left to send, and only every 10 bit periods.  At 9600 baud, that about every 1,041 us.

 

You can rule out the TX interrupt by calling Serial.flush() before starting the count for each leg, by avoiding any serial output after the motor has been commanded on, and by waiting a suitable period of time after commanding the motor off before sending any serial data.

 

I'd be very surprised if the Arduino runtime were having any real effect on your results.  I'd be interested to know if your pure C tests reveal anything interesting.

 

If your ongoing tests show that motor run-on doesn't fully explain your observations, I think something other than the Arduino runtime will be to blame.

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Poor Joey. Happens to me as well from time to time, ... losing a post. I don't swear a lot, but then I swear !

 

So, finally I can rest smiley

 

For next projects:

http://www.banggood.com/HC-020K-...

or

http://www.banggood.com/5Pcs-Spe...

Don't forget to modify the PCB's ! See earlier post(s)

 

Cheers

 

Nard

A GIF is worth a thousend words   They are called Rosa, Sylvia, Tessa and Tina, You can find them https://www.linuxmint.com/

Dragon broken ? http://aplomb.nl/TechStuff/Dragon/Dragon.html for how-to-fix tips

Last Edited: Mon. Apr 11, 2016 - 01:16 PM
This reply has been marked as the solution. 
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I think that I now understand the problems and this understanding implies a route to some possible solutions.

 

It is motor overshoot (as guessed by others, primarily Netizen and Joey Morin - thanks!)

 

Part of the solution is to ramp down the PWM at the end of the cycle and then throw it into reverse for a moment. The trick is knowing the ramp down steps and how long the 'moment' is. This varies with speed, if the moment is too long then the motor will step backwards - you want to have enough power to cause braking but not turning. All this is speed/motor dependent and will require individual calibration.

 

It is neither the Arduino code nor the hardware system noise.

 

This system will require calibration for various motors and uses. I think Joey nailed it again when he said that calibrating will depend on use. So the motor type, the speed or the inclination or whatever that influences the motor, will change the overshoot error.

 

The solution I'm envisioning at the moment involves an auto calibration routine that compares the encoder readings to the actual robot movement. That movement will be determined by two down looking QRD1114 reflective IR sensors on the front of the robot that, in normal operation, will be for line following and edge drop avoidance. They will be placed about three inches apart on the front of the cubot. A calibration sheet will be printed with a series of parallel lines that will be taped to the floor. The robot will be placed near the page and then will run the calibration application. It will approach the page and using the two sensors, it will square up with the first line. Next it will run across the lines and compare the count of the number of lines with the encoder counts of the number of steps. It will then use this 'ground truth' to calculate that actual distance traveled as a function of steps and use that data to calibrate the encoder steps to distance traveled.

 

I will look at Brett Beauregard's PID libraries: http://playground.arduino.cc/Code/PIDLibrary to see if this will be useful for my needs.

 

I am now confident enough to finish the cubot design and build version two and use it as a test bed for further development. I am certain that I will find more problems, but at least now the project looks doable with a decent accuracy.

 

Take home learning:

1.Listen to Joey Morin when he speaks.

2.Get a good digital scope attached to the design EARLY - you'll waste less time blaming the software.

3.AVRFreaks.net can be a very useful debugging tool if you stay focused on the problem.

4.Share your work with friends who have good brains.

5.Share your work with friends who have good tools.

6.Nothing is ever as simple as I'd expect it to be. If I had a true concept of the approaching difficulties, I'd never do anything.

 

Thanks everybody for all the help. I'm going to declare this thread solved. 

Last Edited: Mon. Apr 11, 2016 - 05:16 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You need at least one of these:
http://m.ebay.com/itm/191685084604
Various places sell these things. I bought 4 last time as you tend to blow them up.
The first problem it helps you solve, you'll figure it was the best $8 you ever spent.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

+1

A GIF is worth a thousend words   They are called Rosa, Sylvia, Tessa and Tina, You can find them https://www.linuxmint.com/

Dragon broken ? http://aplomb.nl/TechStuff/Dragon/Dragon.html for how-to-fix tips

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks for the suggestion, I'll look into this.

 

I have an ancient BitScope that is a bit flaky and frankly I'm not even sure it will run on Win10. I didn't want the aggravation so I borrowed my friends digital scope. These look good and I'll verify that I can run them on Linux and/or Win10 before getting some.

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Take home learning:

1.Listen to Joey Morin when he speaks.

That seems like a strategy doomed to eventual failure ;-)

 

Glad you're getting it sorted.

 

As you explore other control algorithms, consider expanding your encoder wheel to be a full quadrature encoder.  You can do this (for each wheel) just by adding another emitter/sensor pair offset by 1/2 slot (or 1.5 slots, or 2.5, or N.5) w.r.t the first pair, the advantage being that a quadrature encoder also carries direction information.  Alternately, use a commercially available quadrature encoder.  Some hobby motors can be had with integrated encoders.

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

They even run on Mac. The front end is written in Java, so it runs on all three o/s.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

joeymorin wrote:
As you explore other control algorithms, consider expanding your encoder wheel to be a full quadrature encoder.  You can do this (for each wheel) just by adding another emitter/sensor pair offset by 1/2 slot (or 1.5 slots, or 2.5, or N.5) w.r.t the first pair, the advantage being that a quadrature encoder also carries direction information.  Alternately, use a commercially available quadrature encoder.  Some hobby motors can be had with integrated encoders.
Since I am setting the motor direction using a digital pin to my H-bridge I already know the motor direction. If I decide to generalize this project, I may well add quadrature encoding.

 

However, my original goal was to include this in a novice friendly introductory type project and it has gotten way way way beyond that. It is however a good project for more advance folks who what to learn a little about control algorithms, so I'll continue with it for that reason. And it has been one hell of a lesson in debugging humility.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If gravity overcomes the force of the motor, you no longer know the motor's direction.

Seriously, get those logic analysers. You would've identified your problem in minutes. Once you get them and put them to use, you'll be too busy kicking yourself wondering why you didn't get them years ago, to thank me for the suggestion!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Kartman wrote:
If gravity overcomes the force of the motor, you no longer know the motor's direction. Seriously, get those logic analysers. You would've identified your problem in minutes. Once you get them and put them to use, you'll be too busy kicking yourself wondering why you didn't get them years ago, to thank me for the suggestion!
Okay okay! I'll order them tonight! Thanks!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Since I am setting the motor direction using a digital pin to my H-bridge I already know the motor direction.

Do you.

For me it sounds like that is your problem, slippage in the gear when change direction. From you stop (or change direction) the motor still move, and could easy be a problem, if you count on direction only depending of your H-bridge pin direction. 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The encoder I use is visible to me and numbered. I insert a 1 second delay so that I can watch it come to a halt and then start again in the other direction. But you do have a point. When I remove the delay an use it in the real world, then the change direction overshoot may well become an issue. Crap, this just gets harder and harder. So now I add quadrature encoding to the list, at least in the development phase to see if this is indeed an issue. Thanks Sparrow.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

That's why that last robot I did used stepper motors instead of DC motors.  So much easier to control the darn thing!  That's it in my avatar picture.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I haven't done the work to know, but aren't steppers energy hogs? I was under the impression that they required much more battery life for a given application than ordinary DC geared motors? I'll look into that, since as you say, steppers are very easy to control. And you can get some fairly cheap. Hmmm...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

There are stepper motors and there are stepper motors :)
The motor itself is actually more effective, but the shifts cost, and don't give it more voltages than needed.
What you really want is a motor pm, so if you give the engine two sinusoidal signals 90 degrees out of phase, you will get a constant torque, with a stepper motor torque will be ripples.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

There are constant torque microstepping drive algorithms, at the slight expense of lower maximum torque. Steppers always draw power, even when stopped. Undriven, a stopped stepper has little holding torque (called detent torque).

 

They must be carefully accelerated and decelerated or they will skip or slip steps.  A load which exceeds maximum torque will do the same.

 

Driver chips exist which can handle most of the details (torque, acceleration, deceleration, etc.).

 

So they are not a general solution to your current problem. You'd still need position sensing either via encoder or B-EMF sensors.

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

Last Edited: Thu. Apr 14, 2016 - 05:04 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

Steppers to drive robot wheels ? Pussies .....

 

devil

A GIF is worth a thousend words   They are called Rosa, Sylvia, Tessa and Tina, You can find them https://www.linuxmint.com/

Dragon broken ? http://aplomb.nl/TechStuff/Dragon/Dragon.html for how-to-fix tips

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

For battery life to be a concern, I guess it would depend on what your application is.  My maze runner would typically run 3 times in a maze that would take maybe 5 minutes to solve and return.  I don't recall having any battery issues using a 7.2V sub-c pack.  I believe the motors are Nema23, but it's been a long time since I ran it.

Pages