Search  
Tuesday, January 06, 2009 ..:: Forum ::.. Register  Login
 HomePage Minimize

 Print   

 Products Minimize

 Print   

 MSRS Minimize

 Print   

      
 RoboticsConnection Forum Minimize
SearchForum Home
  Discussions  Serializer Robot Controller  Encoders on the...
 Re: Encoders on the Serializer WL
 
 5/1/2007 5:42:35 PM
micm66
9 posts


Re: Encoders on the Serializer WL

At the risk of asking a dumb question - do you get one pulse per black spoke, say, or one pulse for a black and one for a white? I.E. Should my 44-spoke disks produce 44 or 88 pulses per rev?

~Mike

 5/1/2007 6:14:28 PM
jason
158 posts
5th


Re: Encoders on the Serializer WL

Mike,

On the contrary, that's a very good question, and one that I'm sure many customers would like to know. :)

Speaking of how the Serializer sees encoder interrupts, it sees a transition from white to black as an interrupt.  Thus if you have 44 black spokes, and 44 white spokes, you will get 44 interrupts.

I would've liked to have had an interrupt occur on any level transition (white-to-black or black-to-white), thus doubling the encoder resolution.  However, one of the interruptable encoder pins we use on the PIC can only see interrupts in one direction or the other, but not both.  Thus we had to follow that behavior on both interruptable pins.

Now, the actual encoder modules output 0-5-0-5 transitions based on the color it sees.  So, if you were using a chip that has two interrupts which can interrupt on any level transition, then you could then double your resolution.  Of course, you couldn't take advantage of the power of the Serializer libraries and services at that point, and have to develop your own code to handle that to run on that chip.


Jason Summerour
President,
Summerour Robotics Corp
Microsoft MVP
www.roboticsconnection.com
 5/3/2007 12:40:21 PM
micm66
9 posts


Re: Encoders on the Serializer WL

Well, I've made some progress.

I used that encoder designer program to create a pattern.  I went for a 3.5" diameter to give at least a little extra clearance (with the 4" wheels).  About the densest I could get to draw fairly cleanly was 100. 

I printed these out onto clear vinyl self-adhesive label stock, and gave them a few coats of clear acrylic to seal and protect the ink. Then I applied them to a pair of disks I made from some white polystyrene I had left over from some vacuum-forming projects.  Now I just need to make a couple of brackets to position the encoder boards and it should be good-to-go.

100 resolution will give me about 180 clicks per second. Is this still too small a number of clicks? If so, what's the threshold of clicks per second that would be useful?

~Mike

 5/3/2007 2:58:30 PM
ringo
36 posts


Re: Encoders on the Serializer WL
Mike,
108 RPM is 1.8 RPS.
If you want an L of 32 that means if you want to be able to set a velocity of 50 then you want 60 (overhead) ticks per PID loop. at 20 pid loops per second that would be 1200 ticks per second. If the RPS is 1.8 then you would need 1200/1.8 = 667 ticks per revolution. That would be your desired encoder resolution.
 
That is the perfect world.
 
Change the velocity of 50 to 9 and and you get something like 10*20=200/1.8=111 ticks. But then you can only set you speed form 0 to 9 and the oscillation will be worse.
 
 
Here is what that really means.
 
When you set a speed of 50, the FW will watch  the velocity, if it drifts to 51 it lowers the PWM, if it drifts to 49 it raises the PWM, If it gets way off it adjust the PWM even more. So if you set a speed of 50 the best you will get is an oscillation from 49 to 51, so that is +/- 2%, not enough to notice and it appears to be holding a perfectly steady speed.
 
Now assume a very bad case where your encoder resolution is so low you can only have a speed of 0-3. If you set it to 2 then it can drift from 1 to 3, which is +/- 33% and would probably look horrible. It is possible that on a perfectly flat floor it might look ok because it could bounce from 2-3-2-3-2-3..... with a very small amount of pwm change. But as soon as you hit a rung or something that slows you down (or speeds you up) there is just too much variance.
 
It is basically the same thing if you increase the L to get a good velocity but you are only updating a couple times a second. If you hit carpet you could slow way down from 50 to 35 (just making up numbers) before the PID loop happens and it see the change. At that point the pid loop would see a drastic change and respond with a drastic change to try to overcome the resistance. so for the next 1/2 second you are getting way more power. that could possibly drive you to something like 70. then it starts over, you are too fast so it slows you down too much. If this is happening 50 time a second you don't even see it. as soon as it slows from 50 to 49 the pid loop increases power.
 
 
I'm hoping this helps explain what happens. so if you follow my logic above and use a max velocity of 9 then you will be +/- 10%. you can try that and see if it is acceptable. Then you can play with the L parameter and see what makes it better. Longer L means more samples so better resolution in that case, but less frequent updates so worse resolution there. It is a balancing game.  It just comes down to what is acceptable to you. 100 is better than 44, 600 would be even better, just experiment and see how well it performs.
 
 
I think I read above that you are using banebots motors, is there not a shaft coming out of the back of the motor you can attach to? if so that would be before the gearing and would greatly help your resolution.
 
Ringo
 
 
 
 

Ringo Davis, Hardware Technical Lead RoboticsConnection.com
 5/3/2007 3:30:22 PM
ringo
36 posts


Re: Encoders on the Serializer WL

Mike, Take a look at

http://www.usdigital.com/products/e4p/

300 counts per revolution for $19 each. just make sure the Diameter will fit your motors.

 

Ringo

 


Ringo Davis, Hardware Technical Lead RoboticsConnection.com
  Discussions  Serializer Robot Controller  Encoders on the...

SearchSearch  Forum HomeForum Home    Print   

Copyright 2004-2007 Summerour Robotics Corp   Terms Of Use  Privacy Statement
DotNetNuke® is copyright 2002-2009 by DotNetNuke Corporation