I’ve been interested in PID motor control since last year and have built my bot developing basic motor control algorithms. I plan to layer motion behaviors to get more complex motions. I have created a blog at jaydmdigital.blogspot.com if you are interested. I have been posting Excel graphs from my feedback captures and have started a sub-project to code a GUI interface to the serial link I have to my bot via Bluetooth.
Jay
Some basic information about my bot:
8" in diameter blue PVC deck
3" diameter PVC o-ring wheels
66RPM 12V motors connected to 1000PPR quad encoders
4S 3100mAH Lipo
BlueSmirf radio
SRF04 sonar
MAVRIC IIb MCU board
Encoders give me a resolution of .004". Max speed is around 19"/s or 1.10MPH
Jay
I have been to your blog page and it looks very nice. Is that a photo of your son?
Also what do you mean by layered motion? Are you talking about combining two motions into one? for example, turning while moving forward to create an arc rather than a sawtooth pattern?
Interesting project.
Yes that is my son, thanks for the kind comments.
By layered I’m referring to subsumption. My favorite example is obstacle avoidance. Let’s say one behavior is wall following. The bot is happily following the wall when the front sonar sees something (maybe a corner, maybe a leg). Another program called avoid sees this obstacle and by having a higher priority it’s signals to the motor controller subsume (overwrite) those from the wall follow program. When the obstacle has been avoided, avoid stops subsuming wall follow’s commands and the bot resumes wall following.
Make sense? Each behavior is simple by itself, but together they become more complex.
After I complete my serial UI program, I am going to add a new function to test driving via vectors (distance, angle) with drift correction added on the PID side.
Thanks for looking,
JAy
I have read the article by Rodney Brooks about subsumption as well as FSM (Finite State Machine) and was amazed. FSM I found very hard to program since several parts of a program are executed on the fly. For example driving a servo while reading a PING sensor, you had to calculate the time it takes to to complete the servo pulse based on the time it takes to run x number of lines of code to equal 20ms.
What labguage are you programming in? I will be programing in either Pbasic or Mbasic.
C. Using WINAVR cross compiler.
I don’t know C so I wont be able to understand your code 
I would like to give this a try though, but not in C, in Pbasic.
Got any videos of your bot in action?
Not yet. It’s on my to-do list but I wanted to show it in a good light … so to speak. I have made myself a promise to do it this weekend … who knows, maybe tonight.
Hi Mike, Jay,
As a way of implementing FSM’s for a subsumption-based architecture I’d assume you’d be running multiple small tasks, all under control of a real-time interrupt. Each FSM gets a chance to run on a regular basis if enabled.
Tasks like running a servo or sending commands (to an SSC32?) would be ran by interrupts, and need not (must not?) interfere with other tasks. Task flags turn on tasks to be run.
That’s my biggest problem with the current bit-bang SPI interface I’ve implemented for the PS2 Joystick controller. I’ve written the code for true hardware (PIC18) SPI, and it looks good, but I haven’t moved PS2 over to it.
Can you do this under PBASIC or MBASIC? I know it can be done with C on the PICs; we’re basically running small multi-task controller programs at my work. Hi-Tech compilers.
Alan KM6VV
As far as servo or any PWM output, the ATMEGA has some nice hardware to automate the waveform generation for up to 6 PWM signals. This means all I have to do is update 1 register to change the duty cycle. The PWM can be 8, 9 or 10 bit too.
You are correct about my using a timer interrupt to call the small apps.
Jay
I finally saw your video. I almost forgot where you posted it and had to do a search! Anyway, very well done!
