Sorry for the slow reply. Church day... I agree - this forum is great. Thanks for your kind words, but the idea and all the hard work was yours!
What is next for you on this project? I'm still going to·fool around with the Vibra Tabs a bit more. When I get serious, I will make an encoder like yours. I orderd a couple of sets of the Hamamatsu P5587 sensors way back, so I'm basically ready to go.
You are currently at 24 black/white bands on the encoder wheels - are you going for more? How will you procede with the code?
One other improvement I was thinking about is switching the encoder sensors and the light sensors. That way you could set the Scribbler up for some of its original code or move to encoder mode.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Whit+
"We keep moving forward, opening new doors, and doing new things, because we're curious and curiosity keeps leading us down new paths." - Walt Disney
Hey, Whit, nice blog! Anyone who hasn't visited "robotics under the stole" is just plain missing out. Click on Whit's name for the link.
After a bit of a break from my hectic encoder weekend, I've gotten some nice emails and comments from the group. I'm not quite ready to publish my code, as there's one strange anomaly to be explained, an often-missed motor speed control that only works when I put a brief pause in front of it. Possibly overlapping or too-close pulsouts on the same pin, I will figure it out.
As I said, my program is VERY simple, and I am more surprised than anyone how well it works. If you've skimmed any of PhiPi's amazing article (links above), you know that real odometry and path planning can get very complicated. And fully realized PID (proportional, intergral, derivative) control is even more complex. But after watching the green blinking LEDs on my video a few times, I think I can hazard a guess why my simple program works relatively well: Instead of dealing with general control theory for every possible electromechanical system, I had the luxury of writing specific code for one particular robot and being able to test it regularly.
In particular, I started with both onboard motor controllers custom adjusted to medium speed, ~pulsout 1500. That is, one motor was set to 1450 and the other to 1550, values I obtained through prior testing to make the robot go as straight as possible without encoders. No two motors are the same, so some "fudging" is usually required. In contrast, PhiPi came up with a much slicker self-calibrating routine which stored calibration constants in memory.
My program only does is the 'P' in PID: proportional control. That's the most obvious type. It compares total encoder pulses from both wheels and adjusts one wheel to go faster or slower to match the other wheel's total distance travelled. Since the robot was already adjusted to go mostly straight, I knew that only minor course corrections would be required for closed loop control. I determined through testing that +/- 200 pulsout units would regulate the wheel speed pretty well.
My status LEDs showed that the wheels were "in sync" much of the time, which was good. Beyond that, the "faster" vs. "slower" LEDS were on for about the same duration. THAT (upon further reflection) is the key. The I ("integral") portion of the PID control system can add up to zero and self-cancel if the motor runs alternately fast then slow in approximately similar amounts.
Long story short, I did my self a favor by using common sense when writing the program. I didn't use any math or formulas. I LOATHED LaPlace transforms in college. But I did constant testing and I manually adjusted the initial motor constants (making the robot go straight without encoders), which minimized the work the control loop had to do (reduced control system variation and overshoot). This resulted in a simple, stable control system with minimal accumulated integral error.
More than anything, this underscores the KISS principle: Keep It Simple, Stupid! Common sense wins out: if you have a complicated, overwhelming goal, don't despair. Try something simple first, then and test and refine it.
erco
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ ·"If you build it, they will come."
Just had an interesting thought. Scribbler's motor drivers use a pulsout 12,2000 to stop. I get all upset having to wait for that pulsout command to execute, it still takes a few milliseconds of waiting (doing nothing)·and I might miss an encoder transition. Well, a high 12 command followed by several (N) encoder checks then a low 12 command would send some·width of motor control pulse. Those commands execute faster, and·by varying the number N of encoder checks, the effective pulse width (and motor speed)·can be·varied, all while monitoring the encoders. I might just have to experiment with that to see if it works at all....
PhiPi·might have·already done this to perfection. Phil?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ ·"If you build it, they will come."
More success. I hate it when that happens.·My quick code (attached) ain't pretty, but it shows that I can fake a full-speed pulsout (approximate value 1000) with a high/low commands while sampling both encoders twice in between. More samples=slower or reverse commands.·I hope to·crunch the code down a bit for finer speed control. Obviously I want a "clean" motor stop command (pulsout 12, 2000).
BTW, I already swapped gearboxes for more gear reduction and I reversed the motor polarity so that my Scribbler goes forward with a pulsout 12, 1000 and reverse with pulsout 3000. The only way to fly!
Whit, or anyone else, please run a test program for me and report back. I found that I could use a pulsout value for full-speed motor speed·control as low as 745. That is, pulsout 12,745 worked just like pulsout 12,1000. But pulsout 12,744 didn't work at all. If you could try some different values in the attached program (faked into the beginning of my program listing) and let me know your results, that will give me·an idea how similar our robots are and how finnicky this program may or may not be with different robots. Thanks.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ ·"If you build it, they will come."
Comments
Sorry for the slow reply. Church day... I agree - this forum is great. Thanks for your kind words, but the idea and all the hard work was yours!
What is next for you on this project? I'm still going to·fool around with the Vibra Tabs a bit more. When I get serious, I will make an encoder like yours. I orderd a couple of sets of the Hamamatsu P5587 sensors way back, so I'm basically ready to go.
You are currently at 24 black/white bands on the encoder wheels - are you going for more? How will you procede with the code?
One other improvement I was thinking about is switching the encoder sensors and the light sensors. That way you could set the Scribbler up for some of its original code or move to encoder mode.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Whit+
"We keep moving forward, opening new doors, and doing new things, because we're curious and curiosity keeps leading us down new paths." - Walt Disney
Post Edited (Whit) : 1/5/2009 12:38:14 PM GMT
After a bit of a break from my hectic encoder weekend, I've gotten some nice emails and comments from the group. I'm not quite ready to publish my code, as there's one strange anomaly to be explained, an often-missed motor speed control that only works when I put a brief pause in front of it. Possibly overlapping or too-close pulsouts on the same pin, I will figure it out.
As I said, my program is VERY simple, and I am more surprised than anyone how well it works. If you've skimmed any of PhiPi's amazing article (links above), you know that real odometry and path planning can get very complicated. And fully realized PID (proportional, intergral, derivative) control is even more complex. But after watching the green blinking LEDs on my video a few times, I think I can hazard a guess why my simple program works relatively well: Instead of dealing with general control theory for every possible electromechanical system, I had the luxury of writing specific code for one particular robot and being able to test it regularly.
In particular, I started with both onboard motor controllers custom adjusted to medium speed, ~pulsout 1500. That is, one motor was set to 1450 and the other to 1550, values I obtained through prior testing to make the robot go as straight as possible without encoders. No two motors are the same, so some "fudging" is usually required. In contrast, PhiPi came up with a much slicker self-calibrating routine which stored calibration constants in memory.
My program only does is the 'P' in PID: proportional control. That's the most obvious type. It compares total encoder pulses from both wheels and adjusts one wheel to go faster or slower to match the other wheel's total distance travelled. Since the robot was already adjusted to go mostly straight, I knew that only minor course corrections would be required for closed loop control. I determined through testing that +/- 200 pulsout units would regulate the wheel speed pretty well.
My status LEDs showed that the wheels were "in sync" much of the time, which was good. Beyond that, the "faster" vs. "slower" LEDS were on for about the same duration. THAT (upon further reflection) is the key. The I ("integral") portion of the PID control system can add up to zero and self-cancel if the motor runs alternately fast then slow in approximately similar amounts.
Long story short, I did my self a favor by using common sense when writing the program. I didn't use any math or formulas. I LOATHED LaPlace transforms in college. But I did constant testing and I manually adjusted the initial motor constants (making the robot go straight without encoders), which minimized the work the control loop had to do (reduced control system variation and overshoot). This resulted in a simple, stable control system with minimal accumulated integral error.
More than anything, this underscores the KISS principle: Keep It Simple, Stupid! Common sense wins out: if you have a complicated, overwhelming goal, don't despair. Try something simple first, then and test and refine it.
erco
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
·"If you build it, they will come."
PhiPi·might have·already done this to perfection. Phil?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
·"If you build it, they will come."
-Phil
You are one smart cookie!
I've got to get set up so I can play with some of these ideas...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Whit+
"We keep moving forward, opening new doors, and doing new things, because we're curious and curiosity keeps leading us down new paths." - Walt Disney
BTW, I already swapped gearboxes for more gear reduction and I reversed the motor polarity so that my Scribbler goes forward with a pulsout 12, 1000 and reverse with pulsout 3000. The only way to fly!
Whit, or anyone else, please run a test program for me and report back. I found that I could use a pulsout value for full-speed motor speed·control as low as 745. That is, pulsout 12,745 worked just like pulsout 12,1000. But pulsout 12,744 didn't work at all. If you could try some different values in the attached program (faked into the beginning of my program listing) and let me know your results, that will give me·an idea how similar our robots are and how finnicky this program may or may not be with different robots. Thanks.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
·"If you build it, they will come."
I am good everytime at 750 or above. Below that the results are irregular. Great discovery.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Whit+
"We keep moving forward, opening new doors, and doing new things, because we're curious and curiosity keeps leading us down new paths." - Walt Disney
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
·"If you build it, they will come."
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Whit+
"We keep moving forward, opening new doors, and doing new things, because we're curious and curiosity keeps leading us down new paths." - Walt Disney
I would love to hear more about the new gearboxes/motors and how they are working! My hacking Scribbler is on the way.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Whit+
"We keep moving forward, opening new doors, and doing new things, because we're curious and curiosity keeps leading us down new paths." - Walt Disney