I watched it, Pal. Good job! Looks like you got it running pretty true, which is very critical for these wheels.
\
Woot! It now has "1 views". Cool.
I ought to switch to my real video camera for these YouTube videos. I'm using the video function on my still camera because it's so easy to transfer the SD card to the PC for uploading to YouTube. My video camera uses those MiniDV tapes which would make transferring the video to the PC more work. But I think the video camera would probably focus better so it might be worth the effort.
I decided drilling holes for set screws isn't so bad. This video showed up as an option after I watch mine. Ouch! Making your own mecanum wheels looks like a lot more work than drilling a few holes.
I'm hoping the Rover 5 has enough power to drive these larger mecanum wheels. After my popsicle stick hexapod, I'm not very confident in my ability to guess power requirements (though I did suspect the hexapod legs would be too long for the servos).
I wired up a couple L298N H-bridge chips to power my newest Rover 5 chassis (thanks Ravenkallen).
Here's a video of the latest progress. It will hurt my feelings if you all don't watch this one (at least the first minute). (See edit.)
Edit: I'm leaving this video here as record of my mistakes. See post #49 for the reason the robot wont rotate and to watch a much better video.
It turns out the L298N chips can be used on a breadboard with a little persuasion.
So far, so good. I'm not really sure how to add the encoders without using a bunch of cogs. I have some code I previously wrote but it needs some polishing (with a jackhammer).
Duane: Fabulous, I watched it all! Looks especially great traversing sideways. It drives better on the carpet than your hard tile floor. From my experience with those Fingertech wheels, some of that is weight distribution. It sinks into the carpet which evens things out and all wheels get some traction. On a hard (non-compliant) floor, one wheel probably has less weight (chassis irregularities) and it skids before the others do, which messes things up. I made my chassis swivel in the middle, which improved things somewhat.
I agree you do need more power (along with encoders) to really get that thing humming. And IMHO a stronger chassis would help. Maybe something in a nice aviation plywood ...
Thanks for the feedback. I'm pleased with how the bot is progressing. I'm busy working on those encoders. I'm trying to balance sample time against refresh rate. If I check the speed too frequently, there haven't been enough encoder ticks to accurately measure speed, if I sample too infrequently the controls are very sluggish.
I'm pretty much back to where I left off with my other Rover 5 chassis (this one I bought off Ravenkallen). I think it will take some sort of PI or PID algorithm to get the wheels to respond well to the encoders. This time I'm not trying to get it all to fit in one cog. I'm using two cogs for the PWM motor control (I'm currently using an object by Kye. I will likely write my own object so the PWM will only take one cog) and one cog for the encoders (my PASM code is reading all four quadrature encoders in one cog successfully) and one for the main loop. I haven't decided if I'll run the PID algorithm (which I have yet to write) to run within the main loop or to use another cog for it. Oh, I'm also using a cog for Jason Dorrie's "RC_Receiver_6.spin" object that reads the RC receiver pulses. How many does that add up to now?
1 (Main Loop)
2 (PWM)
1 (RC pulses)
1 (Encoders)
1 (Serial Driver for Debug)
1 (Floating Point Math)
I count seven. I could do without the serial driver once I'm done with debugging the program. I'm seeing again why I used two Propellers with the other Rover 5 chassis (that's a bit on hold while I work with this chassis and the Vex mecanum wheels). I still a have a cog left to run a PID algorithm if I need it. I have'nt started adding any sensors yet so I might need to reclaim some of the cogs. As I said earlier, I'm pretty sure I could drive all four PWM signals from one cog with some PASM code (the LED array code drives 120 PWM channels with one cog using 595 shift registers).
I hadn't realized until just now, that if I use another cog for the PID algorithm, I might as well use Kye's PID, PWM with quadrature encoder object that requires a cog for each motor/encoder combination. I'm reluctant to do so since I could never get the PID to tune the way I'd like it too. My assumption is the encoders on this bot are too course for Kye's PID object (I'm not sure about this, I just might not know how to tune a PID).
I think I will probably give Kye's PID object another try.
I hadn't planned on posting code until I'm a bit further along. I'm sure I could be persuaded to post my "in progress" code if someone asks.
I agree you do need more power (along with encoders) to really get that thing humming.
Tell me about it. I'm sure you know how much four powerful geared motors with encoders cost. Each one will probably cost as much as what I paid for this Rover 5 ($40). Even though they'd cost a bit, I'm seriously considering some more powerful motors with encoders.
Do mechanum wheels have any advantage over classic omni wheels? With four omni wheels you only drive two at a time to move forward or side to side. With these you drive all four which might give you more power?
I think the biggest advantage is that you can use a standard chassis configuration. If omni wheels are arranged in an x rather that + then they drive just like mecanums.
In the x configuration, the omni travels fastest at a 45 degrees (only two wheels turning) whereas the mecanum travels fastest straight ahead (all wheels turning).
Tell me about it. I'm sure you know how much four powerful geared motors with encoders cost. Each one will probably cost as much as what I paid for this Rover 5 ($40). Even though they'd cost a bit, I'm seriously considering some more powerful motors with encoders.
You can always get gearmotors make your own wheel encoders for cheap, Pal. A rite of passage IMHO!
Do mechanum wheels have any advantage over classic omni wheels? With four omni wheels you only drive two at a time to move forward or side to side. With these you drive all four which might give you more power?
The main advantage of these it the cool factor. Though I also like "classic" omni wheels. I personally like the classic omni wheels when three are used. I think they just look cooler that way and to someone who's not familiar with omni wheels, the robot looks like it shouldn't be able to move. At best they think it will just spin in place.
Here's a three wheeled omni wheeled bot I made a while back.
I was able to attach the omni wheels without modifying the wheels at all. As I've mentioned several times, I had to drill the Vex mecanum wheeels to allow the Rover 5's axles to pass through the wheels and I also had to drill holes for the set screws.
I think the biggest advantage is that you can use a standard chassis configuration. If omni wheels are arranged in an x rather that + then they drive just like mecanums.
In the x configuration, the omni travels fastest at a 45 degrees (only two wheels turning) whereas the mecanum travels fastest straight ahead (all wheels turning).
I think the fastest a three wheeled version can travel is also when a wheel is in line with the direction of travel. With three wheels there a three lines that allow the fastest motion. With a four wheeled omni bot there are only two lines that give the greatest speed. Not that I'd want to race my three wheeled bot against a one with four motors.
You can always get gearmotors make your own wheel encoders for cheap, Pal. A rite of passage IMHO!
I'd really like the encoders to be attached to the motor's shaft to get maximum resolution of the motor/gearbox system. I haven't seen many motor/gearbox combos that give access to the motor shaft.
I have added encoders to a Roboni-I robot. I attached the encoders (homemade, single channel) to the first gear after the motor's pinion. The Roboni-I's homemade encoders work well.
I also like your idea of putting a breadboard on top of the protoboard. It's really flexible,
Technically, it's on the bottom of the protoboard. The crystal socket keeps the bottom of the protoboard from being completely flat in the center area. The wires I soldered to each IO pin also poked through the bottom of the protoboard a bit. To keep these obstructions from interferring with the breadboard, I added a layer of popsicle sticks to raise the level of the breadboard above the solder on the back of the Protoboard. I also added a layer of hard clear plastic from a "clam shell" type package because as I added components to the breadboard, it was being pressed against the soldering joints underneath. The solder joints with the clipped ends of wires would cut through the foam tape on bottom of the breadboard and cause a short with the breadboard's metal clips. (This was a puzzling problem for a while since the shorts were intermittent.)
I initially used the protoboard/breadboard combo on a BOE-Bot. At the time I didn't know there were breadboards this size for sale. The breadboard I'm using a larger breadboard I cut in half.
Things were getting a bit cramped so I added heat shrink tubing to the resistor leads. The heat shrink tubing really let me pack the items closer together.
Here's another shot of the resistors that limit the current from the RC receiver to the Propeller (pins 0 - 5). I also used current limiting resistors with the encoders (pins 6 - 13). You can see I added a label with the pin numbers to the header.
Here's the other header with the IO pin numbers labeled. These pins control the L298 chips. Each L298 chip needs eight diodes. The breadboard is starting to get a bit crowded.
One power rail has 5V to power the RC receiver, encoders and L298 chips. The other power rail is connected to Vin (about 8V with freshly charged batteries). The only 3.3V device on the breadboard is the power on LED.
Here's the side with the power headers. You can see I added male headers for the jumper and servo connections. There's also a female header to connect IO pins to the servo's signal pin.
Here are a couple of shots that show the layers I mentioned.
Here's the "top" of the board with electrical tape to protect the wires from batteries that slide in and out past them.
Under the tape are the wires that bring the IO pins out to the headers.
I end up using this board a lot. I keep meaning to make another.
Thanks Rick. It's nice to know people are watching my progress.
I'm currently uploading a video showing off the new encoder algorithm. The encoders help a lot with control. YouTube says the video should be ready in 32 minutes. Stay tuned.
Well, it turns out the key to getting the robot to turn in place was to not have the wheels fight themselves.
Two of the wheels (front left and rear right) were turning the wrong direction to rotate the robot. The characteristics that allow a robot to travel sideways with mecanum wheels also allow the robot to remain stationary while all four wheels turn. Basically the left side was telling the robot to go right and the right side was trying to get the robot to go left. The net result was the robot stayed put, fast.
The fix was changing a "0" to a "2" in one of the "if" statements.
While this programming error kept the robot from turning in place, the robot had other problems from not knowing how fast each wheel was turning. Encoders to the rescue!
Adding encoders made a huge difference! I added the following PID algorithm:
The above code was based on the PID pseudo code I found on Wikipedia. I used a Kp of 10 with Ki and Kd both remaining zero. With both Ki and Kd zero, I guess the code is just a proportional algorithm. I tried making Ki equal to one with Kd either one or zero. Both of these attempts at adding an integral component caused the motors to oscillate wildly.
Edit (June 20, 2012): I revisited this PID method for a different project and realized the above code has some severe problems when using the Prop's integer math.
I had neglected to scale the motor speeds in my earlier attempt. The code in my first attempt just limited the top speed of any motor to 1000 (the limit of Kye's PWM driver). My new code scales all motor speeds based on the speed of the fastest motor. For example if the fastest motor speed was computed to be 2000 then all motor speeds would be divided by 2. The scaling code is part of the above "Pid" method.
So here's the video. The robot is looking pretty good in my opinion.
So far, I'm really liking these Vex mecanum wheels. Thanks for the information about them erco.
As I said in the video, now it's time to turn this radio controlled vehicle into a robot. I might start with some IR and ultrasound sensors since those are relatively easy to implement. I, of course, will need to add one of the machine vision options to this robot in order to live up to this threads title.
Beauteous! Per Martin_H, show us a figure 8 slaloming around some dinner plates, even if you're manually driving it!
I think this would show off its current weakness. The robot rc car can travel forward, back, side to side and at 45 degree angles just fine. I've noticed it still has trouble with angles that aren't multiples of 45 degrees. I think the encoder algorithm still needs some tweeking. To be honest, I'm surprised it works as well as it does.
I had looked up PID on Wikipedia and translated the pseudo code they had there to Spin and it just worked (as long as it didn't try to add any I or D).
I'm currently trying to merge the PWM code in with the encoder code in order to free up two cogs. I had planned to fiddle with the various encoder parameters later to try to get this rc car travel smoothly at all angles (in a single plan for now).
I'll likely take a break from coding and drive around couple of plates.
Someone's gonna get fancy. First, they'll do it with lobster or other fancy food on the plates. Next, a piece of the food (drumstick or lamb chop) will overhang the circular plate and the robot will track perfectly around the non-circular combination...
It's rolling alot smoother now Duane. looks cool too.
Show erco some love, and give it a spin around the plates...:)
-Tommy
Thanks Tommy. I'm really pleased to see how much the encoders helped. I was also pleased I could monitor all four quadrature encoders within a single cog.
erco already knows I'm working on a figure 8 project. He knows my weak will is no match for his power of suggestion (I have a Roomba, Roboni-I, $4 ultrasound sensors and purple batteries to prove it). And for some reason my robot arm is calling out to me to use it.
I am not going to drive the robot around the plates (with or without lobster) using remote control. I do have some pride. This will be an autonomous figure 8.
In preparation for the Parallax Expo, I'm trying to spruce up my Mecanum wheeled robot. Part of the beautification is to move the motor circuit off the breadboard.
I'm using a couple of L298N breakout boards. I've added the Schottky diodes to one of the controllers so far.
Here's a picure of the two boards.
I drilled a couple of holes in the bottom of the Rover 5 so I can hold these boards in place with some standoffs. Here's a picture of the two boards set in place.
The board with the diodes is on the left in this picture. Since the L298 chips never even got warm when I drove the robot, I'm hoping mounting them upside-down like this will be okay. Other mounting positions I can think of take up too much space. I suppose I could add a small fan to blow air past the chips if they get too warm mounted this way.
I have some surface mount Schottky diodes. I'm thinking of using the smt diodes on the second board to see which type of mounting configuration I like more.
I plan to use the Propeller Proto Boards I made at the beginning of this thread with this robot. I removed the SN754410 chips from the boards since I'll be using these L298N chips to control the motors.
These Vex Mecanum wheels are so large, I'm thinking I may use the LED array on the robot after all. I had previously thought the array looked too bulky but with these larger wheels, it might look okay.
I still hope to use some sort of machine vision with this robot and I thought it would be fun to use the LED array to output what the robot was "seeing".
The through hole diodes are these from SparkFun. I purchased 100 so they were $0.12 each.
The surface mount diodes I purchased from Digi-Key. Part number 641-1014-1-ND. I also purchased 100 of these so they were $0.147 each.
As I mentioned in my earlier post, I liked the surface mount diodes much more than the through hole diodes. They were much easier to fit on the small board and actually made the soldering job easier.
I also like using surface mount resistors and capacitors more than their through hole counter parts. The little 0603 resistors fit nicely between leads spaced 0.1" apart.
I received an email asking about some of the specifics of this project.
I prefer to answer the questions here so others can read my answers.
I as asked to elaborate one the processor used.
I'm using a Parallax Propeller as the processor for this project. The Propeller chips come mounted on Propeller Proto Boards. I usually buy five at a time.
The normal Propeller Proto Boards need a Prop Plug to communicate with a PC. I've managed to burn out two different Prop Plugs so now I make my own by cutting the USB section out of a Propeller Proto Board USB. I buy these four at a time. I add header pins the remaining portion of the board so it behaves like a normal Propeller Proto Board. A PPB USB (buying four at a time) costs $10 less than buying a PPB (five at a time) plus a Prop Plug.
I know I've posted pictures of my DIY Prop Plugs on the forum, and I'll post them again if requested.
One PPB is used to read the encoders, control the motors and monitor the radio connection with the remote.
A second PPB is used to read the video image and control the LED array. I think there are some details about these two boards (though out of date) in post #8.
I'm no longer using the Mecanum wheels from SparkFun. I'm using the ones erco recommended from Vex.
I am still using the Rover 5 platform from SparkFun.
I was asked about using an Arduino with this setup. I'm pretty sure the Arduino couldn't read the four quadrature encoders and do much of anything else. The Propeller is a great microcontoller to use with this projects because of the many things happening at the same time. I can assign the various tasks to different cogs with one cog bringing the data gathered by the other cogs together and making decisions based on the data.
I think an Arduino would just be in the way with this project.
I'm presently working on a remote to use with my various robot projects. This project, the hexapod project and some others will be updated once I have the remote working correctly.
Let's say I'd like to built this thing too, and add a GPS unit so it can drive itself from point A to B; what would I need other than the Rover 5, the PPB, the wheels? I guess I need some kind of ESC for the motors - you mentioned the L298N + some diodes.
Sorry if this is a very beginner question; I'm just getting into robotics.
Comments
Woot! It now has "1 views". Cool.
I ought to switch to my real video camera for these YouTube videos. I'm using the video function on my still camera because it's so easy to transfer the SD card to the PC for uploading to YouTube. My video camera uses those MiniDV tapes which would make transferring the video to the PC more work. But I think the video camera would probably focus better so it might be worth the effort.
I decided drilling holes for set screws isn't so bad. This video showed up as an option after I watch mine. Ouch! Making your own mecanum wheels looks like a lot more work than drilling a few holes.
I'm hoping the Rover 5 has enough power to drive these larger mecanum wheels. After my popsicle stick hexapod, I'm not very confident in my ability to guess power requirements (though I did suspect the hexapod legs would be too long for the servos).
All four wheels are drilled, have set screws and are installed on the Rover 5.
I'll work on getting some motor controllers working today. I'll wait a bit on adding the encoders.
I wired up a couple L298N H-bridge chips to power my newest Rover 5 chassis (thanks Ravenkallen).
Here's a video of the latest progress. It will hurt my feelings if you all don't watch this one (at least the first minute). (See edit.)
Edit: I'm leaving this video here as record of my mistakes. See post #49 for the reason the robot wont rotate and to watch a much better video.
It turns out the L298N chips can be used on a breadboard with a little persuasion.
So far, so good. I'm not really sure how to add the encoders without using a bunch of cogs. I have some code I previously wrote but it needs some polishing (with a jackhammer).
agfa
-Tommy
I agree you do need more power (along with encoders) to really get that thing humming. And IMHO a stronger chassis would help. Maybe something in a nice aviation plywood ...
Thanks for the feedback. I'm pleased with how the bot is progressing. I'm busy working on those encoders. I'm trying to balance sample time against refresh rate. If I check the speed too frequently, there haven't been enough encoder ticks to accurately measure speed, if I sample too infrequently the controls are very sluggish.
I'm pretty much back to where I left off with my other Rover 5 chassis (this one I bought off Ravenkallen). I think it will take some sort of PI or PID algorithm to get the wheels to respond well to the encoders. This time I'm not trying to get it all to fit in one cog. I'm using two cogs for the PWM motor control (I'm currently using an object by Kye. I will likely write my own object so the PWM will only take one cog) and one cog for the encoders (my PASM code is reading all four quadrature encoders in one cog successfully) and one for the main loop. I haven't decided if I'll run the PID algorithm (which I have yet to write) to run within the main loop or to use another cog for it. Oh, I'm also using a cog for Jason Dorrie's "RC_Receiver_6.spin" object that reads the RC receiver pulses. How many does that add up to now?
1 (Main Loop)
2 (PWM)
1 (RC pulses)
1 (Encoders)
1 (Serial Driver for Debug)
1 (Floating Point Math)
I count seven. I could do without the serial driver once I'm done with debugging the program. I'm seeing again why I used two Propellers with the other Rover 5 chassis (that's a bit on hold while I work with this chassis and the Vex mecanum wheels). I still a have a cog left to run a PID algorithm if I need it. I have'nt started adding any sensors yet so I might need to reclaim some of the cogs. As I said earlier, I'm pretty sure I could drive all four PWM signals from one cog with some PASM code (the LED array code drives 120 PWM channels with one cog using 595 shift registers).
I hadn't realized until just now, that if I use another cog for the PID algorithm, I might as well use Kye's PID, PWM with quadrature encoder object that requires a cog for each motor/encoder combination. I'm reluctant to do so since I could never get the PID to tune the way I'd like it too. My assumption is the encoders on this bot are too course for Kye's PID object (I'm not sure about this, I just might not know how to tune a PID).
I think I will probably give Kye's PID object another try.
I hadn't planned on posting code until I'm a bit further along. I'm sure I could be persuaded to post my "in progress" code if someone asks.
Tell me about it. I'm sure you know how much four powerful geared motors with encoders cost. Each one will probably cost as much as what I paid for this Rover 5 ($40). Even though they'd cost a bit, I'm seriously considering some more powerful motors with encoders.
This thing doesn't need to support a toddler. You probably recall, my other omni bot has an aviation plywood chassis.
And we've all seen this one: http://www.youtube.com/watch?v=YaTn-_354R4
I think more weight means better traction & performance.
Do mechanum wheels have any advantage over classic omni wheels? With four omni wheels you only drive two at a time to move forward or side to side. With these you drive all four which might give you more power?
In the x configuration, the omni travels fastest at a 45 degrees (only two wheels turning) whereas the mecanum travels fastest straight ahead (all wheels turning).
You can always get gearmotors make your own wheel encoders for cheap, Pal. A rite of passage IMHO!
The main advantage of these it the cool factor. Though I also like "classic" omni wheels. I personally like the classic omni wheels when three are used. I think they just look cooler that way and to someone who's not familiar with omni wheels, the robot looks like it shouldn't be able to move. At best they think it will just spin in place.
Here's a three wheeled omni wheeled bot I made a while back.
I borrowed this picture from erco's Retrobot thread.
I was able to attach the omni wheels without modifying the wheels at all. As I've mentioned several times, I had to drill the Vex mecanum wheeels to allow the Rover 5's axles to pass through the wheels and I also had to drill holes for the set screws.
I think the fastest a three wheeled version can travel is also when a wheel is in line with the direction of travel. With three wheels there a three lines that allow the fastest motion. With a four wheeled omni bot there are only two lines that give the greatest speed. Not that I'd want to race my three wheeled bot against a one with four motors.
I'd really like the encoders to be attached to the motor's shaft to get maximum resolution of the motor/gearbox system. I haven't seen many motor/gearbox combos that give access to the motor shaft.
I have added encoders to a Roboni-I robot. I attached the encoders (homemade, single channel) to the first gear after the motor's pinion. The Roboni-I's homemade encoders work well.
Technically, it's on the bottom of the protoboard. The crystal socket keeps the bottom of the protoboard from being completely flat in the center area. The wires I soldered to each IO pin also poked through the bottom of the protoboard a bit. To keep these obstructions from interferring with the breadboard, I added a layer of popsicle sticks to raise the level of the breadboard above the solder on the back of the Protoboard. I also added a layer of hard clear plastic from a "clam shell" type package because as I added components to the breadboard, it was being pressed against the soldering joints underneath. The solder joints with the clipped ends of wires would cut through the foam tape on bottom of the breadboard and cause a short with the breadboard's metal clips. (This was a puzzling problem for a while since the shorts were intermittent.)
I initially used the protoboard/breadboard combo on a BOE-Bot. At the time I didn't know there were breadboards this size for sale. The breadboard I'm using a larger breadboard I cut in half.
I have no idea what you're talking about.
Things were getting a bit cramped so I added heat shrink tubing to the resistor leads. The heat shrink tubing really let me pack the items closer together.
Here's another shot of the resistors that limit the current from the RC receiver to the Propeller (pins 0 - 5). I also used current limiting resistors with the encoders (pins 6 - 13). You can see I added a label with the pin numbers to the header.
Here's the other header with the IO pin numbers labeled. These pins control the L298 chips. Each L298 chip needs eight diodes. The breadboard is starting to get a bit crowded.
One power rail has 5V to power the RC receiver, encoders and L298 chips. The other power rail is connected to Vin (about 8V with freshly charged batteries). The only 3.3V device on the breadboard is the power on LED.
Here's the side with the power headers. You can see I added male headers for the jumper and servo connections. There's also a female header to connect IO pins to the servo's signal pin.
Here are a couple of shots that show the layers I mentioned.
Here's the "top" of the board with electrical tape to protect the wires from batteries that slide in and out past them.
Under the tape are the wires that bring the IO pins out to the headers.
I end up using this board a lot. I keep meaning to make another.
...would be non-conductive fabrication risers...
Excellent thread on this project! Well done!
Thanks Rick. It's nice to know people are watching my progress.
I'm currently uploading a video showing off the new encoder algorithm. The encoders help a lot with control. YouTube says the video should be ready in 32 minutes. Stay tuned.
Two of the wheels (front left and rear right) were turning the wrong direction to rotate the robot. The characteristics that allow a robot to travel sideways with mecanum wheels also allow the robot to remain stationary while all four wheels turn. Basically the left side was telling the robot to go right and the right side was trying to get the robot to go left. The net result was the robot stayed put, fast.
The fix was changing a "0" to a "2" in one of the "if" statements.
While this programming error kept the robot from turning in place, the robot had other problems from not knowing how fast each wheel was turning. Encoders to the rescue!
Adding encoders made a huge difference! I added the following PID algorithm:
PUB Pid | localIndex, maxOut repeat while cnt - previousTime < dt 'waitcnt(dt + cnt) previousTime += dt maxOut := 0 repeat localIndex from 0 to _TotalWheels - 1 error[localIndex] := rampedWheelSpeed[localIndex] - bufferSpeed[localIndex] integral[localIndex] := integral[localIndex] + (error[localIndex] * dt) derivative[localIndex] := (error[localIndex] - previousError[localIndex]) / dt output[localIndex] := (Kp * error[localIndex]) + (Ki * integral[localIndex]) + (Kd * derivative[localIndex]) if ||output[localIndex] > maxOut maxOut := ||output[localIndex] previousError[localIndex] := error[localIndex] if maxOut > _MaxSpeed repeat localIndex from 0 to _TotalWheels - 1 output[localIndex] := (output[localIndex] * _MaxSpeed) / maxOut DriveSingle(localIndex, output[localIndex]) else repeat localIndex from 0 to _TotalWheels - 1 DriveSingle(localIndex, output[localIndex])The above code was based on the PID pseudo code I found on Wikipedia. I used a Kp of 10 with Ki and Kd both remaining zero. With both Ki and Kd zero, I guess the code is just a proportional algorithm. I tried making Ki equal to one with Kd either one or zero. Both of these attempts at adding an integral component caused the motors to oscillate wildly.
Edit (June 20, 2012): I revisited this PID method for a different project and realized the above code has some severe problems when using the Prop's integer math.
I had neglected to scale the motor speeds in my earlier attempt. The code in my first attempt just limited the top speed of any motor to 1000 (the limit of Kye's PWM driver). My new code scales all motor speeds based on the speed of the fastest motor. For example if the fastest motor speed was computed to be 2000 then all motor speeds would be divided by 2. The scaling code is part of the above "Pid" method.
So here's the video. The robot is looking pretty good in my opinion.
So far, I'm really liking these Vex mecanum wheels. Thanks for the information about them erco.
As I said in the video, now it's time to turn this radio controlled vehicle into a robot. I might start with some IR and ultrasound sensors since those are relatively easy to implement. I, of course, will need to add one of the machine vision options to this robot in order to live up to this threads title.
I think this would show off its current weakness. The robot rc car can travel forward, back, side to side and at 45 degree angles just fine. I've noticed it still has trouble with angles that aren't multiples of 45 degrees. I think the encoder algorithm still needs some tweeking. To be honest, I'm surprised it works as well as it does.
I had looked up PID on Wikipedia and translated the pseudo code they had there to Spin and it just worked (as long as it didn't try to add any I or D).
I'm currently trying to merge the PWM code in with the encoder code in order to free up two cogs. I had planned to fiddle with the various encoder parameters later to try to get this rc car travel smoothly at all angles (in a single plan for now).
I'll likely take a break from coding and drive around couple of plates.
Show erco some love, and give it a spin around the plates...:)
-Tommy
Thanks Tommy. I'm really pleased to see how much the encoders helped. I was also pleased I could monitor all four quadrature encoders within a single cog.
erco already knows I'm working on a figure 8 project. He knows my weak will is no match for his power of suggestion (I have a Roomba, Roboni-I, $4 ultrasound sensors and purple batteries to prove it). And for some reason my robot arm is calling out to me to use it.
I am not going to drive the robot around the plates (with or without lobster) using remote control. I do have some pride. This will be an autonomous figure 8.
I'm using a couple of L298N breakout boards. I've added the Schottky diodes to one of the controllers so far.
Here's a picure of the two boards.
I drilled a couple of holes in the bottom of the Rover 5 so I can hold these boards in place with some standoffs. Here's a picture of the two boards set in place.
The board with the diodes is on the left in this picture. Since the L298 chips never even got warm when I drove the robot, I'm hoping mounting them upside-down like this will be okay. Other mounting positions I can think of take up too much space. I suppose I could add a small fan to blow air past the chips if they get too warm mounted this way.
I have some surface mount Schottky diodes. I'm thinking of using the smt diodes on the second board to see which type of mounting configuration I like more.
I plan to use the Propeller Proto Boards I made at the beginning of this thread with this robot. I removed the SN754410 chips from the boards since I'll be using these L298N chips to control the motors.
These Vex Mecanum wheels are so large, I'm thinking I may use the LED array on the robot after all. I had previously thought the array looked too bulky but with these larger wheels, it might look okay.
I still hope to use some sort of machine vision with this robot and I thought it would be fun to use the LED array to output what the robot was "seeing".
Jim
The through hole diodes are these from SparkFun. I purchased 100 so they were $0.12 each.
The surface mount diodes I purchased from Digi-Key. Part number 641-1014-1-ND. I also purchased 100 of these so they were $0.147 each.
As I mentioned in my earlier post, I liked the surface mount diodes much more than the through hole diodes. They were much easier to fit on the small board and actually made the soldering job easier.
I also like using surface mount resistors and capacitors more than their through hole counter parts. The little 0603 resistors fit nicely between leads spaced 0.1" apart.
I prefer to answer the questions here so others can read my answers.
I as asked to elaborate one the processor used.
I'm using a Parallax Propeller as the processor for this project. The Propeller chips come mounted on Propeller Proto Boards. I usually buy five at a time.
The normal Propeller Proto Boards need a Prop Plug to communicate with a PC. I've managed to burn out two different Prop Plugs so now I make my own by cutting the USB section out of a Propeller Proto Board USB. I buy these four at a time. I add header pins the remaining portion of the board so it behaves like a normal Propeller Proto Board. A PPB USB (buying four at a time) costs $10 less than buying a PPB (five at a time) plus a Prop Plug.
I know I've posted pictures of my DIY Prop Plugs on the forum, and I'll post them again if requested.
One PPB is used to read the encoders, control the motors and monitor the radio connection with the remote.
A second PPB is used to read the video image and control the LED array. I think there are some details about these two boards (though out of date) in post #8.
I'm no longer using the Mecanum wheels from SparkFun. I'm using the ones erco recommended from Vex.
I am still using the Rover 5 platform from SparkFun.
I was asked about using an Arduino with this setup. I'm pretty sure the Arduino couldn't read the four quadrature encoders and do much of anything else. The Propeller is a great microcontoller to use with this projects because of the many things happening at the same time. I can assign the various tasks to different cogs with one cog bringing the data gathered by the other cogs together and making decisions based on the data.
I think an Arduino would just be in the way with this project.
Here's one of the places to find more information about the Propeller.
I'm presently working on a remote to use with my various robot projects. This project, the hexapod project and some others will be updated once I have the remote working correctly.
I was the one asking the questions in e-mail.
Let's say I'd like to built this thing too, and add a GPS unit so it can drive itself from point A to B; what would I need other than the Rover 5, the PPB, the wheels? I guess I need some kind of ESC for the motors - you mentioned the L298N + some diodes.
Sorry if this is a very beginner question; I'm just getting into robotics.