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.
Welcome to the forum zoltan.
Beginner questions are fine with me.
Yes, I'm using L298N to control the motors. Post #57 shows the two L298N controllers on beakout boards. I think there's a link to the L298N chips in post #27. I linked to the diodes I used in post #59 (Oops, I never linked to the surface mount diodes. I'll fix that soon.)
Most GPS modules output a string that could easily be read by the Propeller. There are several objects in the OBEX (there's a link at the top of each forum page) to help use a GPS unit with a Propeller.
You might want to keep in mind these Mecanum wheels aren't as efficient as normal wheels. They're also not going to perform as well off-road as a lot of other wheels or the original treads of the Rover 5. Mecanum wheels are great for moving sideways etc., but you trade maneuverability for efficiency, speed and power. You'll use more power traveling with Mecanum wheels than traveling with normal wheels.
These Mecanum wheels might not be efficient, but they sure are cool to watch.
So depending on the goals of your robot, a different set of motors and/or wheels might be a better choice.
I just looked back threw this thread to see if I had posted the code for the RC version of the Mecanum robot. I hadn't. So here it is.
mikea asked about using a RC receiver to control PWM to a motor. This code does that. It uses Jason Dorie's object to read six RC channels and PWM code from the OBEX (I think by Kye) to control the motors. The PWM code can only control two motors so I use two instances of the object.
The four sets of quadrature encoders are read with one code using code based on one of JonnyMac's Spin Zone articles.
I'm currently making a major modification to this robot. Instead of a RC transmitter and receiver as a remote, I'm going to use a pair of Nordic nRF24L01+ modules. This will let the remote receive information back from the robot.
Edit(3/11/15): I have deleted the archive VexMecanumPid120301h - Archive [Date 2012.03.03 Time 21.29].zip (151 views)
I plan to upload this program or an improved version to my GitHub account.
If there isn't a replacement on GitHub send me a message and I'll make sure to upload the replacement code.
I just looked back threw this thread to see if I had posted the code for the RC version of the Mecanum robot. I hadn't. So here it is.
Thanks much for posting the Mecanum direction code, as I was very interested to see an implementation for the angle/speed calculations for each wheel, to accomplish a desired overall motion direction.
In your video you mentioned having the best success with moving in exact multiples of 45 degrees in your heading. Is that still the case? I'm guessing that this is either just a basic result of having 4 wheels, or due to the shape of the wheels themselves. Does anyone have any info on whether real arbitrary (non-multiples-of-45 degrees) direction motion should be straightforward to accomplish?
I should ask, are you still using the motors that came with the Rover 5, or should I replace them when I attach the Mecanum wheels?
Thanks much for blazing such a clear trail. Now I have to go shopping, and start inching along the path you've cleared so well.
I'll start a new thread for my robot once I have it at least moving.
In your video you mentioned having the best success with moving in exact multiples of 45 degrees in your heading. Is that still the case?
I fiixed this problem. It was a bug in the code where I didn't take into account the rounding error the integer math causes. After fixing this bug, I had the robot moving in any arbatrary direction. I don't think I made a video of the improved driving ability before I started modifying the robot to use a different remote. I still haven't finished my "new and improved" robot remote since I caught a severe case of "quadcopter fever" and I haven't been working on my ground based robots lately.
I'll look through the code I posted to make sure it includes the 45 degree only bug fix. The code I previously posted has the bug. I'll post a version with the bug fix soon.
I used the stock motors with the Rover 5. If you're thinking of using different motors, I'd suggest skipping the Rover 5 all together and just make a custom chassis to hold the more powerful motors. With powerful motors, the encoders aren't as necessary. With the relative weak motors of the Rover 5, the encoders are needed for slow speed navigation.
If you don't already have a Rover 5 chassis, you might want to think about getting more powerful motors. Another forum member as a robot with these Vex Mecanum wheels which uses more powerful motors and his robot really moves well. More powerful motors will likely cost a lot more than using the Rover 5 though.
As I mentioned earlier in the thread, mounting the Vex wheels to the Rover 5's motors was a challenge.
I'm not convinced the L298N motor control chips are the best option for driving the Rover 5 motors. Gordon McComb suggested there are multiple motor drivers that should work better than the L298 chips at the voltage I'm using . I have several different H-bridge chips I've been meaning to try out. I haven't had time to try out which of these H-bridges will work well with the Rover 5 motors.
With powerful motors, the encoders aren't as necessary. With the relative weak motors of the Rover 5, the encoders are needed for slow speed navigation.
Interesting to hear you say that now, I wondered how necessary they were. As you say, everything's better with mo' power and money.
Oh, you didn't say money. Ah well, I still stand by it, Captain Quadrotor!
Interesting to hear you say that now, I wondered how necessary they were.
I still think the encoders are very necessary in order to use Vex Mecanum wheels with the Rover 5 chassis, but after seeing Rich's powerful Mecanum wheeled robot, I had the impression the power of the motors allowed the wheels to spin a a predictable rate even at low speed settings.
I think the encoders might still be necessary for autonomous navigation with the Mecanum wheels even with powerful motors.
I'm pretty sure the four motors Rich is using cost much more than what the Rover 5 chassis costs. Still, if I were to start from scratch and wanted to build a Mecanum wheeled robot, I'd be very tempted to spring for the more powerful motors and mount them to some sort of homemade chassis. Not only would this approach require more money, I think it would also require more time.
I'm still very pleased with how well the Rover 5 moves with these encoder enhanced Mecanum wheels.
I'll look through the code I posted to make sure it includes the 45 degree only bug fix. The code I previously posted has the bug. I'll post a version with the bug fix soon.
I used the stock motors with the Rover 5. If you're thinking of using different motors, I'd suggest skipping the Rover 5 all together and just make a custom chassis to hold the more powerful motors.
As I mentioned earlier in the thread, mounting the Vex wheels to the Rover 5's motors was a challenge.
I'm not convinced the L298N motor control chips are the best option for driving the Rover 5 motors. Gordon McComb suggested there are multiple motor drivers that should work better than the L298 chips at the voltage I'm using .
Thanks, I'll look forward to seeing the diffs between your new and currently-posted code.
The Rover 5 (w/Vex wheels) looks too cool to resist, so I'll work on getting that going first.
Lastly I have a very accurate compass (3-axis Magnetometer) that I'll use to maintain my desired heading along with the encoders: http://www.pololu.com/catalog/product/1273
It has given me a heading indication that's repeatable within +/- 2-3 degrees, and is independent of tilt, i.e., going up-/down-slope.
My mapping data I'll gather with various sonar sensors, measured starting from some corner of the room. They're accurate to 1/4"-1/2" over 10+', so I hope to be able to gather pretty accurate maps of the rooms in my home.
My Rover 5 should arrive by next weekend, so I'll post a photo as soon as I get the boards attached to it, and will start drilling the wheels as you demonstrated as soon as they arrive.
I don't have an updated version of the program (at least I couldn't find one) with the bug fix and using a RC type TX and RX.
Since posting the buggy code above, I changed the code to use a second Propeller board acting as the "remote" transmitter. The "remote" Prop was connected to both a PlayStation 2 controller and a Nordic nRF24L01+ (similar to the setup a described at the beginning of this thread).
I just now went through and made changes to "VexMecanumPid120301h" in order to fix the integer math bug. Unfortunately, my Rover 5 isn't setup to use with a RC system right now so I can't test the version I'm attaching here. The Propeller board currently attached to my Rover 5 also has different pins connected to the RC receiver, encoders and motors. I'll need to modify this code yet again in order to test it with my current setup (after connecting a RC receiver to the board instead of the Nordic transceiver).
I didn't see a Propeller board mentioned in your list of items you've purchased. The attached code will only run on a Propeller microcontroller.
While it should be possible to write AVR versions of the algorithms used in this program, I strongly doubt the ATmega 328 (or the ATmega 1280 on the Dagu Spider) will be able to perform all the tasks needed fast enough to match the functionality of the Propeller. I don't think the ATmega 328 can read in the pulse lengths of the four channels of the RC receiver and also monitor all four quadrature encoders. I'm not positive the ATmega can't meet these challenges, but I have a strong gut feeling it wouldn't be able to perform all these tasks.
The Propeller is an ideal match for this type of project since this project can greatly benefit from the Propeller's parallel capabilities. The Prop's multiple cogs allow it to monitor multiple inputs (encoders, RC receiver) and control multiple peripherals (motors), simultaneously.
I think a single Propeller Protoboard would out perform both the AVR boards you listed.
Unless you already know how to program AVR chips and have other uses for the AVR boards, you might want to concider returning the boards while they're still brand new.
Mapping rooms in your home will be a very challenging (and fun) task. With one of my robots, I kind of cheated and just had the robot memorize (record on a uSD card) the comands it sent to the motors (CR servos) so it could then replay (autonomously) the course it drove while under human control.
One inexpensive sensor to use in your mapping efforts could be a ultrasound sensor. They're cheap enough you might want to get several.
I'm curious where you purchased your Rover 5? In order to use Mecanum wheels, you want to make sure you get one with motors on all four wheels. I've seen Rover 5s for sale that only have two motors.
Do you have suitable nuts and bolts for mounting the wheels to your robot? I used metric 3mm bolts but I think 4-40 hardware (edit(10/14/12): #6 or #8 hardware would probably be a better choice) would also work for securing the wheels.
I look forward to seeing your robot up and running.
Edit(3/11/15): I have deleted the archive VexMecanumPid120301h121007a - Archive [Date 2012.10.07 Time 01.27].zip (67 views)
I plan to upload this program or an improved version to my GitHub account.
If there isn't a replacement on GitHub send me a message and I'll make sure to upload the replacement code.
Thanks much for the code update. I look forward to applying it soon.
As you wrote, I want to try this with an Arduino-compatible board first. I e-mailed back and forth with Russell, the Rover 5 Designer(?), and he opened my eyes to the fact that I need an MCU with more pins than the Romeo I bought can bring to the table.
Specifically, as many people have written, to implement the Rover 5 fully, we need our MCU to have 4 External Interrupt input pins, plus 8 more to supply PWM and Direction outputs to the motors. And I need two more pins for TX and RX for the XBee to talk with my laptop.
With that in mind, today I ordered an "Arduino Mega 2560 R3"+XBee/SD Card shield, as it should have more than enough pins to implement the Rover 5.
Interestingly, I also looked in detail at the Spider MCU's Instruction Manual. I was surprised to read where it points out that driving Servos consumes more pins than one might imagine (i.e., for Timers, as well as for the Servo signals themselves), such that the majority of the PWM-capable pins become unavailable :-(.
I'll switch to using the "Arduino Mega 2560 R3" once it arrives.
My nephews gave me a Propeller evaluation board for last Christmas, so I can switch to that if need be. I'll give them the Romeo and its IO Shield for Christmas this year :-).
I bought my Rover 5 from Sparkfun. I haven't had time to take it apart yet, but the box says it has "4 motors and 4 encoders". They sell several flavors of it.
I'll study your very helpful photos and text on mounting the wheels, then go to a nearby surplus store to buy some long, thin (#4, etc.) bolts and nuts to make the setscrews as you did. I'll cut off the heads and slot them with a Dremel tool, to make the bolts into setscrews.
Once I get the wheels mounted, I've got to port your code to the Ardunio environment.
I.e.,I need to read up on how to use the Interrupt Service Routine code that other posters have described, to keep track of how many rotations my wheels are turning, and implement the Mecanum angle-calculating code, so lots to figure out there before my robot is moving in any organized fashion.
More news as it develops, hopefully by the end of this week,
Once I get the wheels mounted, I've got to port your code to the Ardunio environment.
I'm afraid this will likely be a major challenge. It's not just a matter of translating Spin to C. The Propeller has eight different processors and the program is run in parallel on these different processors (cogs). Two cogs control the PWM to the motors, one cog watches the RC receiver input, one cog monitors the quadrature encoders, there's also a communication cog with a software UART. A master cog monitors all the other activity and issues appropriate commands.
With all the various cogs working on their own problems, there isn't a need for interrupts.
I'm extremely skeptical any Arduino can do all this.
I look forward to seeing your robot up and running.
I've got it assembled (see attached), and am pondering optimal board arrangement, to see if I can minimize the rats-nest aspect of the wiring going to-and-fro between the Arduino Mega 2560 R3 and the Dagu 4-Motor Controller board.
I'll post again once I get it wired up to report if I at least got it moving. The Motor Controller Board worked fine with the Romeo (and some other motors I had laying around), so I know that at least that much is working. Now to test it with the Mega and the Rover 5's motors.
*EDIT:
I found the Motor Encoder Lead Color Code in the Rover 5 doc:
RED is +5V for the encoder
BLACK is 0V (ground)
WHITE is signal A
YELLOW is signal B
*EDIT2:
Oddbot's comment about the Rover 5's Motor Power Leads being opposite what's silkscreened on the Dagu 4-Motor Controller board is here:
> It seems that the connectors on the rover are not wired to be connected
> to the dagu controller...
No, just a case of an uneducated Chinese laborer accidentally soldering
the wires back to front. It only takes a minute to unclip the wires from the
socket and swap them over.
Lastly, I have to say my heartfelt thanks to you, for all your VEX-wheel-setscrew-adding detailed postings, especially the taping up the wheels near the drill. My tape got chewed, rather than my wheels, which is very good.
I carefully followed in your footsteps, and the results turned out at least ok.
Evaluating beyond that will come once I have can implement some Arduino Mecanum + Interrupt / Encoder code (which I have yet to find any detailed postings on) and see how accurately I can control the robot's direction.
As for my VEX wheel setscrew construction, I used my Dremel drillpress, lots of clamps, and a #50 drill to make pilot holes, then drilled them out with a hand drill and a #21 drill. I drilled out the axle holes with the #21 drill as well.
This was for using #8x1-1/4" pan-head screws. To make the wheels more stable, I wanted the biggest contact area I could get pressing on the driveshafts, so I went with #8 screws rather than #4 ones.
Using my Dremel tool, I cut the heads off of them, then notched their tops, to make them into setscrews. I ground the #8 nuts into triangles, to make them fit in the tiny space between the VEX wheels' spokes.
I used the Dremel "waffle wheel" for grinding and heavy cutting, and the thin "cutting disk" for cutting and notching the screws, because it's much thinner than the "waffle wheel", so the former is best for making thin notches, i.e., to make a screwdriver slot.
Lastly^2, I found that using a hammer and center-punch on the driveshaft, while supporting the original Rover 5 wheel on the edge of a table, allows one to remove the original wheels without pulling the driveshaft out of the motor's gear assembly (which is a colossal pain to put back).
I've got it assembled (see attached), and am pondering optimal board arrangement, to see if I can minimize the rats-nest aspect of the wiring going to-and-fro between the Arduino Mega 2560 R3 and the Dagu 4-Motor Controller board.
Wow, very cool. It was really strange to see a Vex Mecanum wheeled Rover 5 that wasn't mine. My brain kept telling me "Hey, that's a picture of my robot" but I had to keep telling my brain it was wrong.
BTW, are the Rover 5's white and yellow wires "ENC1" and "ENC2"? Does it matter which one I connect to "ENC1" vs. "ENC2" on the motor controller? I recall that you made your own motor controller from scratch, so I'll leave this question and the following ones in, in case someone else can answer them.
The answer here is "it depends." As far as the board's "interrupt output" logic is concerned, it doesn't matter which wire is connected to which connector. Either way the wires are connected the output from the "interrupt" line will be the same.
If you're using the "interrupt output" from the motor control board instead of having Mega reading the quadrature encoders directly, it wont matter how the encoders are connected.
If you are going to read the quadrature encoders directly with the Mega, then the order will matter. The order will depend on what the software expects to see from the encoders based on the direction of the motor's rotation. I describe what I saw with my encoders in post #2 of this thread. I'm not positive all the encoders worked the same. If the encoders are connected backwards the software will usually cause the motors to spin at full speed no matter the input since the program will interpret the encoder signals as the motor not spinning fast enough in the desired direction (since it will appear to be spinning backwards). The program will keep trying to increase the speed of the motor which will have the result of the motor spinning at full speed.
If the motors spin at full speed when using a program that reads the quadrature encoders directly, you'll need to switch the order of the encoders. You can switch the order of the encoders either as they plug into the motor board or you could switch the order of the wires (from motor contoller board to Mega board) where they connect to the Mega, or you could also just change the pin assignments within the program.
It's always a good idea to test out each part of the robot as you're building and programming it. I had my program output to a terminal window the encoder values and then manually turned the wheels to check to see which direction produced positive distance measured. I also tested which way the motors turned when given forward and reverse commands.
You wont need to worry about the order of the encoder wires if your program is just using the "interrupt output" line and not monitoring the encoders itself.
The "interrupt output" lines wont tell the Mega which direction the motors are turning, but this often isn't a problem since the control program already knows which direction the motors are turning since the program is issuing direction commands to the motor control board.
Relatedly, none of my Rover 5's motor leads wire (Red & Black) colors matches the "CH1+" and "CH1-", etc., silkscreening on the Dagu 4-Motor Controller board (the connectors snap onto the board only 1 way), with the other 3 are backwards.
Will my motors burn up if I hook them up as is, or will they just run backwards from what I expect?
It wont hurt the motors if they are plugged in backwards. They will just turn the opposite direction from what is expected.
If all the motors turn backwards from what is expected, then turn your control board around and make the front of the robot the back of the robot.
The connectors can be removed from the plastic housing and switched if you want to reverse the direction of a motor. It should also be possible to reverse the direction the motors turn from software.
Lastly, I have to say my heartfelt thanks to you, for all your VEX-wheel-setscrew-adding detailed postings, especially the taping up the wheels near the drill. My tape got chewed, rather than my wheels, which is very good.
It's great to see someone else using this method of attaching Vex Mecanum wheels to a Rover 5. It makes me very glad I took the time to document my efforts.
As for my VEX wheel setscrew construction, I used my Dremel drillpress, lots of clamps, and a #50 drill to make pilot holes, then drilled them out with a hand drill and a #21 drill. I drilled out the axle holes with the #21 drill as well.
This was for using #8x1-1/4" pan-head screws. To make the wheels more stable, I wanted the biggest contact area I could get pressing on the driveshafts, so I went with #8 screws rather than #4 ones.
I realize now that #4 hardware is slightly thinner than 3mm hardware. In hindsight, I don't think it was a good recommendation. A #8 screw sounds like a good idea.
Using my Dremel tool, I cut the heads off of them, then notched their tops, to make them into setscrews. I ground the #8 nuts into triangles, to make them fit in the tiny space between the VEX wheels' spokes.
I used the Dremel "waffle wheel" for grinding and heavy cutting, and the thin "cutting disk" for cutting and notching the screws, because it's much thinner than the "waffle wheel", so the former is best for making thin notches, i.e., to make a screwdriver slot.
This sounds like a really good idea. I'm sure your #8 screws were easier to slot than trying to cut a slot in 3mm screws. If I add set screws to any more Vex Mecanum wheels, I'll probably use your method.
Lastly^2, I found that using a hammer and center-punch on the driveshaft, while supporting the original Rover 5 wheel on the edge of a table, allows one to remove the original wheels without pulling the driveshaft out of the motor's gear assembly (which is a colossal pain to put back).
I've read in SparkFun's comments section of the Rover 5 that other people have had problems with pulling the drive axle out of the gear assembly. I myself haven't had this problem. All of my wheels have easily pulled off without taking the axles with them.
What do you plan to use as a remote? Are you going to use RC gear? Of course a real robot doesn't need a remote since it should be able to find its own way around, but even an autonomous robot would likely need some sort of input device.
You might want to keep in mind these Mecanum wheels aren't as efficient as normal wheels. They're also not going to perform as well off-road as a lot of other wheels or the original treads of the Rover 5. Mecanum wheels are great for moving sideways etc., but you trade maneuverability for efficiency, speed and power. You'll use more power traveling with Mecanum wheels than traveling with normal wheels.
In forward movement, there is no loss of speed with Mecanums. There is less traction then a comparable standard wheel, however due to the roller design it can in some cases provide more climbing power than a smooth rubber wheel. I have found the Mecanums to perform much better than expected off road but I would not put it up against a purpose built off road vehicle. Here is a video showing how it can climb onto a Roomba. http://www.youtube.com/watch?v=tCQJNTj4Zmg
Power (as in pulling or pushing power) is not reduced by using Mecanums. The limiting factor for my Mecanum robot as far as pulling or pushing goes is either the motors or the surface the wheels are on. On a non slippery surface the motors will stall before the wheels slip.
In forward movement, there is no loss of speed with Mecanums. There is less traction then a comparable standard wheel,
Rich, I'll take your word for it and as I think back at watching these robots, you're right, they do move at the same speed the wheels are turning (going forward or backward).
Power (as in pulling or pushing power) is not reduced by using Mecanums. The limiting factor for my Mecanum robot as far as pulling or pushing goes is either the motors or the surface the wheels are on. On a non slippery surface the motors will stall before the wheels slip.
This is very good to know. Thanks for setting me and the record straight about Mecanum wheels.
Edit: I think one of my reasons for thinking Mecanum wheels were inefficient was because of this post on SparkFun's Mecanum wheel product page. About half way down the comments is a post by JWRM22 which in part says:
A disadvantage of these wheels is the efficiency and control trouble. Autonomous drive is hard with these wheels, because there are plenty of variables that are hard(er) to predict. But thats just a challenge. The efficiency of these wheels is the square root of 2 (theoretical…) because the inner rollers are turned by 45 degrees or 1/4pi rad.
Its worth it to google “macanum wheels”, “mecanum algarithm” for nice information like an algarithm that makes your robot. It will also explain the square root of 2.
What do you plan to use as a remote? Are you going to use RC gear? Of course a real robot doesn't need a remote since it should be able to find its own way around, but even an autonomous robot would likely need some sort of input device.
I'll start a new post to document the details of my plans, and my update progress in implementing them (I'll post a link to it here once it's up). In brief, let's see if I can hit the highlights here:
1. Switchable between autonomous and remote control from my laptop, via XBee.
2. App#1 is to map out the room (including furniture), and display the map in a Java program running in my laptop, that I've already partially written.
3. Autonomous exploration is via a steerable front-looking Sonar mounted on a servo, and IR transceivers on the sides to detect imminent tangential side-collisions. The sonar is accurate to 1" in 10'.
4. Navigation is via a 3-Axis Magnetometer (which I already have working to +/- 2 degrees), combined with "following walls" by turning the Sonar (via its servo) towards the nearest wall, to maintain a constant distance running parallel to the wall, and periodically checking the distance to the upcoming perpendicular wall. I'll thus proceed to pick a coordinate system for the room, to determine its dimensions, and to maintain a desired path across it.
5. App#2 is to pick a point on the map, and then the robot (ultimately more than one) will hunt down balloons laying about on the floor in the room, and herd them to that spot, using 2 "Ducted Fans" from R/C electric Jet Planes. My battery at present is 2S 2.5Ah 7.4V 6C Li-Po, with the likelihood I'll change it to a higher Amp-Hour battery later on. I have to match the Fans' current/voltage with the battery (so I could upgrade the Fans and battery together), while ensuring that I don't draw too much current through the Romeo or whatever other Motor Controller I use to drive the Fans.
6. App#3 is for multiple similar robots to collaborate in sharing new map-data discoveries (i.e., the sofa), and locating and herding the balloons, sharing data via XBee Mesh networking between themselves and to the laptop.
More on all this in my separate posting as I progress.
I just stumbled upon this thread doing some research for a robot we currently built. The chassis was thrown together ourselves but we have been considering maybe building another one with the rover 5. We are having huge issues with the PID and are currently using the arduino mega. I think it is because we dont understand exactly what is happening with the PID equations as we should. We just can't get the damn thing to move straight or sideways in a slow controlled manner the wheels seem to not want to match up correctly. We have even tried writing a small type of code where we have a master wheel and the other three are trying to match the master wheel. This may be due to using continuous servos as our motors with encoders attached for feedback. Hopefully you two still look at this thread really could use some help! I might even jump over to that parallax chip as it seems very interesting with the parallel processing.
[...] We are having huge issues with the PID and are currently using the arduino mega. I think it is because we dont understand exactly what is happening with the PID equations as we should.
Please post your code as an attachment, or send it to me as a message, and I'll take a look an see if I can find any issues in it.
@amano001, Sorry I missed you post. I'm glad Cliff replied.
I doubt you need full blown PID. Proportional feedback is usually enough with these type of robots.
I don't see any encoders on your robot? You don't really need encoders if you're driving the robot remotely and your motors are powerful enough, but if your motors are underpowered like the Rover 5 then encoders are needed to move at slow speeds.
While the Rover 5 is reasonably priced, it has its shortcomings. I have a thread here discussing some of the pros and cons of the Rover 5.
I haven't used Vex motors myself but the ones you have on your robot, look like they're on the small side for this application. The motors may need encoders in order to be useful at slow speed.
I don't know if the Arduino Mega can read four quadrature encoders and perform the other calculations needed to control a four motor robot. Projects like this (with lots of sensors and things to control) is where the Propeller really shines.
I've been working on both my Rover 5 robots a lot lately. I added a QuickStart board and two inexpensive L298N motor control boards to my treaded Rover 5. It worked pretty well so I decided to try the same control board in my Mecanum wheeled Rover 5. The control board was easy to switch between robots. I'm like how the code is coming along.
Here's the Mecanum wheeled Rover 5 with the alternate control board in action.
There's another Mecanum wheeled Rover 5 on LetsMakeRobots.
I'm trying to figure out how to position the various PCBs and battery on the robot to keep the the robot relatively sleek. I'd really like to figure out some sort of cover for the electronics. I found having a rats nest of wires bothersome when I drove the treaded Rover 5 out in the snow. I'm also trying to figure out some sort of turret to which I plan to mount sensors.
I've attached the lastest code I'm using on my Mecanum wheeled Rover 5.
The code is heavily commented. See post #60 the Rover 5 thread for some additional instructions on how to use the object.
I recently realized this code could easily be used to make a Propeller board a slave to another microcontroller. Since I've included a way to enter wheel speeds through a terminal window, it should be easy for another microcontroller to send motor speeds over a UART to the Propeller.
I ought to (and plan to) add a few Mecanum specific commands so a master microcontroller (Arduino or BS2) could send joystick x and y values through the UART and the Propeller would then use this information to control the Rover 5 (or other four motors with four quadrature encoders robot). I'll probably add a direction, magnitude and rotation option as an additional way of controlling the robot through a UART.
Edit(3/11/15): I have deleted the archive Demo4WDBot130226e - Archive [Date 2013.02.26 Time 23.24].zip (114 views)
I plan to upload this program or an improved version to my GitHub account.
If there isn't a replacement on GitHub send me a message and I'll make sure to upload the replacement code.
Hey guys! Glad to see your still active on the forum. I had lost hope lol. I will update pictures and code by the weekend. We actually switched over to the rover 5 chassis after seeing the success you guys have had. Our chassis was giving us issues with the shafts of our servos and the encoders on them.
We are using the Rover 5 chassis with vex mecanum wheels
Arduino Mega
Beagle Board - Computer vision
Ultrasonics for XY positioning on a board
forgot to add
Dagu 4 channel motor controller (Question if the properller board is sending out a 3.3v pwm signal and the dagu seems to be 5v will this cause a huge issue?, btw what do you use for h bridge motor controllers)
We are not sure exactly how to implement the PID. We were looking at the arduino library PID that someone made and tried to mess with it a little. We are not sure exactly how to go about using the PID. What should our set point be? Originally we were trying to use a master wheel for our setpoint and have the other wheels try to match that. But not sure if this is the right approach. We just need to make sure the robot when it moves always stays parallel to a wallno matter if its moving or stopped.
we were looking into using one of the propeller proto boards instead of the arduino mega as we have seen the code response get very sluggish with interrupts going off all the time for the encoders. But we are currently trying to figure out if the dagu 4 channel motor controller will have an issue with receiving 3.3v pwm signals instead of the arduino megas 5v pwm signal? Any idea thanks!
we were looking into using one of the propeller proto boards instead of the arduino mega as we have seen the code response get very sluggish with interrupts going off all the time for the encoders. But we are currently trying to figure out if the dagu 4 channel motor controller will have an issue with receiving 3.3v pwm signals instead of the arduino megas 5v pwm signal? Any idea thanks!
Got the one with 5v regulator so we can run some of our other servos/sensors off the board as well.
The board you linked to doesn't have a 5V regulator but I still think it's a good board. You should have 5V from your other boards you could use to power the servos or use a cheap regulator from ebay for your 5V line. (Maybe you have the Propeller Proto Board (which has a 5V regulator) and not the Project Board?)
You could use the Propeller board (either the Project Board or a QuickStart) as a slave to your other boards. As the code is now it can be controlled from a serial line by sending the motor number followed by the speed. A carriage return indicates when the end of the number has been received.
I haven't found many 5V devices that wont read 3.3V as logic high. I doubt the motor controller will have a problem with the Prop's 3.3V signal. If needed, you could use a level shifter.
I'm using a couple of $4 motor controllers I purchased off ebay myself.
I've been working on adding a compass today but I plan to add support that will allow the Prop to take care of all the trig itself. A master microcontroller would just send direction, speed and rotation information and the Propeller would compute the wheel speeds based on this information.
The parent uC could take care of sensor readings and navigation decisions while the Propeller chip kept the motors turning at the correct speeds based on the signal from the master uC.
While I think the Propeller is a great uC to learn to use with robotics, by using the Prop as a slave device you could then free the Arduino to take care of higher level stuff. This should speed up your ability to having a working robot instead of needing to learn to program the Propeller yourself. You could then learn to program the Propeller at your leisure.
Edit: I hadn't seen your last post when writing the above. I see I was preaching to the choir.
BTW, I really like your robot. Very cool.
Edit: Apparently I was suffering from temporary blindness. The board you linked to does indeed have a 5V regulator. My brain saw the Propeller Project Board.
Comments
Welcome to the forum zoltan.
Beginner questions are fine with me.
Yes, I'm using L298N to control the motors. Post #57 shows the two L298N controllers on beakout boards. I think there's a link to the L298N chips in post #27. I linked to the diodes I used in post #59 (Oops, I never linked to the surface mount diodes. I'll fix that soon.)
Most GPS modules output a string that could easily be read by the Propeller. There are several objects in the OBEX (there's a link at the top of each forum page) to help use a GPS unit with a Propeller.
You might want to keep in mind these Mecanum wheels aren't as efficient as normal wheels. They're also not going to perform as well off-road as a lot of other wheels or the original treads of the Rover 5. Mecanum wheels are great for moving sideways etc., but you trade maneuverability for efficiency, speed and power. You'll use more power traveling with Mecanum wheels than traveling with normal wheels.
These Mecanum wheels might not be efficient, but they sure are cool to watch.
So depending on the goals of your robot, a different set of motors and/or wheels might be a better choice.
mikea asked about using a RC receiver to control PWM to a motor. This code does that. It uses Jason Dorie's object to read six RC channels and PWM code from the OBEX (I think by Kye) to control the motors. The PWM code can only control two motors so I use two instances of the object.
The four sets of quadrature encoders are read with one code using code based on one of JonnyMac's Spin Zone articles.
I'm currently making a major modification to this robot. Instead of a RC transmitter and receiver as a remote, I'm going to use a pair of Nordic nRF24L01+ modules. This will let the remote receive information back from the robot.
Edit(3/11/15): I have deleted the archive VexMecanumPid120301h - Archive [Date 2012.03.03 Time 21.29].zip (151 views)
I plan to upload this program or an improved version to my GitHub account.
If there isn't a replacement on GitHub send me a message and I'll make sure to upload the replacement code.
Thanks much for posting the Mecanum direction code, as I was very interested to see an implementation for the angle/speed calculations for each wheel, to accomplish a desired overall motion direction.
In your video you mentioned having the best success with moving in exact multiples of 45 degrees in your heading. Is that still the case? I'm guessing that this is either just a basic result of having 4 wheels, or due to the shape of the wheels themselves. Does anyone have any info on whether real arbitrary (non-multiples-of-45 degrees) direction motion should be straightforward to accomplish?
I should ask, are you still using the motors that came with the Rover 5, or should I replace them when I attach the Mecanum wheels?
Thanks much for blazing such a clear trail. Now I have to go shopping, and start inching along the path you've cleared so well.
I'll start a new thread for my robot once I have it at least moving.
=Cliff
I fiixed this problem. It was a bug in the code where I didn't take into account the rounding error the integer math causes. After fixing this bug, I had the robot moving in any arbatrary direction. I don't think I made a video of the improved driving ability before I started modifying the robot to use a different remote. I still haven't finished my "new and improved" robot remote since I caught a severe case of "quadcopter fever" and I haven't been working on my ground based robots lately.
I'll look through the code I posted to make sure it includes the 45 degree only bug fix. The code I previously posted has the bug. I'll post a version with the bug fix soon.
I used the stock motors with the Rover 5. If you're thinking of using different motors, I'd suggest skipping the Rover 5 all together and just make a custom chassis to hold the more powerful motors. With powerful motors, the encoders aren't as necessary. With the relative weak motors of the Rover 5, the encoders are needed for slow speed navigation.
If you don't already have a Rover 5 chassis, you might want to think about getting more powerful motors. Another forum member as a robot with these Vex Mecanum wheels which uses more powerful motors and his robot really moves well. More powerful motors will likely cost a lot more than using the Rover 5 though.
As I mentioned earlier in the thread, mounting the Vex wheels to the Rover 5's motors was a challenge.
I'm not convinced the L298N motor control chips are the best option for driving the Rover 5 motors. Gordon McComb suggested there are multiple motor drivers that should work better than the L298 chips at the voltage I'm using . I have several different H-bridge chips I've been meaning to try out. I haven't had time to try out which of these H-bridges will work well with the Rover 5 motors.
I look forward to seeing your robot.
Interesting to hear you say that now, I wondered how necessary they were. As you say, everything's better with mo' power and money.
Oh, you didn't say money. Ah well, I still stand by it, Captain Quadrotor!
I still think the encoders are very necessary in order to use Vex Mecanum wheels with the Rover 5 chassis, but after seeing Rich's powerful Mecanum wheeled robot, I had the impression the power of the motors allowed the wheels to spin a a predictable rate even at low speed settings.
I think the encoders might still be necessary for autonomous navigation with the Mecanum wheels even with powerful motors.
I'm pretty sure the four motors Rich is using cost much more than what the Rover 5 chassis costs. Still, if I were to start from scratch and wanted to build a Mecanum wheeled robot, I'd be very tempted to spring for the more powerful motors and mount them to some sort of homemade chassis. Not only would this approach require more money, I think it would also require more time.
I'm still very pleased with how well the Rover 5 moves with these encoder enhanced Mecanum wheels.
Thanks, I'll look forward to seeing the diffs between your new and currently-posted code.
The Rover 5 (w/Vex wheels) looks too cool to resist, so I'll work on getting that going first.
I bought a Romeo MCU, and I/O Shield, which may turn out to have too few Digital Inputs to monitor all of the Rover 5's Motor Encoders:
https://www.jameco.com/webapp/wcs/stores/servlet/ProductDisplay?storeId=10001&productId=2144403&catalogId=100&langId=-1&ddkey=https:CookieLogon
https://www.jameco.com/webapp/wcs/stores/servlet/Product_10001_100_2159242_-1
I also bought a SD Memory Card Holder, to hold my mapping data I acquire while roving around the house:
https://www.jameco.com/webapp/wcs/stores/servlet/ProductDisplay?storeId=10001&productId=2167744&catalogId=100&langId=-1&ddkey=https:CookieLogon
To cover the possibility of running out of Digital Inputs, I also bought a Spider MCU. Alas, it won't arrive until early Nov.:
http://www.robotshop.com/dagu-spider-robot-controller-2.html
I also bought a DAGU 4-motor controller to drive the wheels:
http://www.jameco.com/webapp/wcs/stores/servlet/Product_10001_10001_2150539_-1
Lastly I have a very accurate compass (3-axis Magnetometer) that I'll use to maintain my desired heading along with the encoders:
http://www.pololu.com/catalog/product/1273
It has given me a heading indication that's repeatable within +/- 2-3 degrees, and is independent of tilt, i.e., going up-/down-slope.
My mapping data I'll gather with various sonar sensors, measured starting from some corner of the room. They're accurate to 1/4"-1/2" over 10+', so I hope to be able to gather pretty accurate maps of the rooms in my home.
My Rover 5 should arrive by next weekend, so I'll post a photo as soon as I get the boards attached to it, and will start drilling the wheels as you demonstrated as soon as they arrive.
More news next weekend,
=Cliff
I don't have an updated version of the program (at least I couldn't find one) with the bug fix and using a RC type TX and RX.
Since posting the buggy code above, I changed the code to use a second Propeller board acting as the "remote" transmitter. The "remote" Prop was connected to both a PlayStation 2 controller and a Nordic nRF24L01+ (similar to the setup a described at the beginning of this thread).
I just now went through and made changes to "VexMecanumPid120301h" in order to fix the integer math bug. Unfortunately, my Rover 5 isn't setup to use with a RC system right now so I can't test the version I'm attaching here. The Propeller board currently attached to my Rover 5 also has different pins connected to the RC receiver, encoders and motors. I'll need to modify this code yet again in order to test it with my current setup (after connecting a RC receiver to the board instead of the Nordic transceiver).
I didn't see a Propeller board mentioned in your list of items you've purchased. The attached code will only run on a Propeller microcontroller.
While it should be possible to write AVR versions of the algorithms used in this program, I strongly doubt the ATmega 328 (or the ATmega 1280 on the Dagu Spider) will be able to perform all the tasks needed fast enough to match the functionality of the Propeller. I don't think the ATmega 328 can read in the pulse lengths of the four channels of the RC receiver and also monitor all four quadrature encoders. I'm not positive the ATmega can't meet these challenges, but I have a strong gut feeling it wouldn't be able to perform all these tasks.
The Propeller is an ideal match for this type of project since this project can greatly benefit from the Propeller's parallel capabilities. The Prop's multiple cogs allow it to monitor multiple inputs (encoders, RC receiver) and control multiple peripherals (motors), simultaneously.
I think a single Propeller Protoboard would out perform both the AVR boards you listed.
Unless you already know how to program AVR chips and have other uses for the AVR boards, you might want to concider returning the boards while they're still brand new.
Mapping rooms in your home will be a very challenging (and fun) task. With one of my robots, I kind of cheated and just had the robot memorize (record on a uSD card) the comands it sent to the motors (CR servos) so it could then replay (autonomously) the course it drove while under human control.
One inexpensive sensor to use in your mapping efforts could be a ultrasound sensor. They're cheap enough you might want to get several.
I'm curious where you purchased your Rover 5? In order to use Mecanum wheels, you want to make sure you get one with motors on all four wheels. I've seen Rover 5s for sale that only have two motors.
Do you have suitable nuts and bolts for mounting the wheels to your robot? I used metric 3mm bolts but I think 4-40 hardware (edit(10/14/12): #6 or #8 hardware would probably be a better choice) would also work for securing the wheels.
I look forward to seeing your robot up and running.
Edit(3/11/15): I have deleted the archive VexMecanumPid120301h121007a - Archive [Date 2012.10.07 Time 01.27].zip (67 views)
I plan to upload this program or an improved version to my GitHub account.
If there isn't a replacement on GitHub send me a message and I'll make sure to upload the replacement code.
Thanks much for the code update. I look forward to applying it soon.
As you wrote, I want to try this with an Arduino-compatible board first. I e-mailed back and forth with Russell, the Rover 5 Designer(?), and he opened my eyes to the fact that I need an MCU with more pins than the Romeo I bought can bring to the table.
Specifically, as many people have written, to implement the Rover 5 fully, we need our MCU to have 4 External Interrupt input pins, plus 8 more to supply PWM and Direction outputs to the motors. And I need two more pins for TX and RX for the XBee to talk with my laptop.
With that in mind, today I ordered an "Arduino Mega 2560 R3"+XBee/SD Card shield, as it should have more than enough pins to implement the Rover 5.
Interestingly, I also looked in detail at the Spider MCU's Instruction Manual. I was surprised to read where it points out that driving Servos consumes more pins than one might imagine (i.e., for Timers, as well as for the Servo signals themselves), such that the majority of the PWM-capable pins become unavailable :-(.
I'll switch to using the "Arduino Mega 2560 R3" once it arrives.
My nephews gave me a Propeller evaluation board for last Christmas, so I can switch to that if need be. I'll give them the Romeo and its IO Shield for Christmas this year :-).
I bought my Rover 5 from Sparkfun. I haven't had time to take it apart yet, but the box says it has "4 motors and 4 encoders". They sell several flavors of it.
I'll study your very helpful photos and text on mounting the wheels, then go to a nearby surplus store to buy some long, thin (#4, etc.) bolts and nuts to make the setscrews as you did. I'll cut off the heads and slot them with a Dremel tool, to make the bolts into setscrews.
Once I get the wheels mounted, I've got to port your code to the Ardunio environment.
I.e.,I need to read up on how to use the Interrupt Service Routine code that other posters have described, to keep track of how many rotations my wheels are turning, and implement the Mecanum angle-calculating code, so lots to figure out there before my robot is moving in any organized fashion.
More news as it develops, hopefully by the end of this week,
=Cliff
I'm afraid this will likely be a major challenge. It's not just a matter of translating Spin to C. The Propeller has eight different processors and the program is run in parallel on these different processors (cogs). Two cogs control the PWM to the motors, one cog watches the RC receiver input, one cog monitors the quadrature encoders, there's also a communication cog with a software UART. A master cog monitors all the other activity and issues appropriate commands.
With all the various cogs working on their own problems, there isn't a need for interrupts.
I'm extremely skeptical any Arduino can do all this.
I've got it assembled (see attached), and am pondering optimal board arrangement, to see if I can minimize the rats-nest aspect of the wiring going to-and-fro between the Arduino Mega 2560 R3 and the Dagu 4-Motor Controller board.
I'll post again once I get it wired up to report if I at least got it moving. The Motor Controller Board worked fine with the Romeo (and some other motors I had laying around), so I know that at least that much is working. Now to test it with the Mega and the Rover 5's motors.
*EDIT:
I found the Motor Encoder Lead Color Code in the Rover 5 doc:
RED is +5V for the encoder
BLACK is 0V (ground)
WHITE is signal A
YELLOW is signal B
https://docs.google.com/file/d/0B__O096vyVYqNzE3OWYyMTctZmFkMC00YjY1LTg0Y2ItNWUwMjQwZWZmMGI1/edit?hl=en_US&pli=1
*EDIT2:
Oddbot's comment about the Rover 5's Motor Power Leads being opposite what's silkscreened on the Dagu 4-Motor Controller board is here:
> It seems that the connectors on the rover are not wired to be connected
> to the dagu controller...
No, just a case of an uneducated Chinese laborer accidentally soldering
the wires back to front. It only takes a minute to unclip the wires from the
socket and swap them over.
http://letsmakerobots.com/node/30878#comment-79106
Lastly, I have to say my heartfelt thanks to you, for all your VEX-wheel-setscrew-adding detailed postings, especially the taping up the wheels near the drill. My tape got chewed, rather than my wheels, which is very good.
I carefully followed in your footsteps, and the results turned out at least ok.
Evaluating beyond that will come once I have can implement some Arduino Mecanum + Interrupt / Encoder code (which I have yet to find any detailed postings on) and see how accurately I can control the robot's direction.
As for my VEX wheel setscrew construction, I used my Dremel drillpress, lots of clamps, and a #50 drill to make pilot holes, then drilled them out with a hand drill and a #21 drill. I drilled out the axle holes with the #21 drill as well.
This was for using #8x1-1/4" pan-head screws. To make the wheels more stable, I wanted the biggest contact area I could get pressing on the driveshafts, so I went with #8 screws rather than #4 ones.
Using my Dremel tool, I cut the heads off of them, then notched their tops, to make them into setscrews. I ground the #8 nuts into triangles, to make them fit in the tiny space between the VEX wheels' spokes.
I used the Dremel "waffle wheel" for grinding and heavy cutting, and the thin "cutting disk" for cutting and notching the screws, because it's much thinner than the "waffle wheel", so the former is best for making thin notches, i.e., to make a screwdriver slot.
Lastly^2, I found that using a hammer and center-punch on the driveshaft, while supporting the original Rover 5 wheel on the edge of a table, allows one to remove the original wheels without pulling the driveshaft out of the motor's gear assembly (which is a colossal pain to put back).
More news next week,
=Cliff
Wow, very cool. It was really strange to see a Vex Mecanum wheeled Rover 5 that wasn't mine. My brain kept telling me "Hey, that's a picture of my robot" but I had to keep telling my brain it was wrong.
The answer here is "it depends." As far as the board's "interrupt output" logic is concerned, it doesn't matter which wire is connected to which connector. Either way the wires are connected the output from the "interrupt" line will be the same.
If you're using the "interrupt output" from the motor control board instead of having Mega reading the quadrature encoders directly, it wont matter how the encoders are connected.
If you are going to read the quadrature encoders directly with the Mega, then the order will matter. The order will depend on what the software expects to see from the encoders based on the direction of the motor's rotation. I describe what I saw with my encoders in post #2 of this thread. I'm not positive all the encoders worked the same. If the encoders are connected backwards the software will usually cause the motors to spin at full speed no matter the input since the program will interpret the encoder signals as the motor not spinning fast enough in the desired direction (since it will appear to be spinning backwards). The program will keep trying to increase the speed of the motor which will have the result of the motor spinning at full speed.
If the motors spin at full speed when using a program that reads the quadrature encoders directly, you'll need to switch the order of the encoders. You can switch the order of the encoders either as they plug into the motor board or you could switch the order of the wires (from motor contoller board to Mega board) where they connect to the Mega, or you could also just change the pin assignments within the program.
It's always a good idea to test out each part of the robot as you're building and programming it. I had my program output to a terminal window the encoder values and then manually turned the wheels to check to see which direction produced positive distance measured. I also tested which way the motors turned when given forward and reverse commands.
You wont need to worry about the order of the encoder wires if your program is just using the "interrupt output" line and not monitoring the encoders itself.
The "interrupt output" lines wont tell the Mega which direction the motors are turning, but this often isn't a problem since the control program already knows which direction the motors are turning since the program is issuing direction commands to the motor control board.
It wont hurt the motors if they are plugged in backwards. They will just turn the opposite direction from what is expected.
If all the motors turn backwards from what is expected, then turn your control board around and make the front of the robot the back of the robot.
The connectors can be removed from the plastic housing and switched if you want to reverse the direction of a motor. It should also be possible to reverse the direction the motors turn from software.
It's great to see someone else using this method of attaching Vex Mecanum wheels to a Rover 5. It makes me very glad I took the time to document my efforts.
I realize now that #4 hardware is slightly thinner than 3mm hardware. In hindsight, I don't think it was a good recommendation. A #8 screw sounds like a good idea.
This sounds like a really good idea. I'm sure your #8 screws were easier to slot than trying to cut a slot in 3mm screws. If I add set screws to any more Vex Mecanum wheels, I'll probably use your method.
I've read in SparkFun's comments section of the Rover 5 that other people have had problems with pulling the drive axle out of the gear assembly. I myself haven't had this problem. All of my wheels have easily pulled off without taking the axles with them.
What do you plan to use as a remote? Are you going to use RC gear? Of course a real robot doesn't need a remote since it should be able to find its own way around, but even an autonomous robot would likely need some sort of input device.
In forward movement, there is no loss of speed with Mecanums. There is less traction then a comparable standard wheel, however due to the roller design it can in some cases provide more climbing power than a smooth rubber wheel. I have found the Mecanums to perform much better than expected off road but I would not put it up against a purpose built off road vehicle. Here is a video showing how it can climb onto a Roomba. http://www.youtube.com/watch?v=tCQJNTj4Zmg
Power (as in pulling or pushing power) is not reduced by using Mecanums. The limiting factor for my Mecanum robot as far as pulling or pushing goes is either the motors or the surface the wheels are on. On a non slippery surface the motors will stall before the wheels slip.
Rich, I'll take your word for it and as I think back at watching these robots, you're right, they do move at the same speed the wheels are turning (going forward or backward).
Yes, I've seen your robot abusing the poor Roomba. Doesn't your robot have to be registered on some national robot offender registry or something?
This is very good to know. Thanks for setting me and the record straight about Mecanum wheels.
Edit: I think one of my reasons for thinking Mecanum wheels were inefficient was because of this post on SparkFun's Mecanum wheel product page. About half way down the comments is a post by JWRM22 which in part says:
I'll start a new post to document the details of my plans, and my update progress in implementing them (I'll post a link to it here once it's up). In brief, let's see if I can hit the highlights here:
1. Switchable between autonomous and remote control from my laptop, via XBee.
2. App#1 is to map out the room (including furniture), and display the map in a Java program running in my laptop, that I've already partially written.
3. Autonomous exploration is via a steerable front-looking Sonar mounted on a servo, and IR transceivers on the sides to detect imminent tangential side-collisions. The sonar is accurate to 1" in 10'.
4. Navigation is via a 3-Axis Magnetometer (which I already have working to +/- 2 degrees), combined with "following walls" by turning the Sonar (via its servo) towards the nearest wall, to maintain a constant distance running parallel to the wall, and periodically checking the distance to the upcoming perpendicular wall. I'll thus proceed to pick a coordinate system for the room, to determine its dimensions, and to maintain a desired path across it.
5. App#2 is to pick a point on the map, and then the robot (ultimately more than one) will hunt down balloons laying about on the floor in the room, and herd them to that spot, using 2 "Ducted Fans" from R/C electric Jet Planes. My battery at present is 2S 2.5Ah 7.4V 6C Li-Po, with the likelihood I'll change it to a higher Amp-Hour battery later on. I have to match the Fans' current/voltage with the battery (so I could upgrade the Fans and battery together), while ensuring that I don't draw too much current through the Romeo or whatever other Motor Controller I use to drive the Fans.
6. App#3 is for multiple similar robots to collaborate in sharing new map-data discoveries (i.e., the sofa), and locating and herding the balloons, sharing data via XBee Mesh networking between themselves and to the laptop.
More on all this in my separate posting as I progress.
=Cliff
http://letsmakerobots.com/node/35134
=Cliff
I keep getting:
Oh, I see. I'm guessing that it's because I still have the "Draft" checkbox checked, it's hiding it from external view.
I unchecked it, so can you see it now? I.e., even right on the front page of the website:
http://letsmakerobots.com/
BTW, I added 4 videos of my EncoderCount investigations, with additions to come later this week.
=Cliff
http://www.cliffolling.com/ArukuGo/
=Cliff
http://www.cliffolling.com/ArukuGo/EncoderInvestigations1/encoderCountOutputChecks.html
Hopefully by next weekend I'll have made some (visible) progress with my Encoder data plotting, so stay tuned.
=Cliff
I just stumbled upon this thread doing some research for a robot we currently built. The chassis was thrown together ourselves but we have been considering maybe building another one with the rover 5. We are having huge issues with the PID and are currently using the arduino mega. I think it is because we dont understand exactly what is happening with the PID equations as we should. We just can't get the damn thing to move straight or sideways in a slow controlled manner the wheels seem to not want to match up correctly. We have even tried writing a small type of code where we have a master wheel and the other three are trying to match the master wheel. This may be due to using continuous servos as our motors with encoders attached for feedback. Hopefully you two still look at this thread really could use some help! I might even jump over to that parallax chip as it seems very interesting with the parallel processing.
Thanks!
Please post your code as an attachment, or send it to me as a message, and I'll take a look an see if I can find any issues in it.
=Cliff
I doubt you need full blown PID. Proportional feedback is usually enough with these type of robots.
I don't see any encoders on your robot? You don't really need encoders if you're driving the robot remotely and your motors are powerful enough, but if your motors are underpowered like the Rover 5 then encoders are needed to move at slow speeds.
While the Rover 5 is reasonably priced, it has its shortcomings. I have a thread here discussing some of the pros and cons of the Rover 5.
I haven't used Vex motors myself but the ones you have on your robot, look like they're on the small side for this application. The motors may need encoders in order to be useful at slow speed.
I don't know if the Arduino Mega can read four quadrature encoders and perform the other calculations needed to control a four motor robot. Projects like this (with lots of sensors and things to control) is where the Propeller really shines.
Here's the Mecanum wheeled Rover 5 with the alternate control board in action.
There's another Mecanum wheeled Rover 5 on LetsMakeRobots.
I'm trying to figure out how to position the various PCBs and battery on the robot to keep the the robot relatively sleek. I'd really like to figure out some sort of cover for the electronics. I found having a rats nest of wires bothersome when I drove the treaded Rover 5 out in the snow. I'm also trying to figure out some sort of turret to which I plan to mount sensors.
The code is heavily commented. See post #60 the Rover 5 thread for some additional instructions on how to use the object.
I recently realized this code could easily be used to make a Propeller board a slave to another microcontroller. Since I've included a way to enter wheel speeds through a terminal window, it should be easy for another microcontroller to send motor speeds over a UART to the Propeller.
I ought to (and plan to) add a few Mecanum specific commands so a master microcontroller (Arduino or BS2) could send joystick x and y values through the UART and the Propeller would then use this information to control the Rover 5 (or other four motors with four quadrature encoders robot). I'll probably add a direction, magnitude and rotation option as an additional way of controlling the robot through a UART.
Edit(3/11/15): I have deleted the archive Demo4WDBot130226e - Archive [Date 2013.02.26 Time 23.24].zip (114 views)
I plan to upload this program or an improved version to my GitHub account.
If there isn't a replacement on GitHub send me a message and I'll make sure to upload the replacement code.
We are using the Rover 5 chassis with vex mecanum wheels
Arduino Mega
Beagle Board - Computer vision
Ultrasonics for XY positioning on a board
forgot to add
Dagu 4 channel motor controller (Question if the properller board is sending out a 3.3v pwm signal and the dagu seems to be 5v will this cause a huge issue?, btw what do you use for h bridge motor controllers)
We are not sure exactly how to implement the PID. We were looking at the arduino library PID that someone made and tried to mess with it a little. We are not sure exactly how to go about using the PID. What should our set point be? Originally we were trying to use a master wheel for our setpoint and have the other wheels try to match that. But not sure if this is the right approach. We just need to make sure the robot when it moves always stays parallel to a wallno matter if its moving or stopped.
We are going to try out the parallax board
https://www.parallax.com/Store/Microcontrollers/BASICStampModules/tabid/134/txtSearch/protoboar/List/1/ProductID/423/Default.aspx?SortField=ProductName%2cProductName
Got the one with 5v regulator so we can run some of our other servos/sensors off the board as well.
The board you linked to doesn't have a 5V regulator but I still think it's a good board. You should have 5V from your other boards you could use to power the servos or use a cheap regulator from ebay for your 5V line. (Maybe you have the Propeller Proto Board (which has a 5V regulator) and not the Project Board?)
You could use the Propeller board (either the Project Board or a QuickStart) as a slave to your other boards. As the code is now it can be controlled from a serial line by sending the motor number followed by the speed. A carriage return indicates when the end of the number has been received.
I haven't found many 5V devices that wont read 3.3V as logic high. I doubt the motor controller will have a problem with the Prop's 3.3V signal. If needed, you could use a level shifter.
I'm using a couple of $4 motor controllers I purchased off ebay myself.
I've been working on adding a compass today but I plan to add support that will allow the Prop to take care of all the trig itself. A master microcontroller would just send direction, speed and rotation information and the Propeller would compute the wheel speeds based on this information.
The parent uC could take care of sensor readings and navigation decisions while the Propeller chip kept the motors turning at the correct speeds based on the signal from the master uC.
While I think the Propeller is a great uC to learn to use with robotics, by using the Prop as a slave device you could then free the Arduino to take care of higher level stuff. This should speed up your ability to having a working robot instead of needing to learn to program the Propeller yourself. You could then learn to program the Propeller at your leisure.
Edit: I hadn't seen your last post when writing the above. I see I was preaching to the choir.
BTW, I really like your robot. Very cool.
Edit: Apparently I was suffering from temporary blindness. The board you linked to does indeed have a 5V regulator. My brain saw the Propeller Project Board.