That is exactly the same way my 6"X48" Belt sander works, just a slight crown in the drive and idler drums.
if you wanted to custom make a set. I don't see why you could not have the crown and a slot for the V drive.(or Cogs).
But I think that chassis would need a better wheel alignment system, before you can hope to keep those treads from falling off.
I think four motors would be the way to go with a track setup. more power is always good. :thumb:
-Tommy
Edit: Hey, why not try wrapping some of that Polymorph stuff around your rims.
See if you can form a semi smooth crown and V channel, I bet that might do the trick, eh?
When I saw pictures of the Rover 5 I thought the ground clearance adjustments might introduce play. So even though it was less fancy I purchased the RP5 tank chassis instead. Also the extra width of the Rover 5 wasn't what I was looking for either. So I was a bit nervous paying more for less features, but it sounds like I made the right decision.
Here's a close up view of the inside of the treads.
It doesn't look like the spikes will need to be removed after all. The barrel shaped wheels did the trick!
Here's a picture of the two I've made so far.
I also came up with a better method of keeping the gearboxes aligned than my previous attempts.
I had previously drilled holes in the gearbox housings in order to attach plastic standoffs. This time I used 2" 4-40 machine screws in the holes. I added a threaded spacer to the outside portion of the screw with an additional nut to lock it in place (not shown).
By joining the two screws in the center with a 1" threaded spacer, I was able to precisely control the space between the two gearboxes. Once I had the spacing correct (110mm), I used additional nuts to lock all the screws and spacers into their positions and reassembled the gearboxes. A pretty cool trick if I do say so myself.
I haven't taken a picture of the final assembly but you can see it in the video pretty well. Speaking of video:
BTW, I used the same parameters for speed and loop times in the above video as in this figure 8 attempt with my Mecanum wheeled Rover 5.
The right side of the robot is using the normal wheels. The right side also only has one of two motors connected to see if not driving both ends of the tread would reduce the likelihood of the treads derailing. I don't think one verses two motors per tread affects the treads ability to stay on the wheels.
Both sides did relatively well. Of the four times I ran the program, the treads on the left only came off twice (an improvement from earlier tests without aligned gearboxes but comparable to previous tests with aligned gearboxes). The right side with the barrel shaped wheels didn't have a single problem with the treads. I ran the loop (was a figure 8 with my other Rover 5) twice since both treads stayed in place through the first run of the program.
This is just so weird! The rims make it more likely the treads will come off. It was even harder to remove the treads on purpose from the barrel shaped wheels. The tread on the rimmed wheels are relatively easy to remove by just getting the tread started coming up on to the rim. One the tread is on the rim, it's easy to get it the rest of the way off by rotating the wheels while pulling sideways on the tread. The barrel shaped wheels resisted my efforts to remove the tread. It kept pulling the tread back on. It was very odd.
Thank you erco for your great idea! Very, very cool!
Now I need to make two more of these barrel shaped wheels.
Very good. As promised, belt-like treads are countertuitive.
I see just a hint of barrel shape. As with most things, more is better. An innovator like you could go even fsrther, filling in the ID of the hub with Sugru so you have more material to shave away.
In your video, why does the bot turn left (first part) fairly smoothly, but chatters a lot when turning right (last part)?
In your video, why does the bot turn left (first part) fairly smoothly, but chatters a lot when turning right (last part)?
You noticed that, huh?
I'm pretty sure it was my proportional control algorithm having a hissy fit about not having two motors in the left side. I hadn't tuned the control algorithm to compensate for the single motor so it oscillated pretty heavily particular when the left side was the side requiring fast, outside of the loop, speed. I think the problem will go away once I reinstall the gears to the back left gearbox.
Hey, if a hint of a barrel shape works, I say don't fix it.
I feel like I should be spreading the word to all the other Rover 5 owners struggling to keep their treads from coming off. This method works great.
Sure is. But those rims actually cause the problem.
If you love something, set it free...
Some horses can't be broke...
I got more.
Until you build a conveyor belt (flat rubber treads work the same way) it's hard to visualize how the shear in the belt actually helps center it up on a barrel roller, as that previous video shows, despite the wild oscillation.
Another interesting "centering" mechanism of a "flat belt" is inside every old player piano. Proper alignment of the paper roll holes to their corresponding vacuum holes is critical. A lightweight mechanical follower senses the edge of the paper and actively steers the rolls to maintain alignment. Before electronics, people were far more clever mechanically.
My 1911 player is awesome and works great. Here's someone else's video. The "sensor" is on the left edge of the paper.
I recall in my past experiences with the Rover 5 the easiest way to get the treads to come off the rollers was to make relatively tight turn. Turns with a small radius were more likely to cause a tread to come off than turning in place. The turn radius in this figure 8 is would normally peel the treads off the Rover 5 very quickly. As you can see in the video below, the treads stay put through the entire figure 8.
I don't know what was happening at the end of the figure 8. I think my control algorithm needs some tweaking.
I'd be very interested in seeing other videos of a Rover 5 making circles like these without losing a tread. All the videos I could find showed the Rover 5 making very short turns to correct direction or turning in place. I couldn't find any showing a Rover 5 making continuous rounded turns like those in this figure 8 attempt. If any of you know of a video showing a Rover 5 making these kind of turns please let me know. I'm not sure it a Rover 5 can make these kind of turns without being modified.
I'm very pleased with how well the Rover 5 is now performing.
I plan to add a radio control to allow the robot to be driven remotely. I know I'll be working on autonomous navigation soon, but I'm not sure if I'm going to pursue autonomous navigation with either of my Rover 5 robots right way. I was mainly interested in testing my four motor/ four quadrature encoder objects but erco's suggestion of barrel shaped wheels looked so promising, I couldn't stop myself from seeing if the tread problem could be solved.
For me, the jury is still out on the Rover 5 chassis. It's an awful easy and inexpensive way of getting four motors with quadrature encoders, but the drawbacks keep me from giving it an unqualified recommendation.
Here are a few pictures of the completed (so far) robot.
You may have noticed a strong similarity between the Rover 5 with treads and the Rover 5 with Mecanum wheels. (Here's the Mecanum wheeled version performing a figure 8 (same video as the one in the figure 8 thread).)
I've been using a stacked deck to hold the battery, motor controllers and QuickStart board. It's a pretty simple process to disconnect the motors and encoders and switch the deck from one robot to the other.
I do plan to make a second deck so both Rover 5s can be operational at the same time.
I'm already wired up a RC receiver to the QuickStart board, but my initial test of the software wasn't successful. I should have the RC version of these Rover 5s working soon.
Thanks again erco for setting me straight with the barrel shaped rollers. Those rim extenders I initially tried seem pretty silly now. I think the rim extenders were worth the effort for the information they provided. The only failed experiment is the one that doesn't provide data.
That's particularly nice for treads, which aren't known for repeatability. Even if your program has a hissy fit a the end, I'm curious how consistent it is if you run it several times in a row. Does it trace the same path all the time, and how about a hardwood/linoleum floor instead of carpet?
I ran the figure 8 three times on carpet. All three were about the same. I did pick the best of the three to post.
You're right about the treads behaving differently on a hard floor. With the same code still loaded in the Rover 5, I tried a figure 8 in our kitchen. It wasn't pretty; no one would be crazy enough to want to see that attempt.
This was the first of two attempts. Both attempts were very similar. I'm guessing the treads get a better grip on carpet so it makes it around the loop rather and than when it's on vinyl?
So yes, the treads behave differently on carpet than vinyl but the multiple carpet runs were very similar to each other and the multiple vinyl runs were also very similar so the treads are reasonably consistent if the surface is consistent.
. . . All I did was test my Stingray motors via a direct battery connection. A slight left hook, moving ~1.5 feet per second, using my low gear ratio motors from China. That's plenty fast. I'm more convinced than ever that the original 30:1 gearmotor are undergeared and simply too fast for this robot. IMO moving faster than 2 feet per second (indoors, navigating using sensors) is asking for a bloody nose (and a dented robots & baseboards).
I partially agree. I agree that navigating is much easier at slow speeds. I'm not so sure if I agree about the 30:1 gearmotors being a bad thing. . . if they could be used with encoders.
I've been amazed at how helpful encoders can be in getting a robot to move slowly. These Rover 5 robots wont start moving with a PWM below about 50% duty cycle. It usually takes about a 60% duty cycle before the robot starts moving and once it starts moving it moves relatively quick. It's just about impossible to get these robots to move slowly without encoder feedback. With encoders, the algorithm brings the duty cycle up to about 60% but then quickly reduces the duty cycle to around 30% in order to keep the speed low. It's a really cool thing to watch the various numbers as the control loop tries to maintain a set speed. I'm still working out a few kinks in the control algorithm but I'm already very pleased with how well it works.
I'd think the 30:1 gearmotors could also be finessed to move slowly with the proper control software. The motors would then also have the option of fast speed when desired.
I now have the Rover 5 radio controlled. There have been a couple of times when I've been having the robot driving in tight loops that a tread has started to come off. If I drive the robot in a straight line after the tread comes partially off, the tread get pulled back to the center soon after I begin driving straight. It's really kind of freaky to watch. I'll need to make yet another video to show how this works. It's very cool.
Very cool, glad to see you got this chassis working right with all 4 motors and treads, Im still not sure what I think about having to mod a new chassis to get it to work right though! Im unclear did you make those barrel wheels by just cutting the lips off the stock r5 rollers? I have a cheap tread set with rollers shaped the same way as the ones on your r5, the tread slip off as soon as it touches the ground..
First, thank you for all of your posts. I have a few questions and comments. But first a little background on my project(s). I am trying to make an autonomous wheelchair, and I bought a couple of Rovers to test out control logic and sensor integration on a package that won't destroy my living room. This is a very long term project:) I originally started out with a Dagu 4 motor controller... destroyed it. Bought another... destroyed that one and then gave up on the Rover and moved on to the actual wheelchair design. Your posts have given me new resolve to try again.
You have probably already answered these questions, but looking through everything... and there is a lot to look through:)... I can't seem to find the answers.
Are you modifying the board in any way? How exactly do you hook up to your Propeller. Do you start everything... power to motors, power to boards... at the same time?
About PWM... PWM just produces a voltage equivalent. Since this is intended to be a 5V equivalent... doesn't that mean that you are going to be missing the high end of power with a 3.3V PWM signal... since at most you are going to get 3.3V and not 5V?
IF so.... would this be useful: https://www.sparkfun.com/products/8745
To increase control at the slow end... have you tried PWM signals at or under 1Khz? On my wheelchair I am getting good results with such a pulse width and I can get 10 bit resolution on my PWM, but I also have to have current limiting and a about a 1uF capacitor between my prop and board(sabertoot).
@rjo, you've brought up several issues which must be understood before you move on to PWM. If you've destroyed a couple of Dagu 4 boards do not move on until you understand why. I recommend you study the datasheet for your motor driver board before you apply power to it. One of your problems may be how you power your devices, not when.
If you still have your boards can you post a picture of how you connected everything?
Im still not sure what I think about having to mod a new chassis to get it to work right though!
Agreed. I think the Rover 5 is damaged as it sits in its box waiting to be shipped. The Rover 5 arrives with the gearboxes in thier most extended position which would be fine if the treads hadn't been installed. As it is now, the treads end up warping the Rover 5 to the point of their being a noticable "bow" to each side which increases the problems with the treads.
I'm still not ready to completely endorse the Rover 5 as a good robot chassis, but I do like them much more lately than I had previously liked them.
Im unclear did you make those barrel wheels by just cutting the lips off the stock r5 rollers?
I used a belt sander to remove the bulk of the rims. On a couple of the wheels, I used a Dremel cutting wheel to cut off a couple of pieces of the white plastic. I wanted to have a few scraps in case I need it for repairs. I cleaned up the edges with a Dremal sanding wheel and tried to give the wheels a bit of a barrel shape. I think the pictures in post #34 shows the shape I ended up with pretty well.
I have a cheap tread set with rollers shaped the same way as the ones on your r5, the tread slip off as soon as it touches the ground.
To be honest, I'm still amazed these treads work as well as they do. As I previously mentioned, I can get the treads to start to come off, but if I just straighten out my driving, the treads pull themselves back on. It's kind of eerie.
I should have a second set of treads somewhere. When I find them, I'll likely try removing the internal spikes. I'll probably modify the other set of wheels to an even more extremely rounded shape to see if it makes a difference in how well the treads stay on.
I glad you liked them. I always feel like I was more productive with my time if, in hindsight, I can see my efforts were useful to more than just myself.
I have a few questions and comments. But first a little background on my project(s). I am trying to make an autonomous wheelchair, and I bought a couple of Rovers to test out control logic and sensor integration on a package that won't destroy my living room. This is a very long term project:) I originally started out with a Dagu 4 motor controller... destroyed it. Bought another... destroyed that one and then gave up on the Rover and moved on to the actual wheelchair design. Your posts have given me new resolve to try again.
I'm glad sorry to hear I'm not the only one who has those kinds of projects. Hopefully I can explain what I did (that worked) well enough for you and others to reproduce the results. (BTW, don't add extended rims.)
You have probably already answered these questions, but looking through everything... and there is a lot to look through:)... I can't seem to find the answers.
Yes. Those are they. I purchased four of those controllers. What's nice is they have an on board 5V regulator. I run the QuickStart from the 5V regulator from one of the controllers. I'm powering the robot with the same battery packs I use in my ELEV-8. These are 3 cell LiPos which output about 12V when charged. I try not to run the motors at full power since I believe the motors are rated for around 7.2V.
Are you modifying the board in any way? How exactly do you hook up to your Propeller. Do you start everything... power to motors, power to boards... at the same time?
I plan to provide step by step instructions for setting up a four motor/ four encoder robot when I post my updated software. I'll go over this a bit now.
The only modification to the ebay L298N boards I made was to remove the jumper between the two 5V headers and the two enable headers.
I used m/f jumper wires to connect the QuickStart (QS) to the motor controllers. I'm not sure if series resistors are needed between the QS and the motor controllers, but I've found voltage levels to be higher than 3.3V on some h-bridge "IN" pins so I used 10K ohm resistors between the QS and motor controllers. Since I planned to add resistors to the m/f jumper wires, I decided to shorten some of the jumper wires in an attempt to reduce the height of the rats nest of wires above the robot. I used three pieces of clear heat shrink per jumper wire. Two pieces to cover the wire end/resistor leads joint and a single larger piece to cover the resistor itself. With the clear heat shrink I can still read the color lines on the resistor (thank you NASA for the idea of clear heat shrink tubing).
Each motor controller PCB had six connections to the QS. A total of 12 I/O pins are used to control the four motors. I think this total could be reduced to 8 by using inverters in the "In" lines. The In lines are only used to control the direction. The speed is controlled by pulsing the enable pin for each motor. Erco showed in one of the L298N threads that pulsing the enable pin gave better results than pulsing one of the "In" pins.
The encoders are powered by the motor control 5V pins (the ones previously jumpered (or is it "jumped") to the enable pins). I use more resistor enhanced jumper wires to connect the encoder outputs to QS. My encoder software requires each encoder pair be plugged into two consecutive I/O pins. The eight pins don't all have to be grouped together, be each pair does. The order each pair is connected isn't important; if encoder pins are reversed, they can be fixed by setting a few constants in the robot's header file.
The motor pins don't need to be consecutive at all. You also don't need to worry about the direction the motors turn when connecting the wires. The direction the motor turns will be adjusted with more constants in the header file.
When I'm running the robot connected to the PC with a USB cable, I don't connect the QS to the motor controller's 5V line. If I plan to use the motors while connected to the PC, I do connect a ground line between the QS and the motor control boards.
When not connected to the PC, I power the QS from one (and only one) of the motor controller 5V outputs (I use the screw terminal connection since the header pins are taken by the encoders).
I have the negative of my battery (3 cell LiPo) connected to the grounds of both motor controllers, the QS, and all four encoder grounds. The positive wire from the battery is connected to a switch to make it easier to turn the robot on and off. The other side of the switch branches into two wires, one for each motor control board. The switch sends power to the two control boards which in turn powers the encoders and one motor control board powers the QS. (I'll try to make a schematic to include in the Spin file).
So just one swtch powers up the whole system.
I currently have the software automatically start a figure 8 unless input is received from the terminal window or if the landing gear switch is moved on the RC transmitter.
I'll try to get a couple of features added to the software to make it easier to set encoder pin and motor pin directions and post these changes later today. There will still be lots of problems with the software, but it hopefully will be useable.
About PWM... PWM just produces a voltage equivalent. Since this is intended to be a 5V equivalent... doesn't that mean that you are going to be missing the high end of power with a 3.3V PWM signal... since at most you are going to get 3.3V and not 5V?
I think the PWM produces the voltage equivalent on the output side of the motor controller. My understanding is the inductors in the motor resist change in current, so the pulsed voltage get smoothed out by the motor. I think the motor controller chip itself just sees ons and offs, not an average voltage. (Please, someone correct me if I'm wrong.)
I've heard Phil many times say that these semiconducting switches shouldn't be held in the "linear" zone, but should be either all on or all off. Apparently 3.3V is enough to turn on these L298N controllers, I'm not sure if it's enough to turn them "all on" or not, but it seems to be working as it is.
To increase control at the slow end... have you tried PWM signals at or under 1Khz?
I have several of those SparkFun level shifters. I haven't tried them with these motor controllers. I may hook up some measuring equipment to see if using a level shifter matters helps or not. My "gut" feeling is it wouldn't make much difference (but what does my gut know?).
I think I'm running the PWM at about 20KHz. I tried lowering the frequency but then their was an audible whine which was very annoying to me and I know my wife well enough to know it wouldn't be a good idea to run the robot when she's at home with the robot running at lower PWM frequencies.
I don't know if I've tried it at 1KHz or not. I may give it a try while my wife isn't home to see if there's a noticeable difference.
If you get your Rover 5 running, I hope you share it with the rest of us.
Thanks. I don't have any pictures and I disassembled it.
The first puff of smoke was a mystery until I read somewhere on the web that with that particular board, if you supplied power to the motors before power to the logic... it was not good... There were several cases I came across, where this apparently destroyed the board.
The second time, being aware of this, as nearly as I can figure... I didn't do anything wrong. The board seemed to be dead on arrival. I'm not the complaining type, I got it from a vendor I like, and I couldn't be positively sure that I didn't do something wrong in my sleepless state. So, I just moved on to the sabertooth board and my 24v wheelchair motors. No problems.
I think I understand what a PWM signal is and how to program it on a Prop... but I'm not expert. My characterization of it as merely a way to create an analog voltage came from the forum. Up til I read that on the forum, I always thought that the signal had to be decoded in some way before being used on the other side of the control circuit. I suspect that there are examples of both but I haven't seen them and my reading on the forums here hasn't suggested it.
My comments to Duane about PWM derive from my experience with the Sabertooth, which uses a 0-5V analog signal to control the motor output. On the sabertooth the same switch settings are used for PWM and potentiometer control. In that context, the Prop can doesn't fully control the input port of the Sabertooth without either using a logic level translator... as from Sparkfun above... or by changing the sensitivity of the control port by changing switch settings. When you do change the sensitivity, you end up with a control range of 1.25v with a center point at 2.5v. As Duane has said... as you increase your PWM frequency, you decrease your control resolution.
I'm open for education. This stuff is important to me, and I don't know enough to keep me out of trouble yet.
Wow... thank you so much.
I already ordered the controllers... glad I got the right ones. I will post pictures. But I'm thinking I will go all normal tires... that's what my other project will be using.
One interesting divot is that on the wheelchair project, I have been stockpiling wheelchairs... and so far, no two have the exact same motors. It will be a 4 wheel drive system...with
two different kinds of motors... I little hard to emulate on my Rover platform and something for you guys to think about:)
I think I understand what a PWM signal is and how to program it on a Prop... but I'm not expert. My characterization of it as merely a way to create an analog voltage came from the forum. Up til I read that on the forum, I always thought that the signal had to be decoded in some way before being used on the other side of the control circuit. I suspect that there are examples of both but I haven't seen them and my reading on the forums here hasn't suggested it.
Part of the confusion for me, when first learning about this stuff, was the loose way PWM is used. The pulses sent to control a servo or hobby ESC are often referred to as PWM signals. So in the servo example the pulse does need to be decoded, but with "normal" h-bridge circuit, the pulse just gets amplified.
One problem with using a Prop with a h-bridge circuit is many h-bridge chips expect 5V signals to turn the chips on and off. Many chips work with a 3.3V logic signal but not all. My experience so far suggests the L298N works with 3.3V logic.
I also understand that some chips of a limited PWM frequency before the fast switching times will cause a problem. I think the main concern here is for the motor control circuit and not necessarily for the microcontoller. With the L298N PCB being so cheap, I'm not really worried about this.
I also understand that some chips of a limited PWM frequency before the fast switching times will cause a problem. I think the main concern here is for the motor control circuit and not necessarily for the microcontoller. With the L298N PCB being so cheap, I'm not really worried about this.
I still don't get why 99% of motor controllers use PWM frequencies in the kilohertz range. All they do at low power is squeal, without delivering any usable power. That's no better than a resistor or a few diodes to drop voltage. I learned from the low gutsy growl of my HERO 2000 robot that you can have stump-pulling torque down to very low speeds if your PWM frequency is VERY low, like 10-20 Hz. My own L298 tests confirm this. Works great...
These Rover 5 robots wont start moving with a PWM below about 50% duty cycle. It usually takes about a 60% duty cycle before the robot starts moving and once it starts moving it moves relatively quick. It's just about impossible to get these robots to move slowly without encoder feedback.
That's more of an indictment of the speed controller PWM frequency being too high IMO. Bit bang 10-20 Hz PWM to your motors through your $4 L298s and you'll see what I mean.
There have been a couple of times when I've been having the robot driving in tight loops that a tread has started to come off. If I drive the robot in a straight line after the tread comes partially off, the tread get pulled back to the center soon after I begin driving straight. It's really kind of freaky to watch. I'll need to make yet another video to show how this works. It's very cool.
That's more of an indictment of the barrel rollers and how they need more curvature IMO.
PS: You never replied about taking our twins for a week since you have all this free time on your hands. Next week OK?
That's more of an indictment of the speed controller PWM frequency being too high IMO. Bit bang 10-20 Hz PWM to your motors through your $4 L298s and you'll see what I mean.
At 50Hz the wheels move at about 10% duty cycle. I hardly even need my super duper propotional feedback code now.
That's more of an indictment of the barrel rollers and how they need more curvature IMO.
Okay, once I find my other set of treads, I'm going to cut off the little spikes on the inside and make another set of rounded rollers. This time the rounding will be more extreme.
PS: You never replied about taking our twins for a week since you have all this free time on your hands. Next week OK?
Next week is great. They know how to use a soldering iron right? I have a much headers that need to be soldered to a bunch of PCBs, it would be great to have some help.
BTW, it may look like I'm working on multiple projects at once, but this is really the same four motor / four encoder project. The Mecanum wheeled Rover 5 and the treaded version even share the same controller board.
I'm hoping to get some video of this robot outside in the snow today.
Well it was fun to imagine the treaded Rover 5 cruising over the snow banks outside our house but the reality was a little less dramatic. The Rover 5 managed to get through the snow without too much trouble (as long as the snow wasn't deep).
I thought it was kind of fun.
Our camera does not play nice with audio. Everytime the zoom lever was moved it produced an audible "click". I'm on the lookout for a better camera.
I managed to get the treads to come off on my first attempt in the snow. Warning, the audio is even worse in this one.
You better rush if you want to beat me to it, it's 70 degrees here in LA!
I'll wait to do a figure 8 in the snow until later in the week so I can have the "8" drawn around your twins. They could each be making a snow angel while the robot drives around them.
I thought getting a treaded vehicle to make consistent loops on carpet was hard, I think trying to get a consistent loop in snow will be next to impossible.
Maybe I could cheat and use the switch on my radio to tell the robot when it has reached the center of the "8" and it's time to switch directions.
I've decided I don't mind (much) a rats nest of wires on an indoor robot but I don't like have a bunch of wires hanging out on an outside bot (particularly one driving in the snow). I'll need to figure out a way of making a cover this robot.
BTW, your twins would love it at our house. We've got a great Duplo collection and our Lego collection is probably the largest in South East Idaho. Just tell your twins you're sending them to Legoland Idaho.
I've added some four motor driver code to post #4. There are two versions of the code; one version has the motor control pins of two motors set to "-1" to allow it to be used with two motor robots.
I'm still cleaning up my four motor with encoder feedback code. I should be posting the code with proportional feedback (and other cool stuff) soon.
I code that lets the Rover 5 be controlled by a Wii Nunchuck.
I'm attaching the code for the treaded Rover 5 along with the header file I use with my Mecanum Rover 5.
There are a few restrictions on how the pins can be used. If a RC receiver is used, it needs to have six channels and all six channels need to be connected to six sequential I/O pins. I mainly did it this way out of laziness /s] for time management reasons. It wouldn't be hard to change the code to use a four channel radio connected to any four I/O pins (they wouldn't even need to be sequential). If anyone needs this modification let me know. It kind of bugs me that I left the code as it is now. Now that I think about it, I think fewer than six channels may be used. See the "BotCommand" object for the channel names. The channels "THROTTLE", "X", "Y", "ROTATION", and "GEAR" are used by the program.
I added a bunch of comments to the beginning of the top object with additional comments in the header files. All but the Nunchuck pin settings are done in the header file (the Nunchuck uses the Prop's I2C pins 28 & 29).
I've given instructions on how to set up a robot using this code. The directions of the encoders and motors need to be checked to make sure they are going the right direction.
I've left constants in the header file set for this initial setup. Once the motors and encoders are setup correctly then the various input options my be selected.
' inputType enumeration #0, PC_ONLY_INPUT, WII_NUNCHUCK_INPUT, RC_INPUT, WII_AND_RC_INPUT, AUTO_DETECT_INPUT
INPUT_TYPE = PC_ONLY_INPUT '' Use this when first setting up robot
'INPUT_TYPE = WII_NUNCHUCK_INPUT
'INPUT_TYPE = RC_INPUT
'INPUT_TYPE = WII_AND_RC_INPUT '' Not yet supported. If used it will behave the same
'' as AUTO_DETECT_INPUT.
'INPUT_TYPE = AUTO_DETECT_INPUT '' Priority given to Nunchuck
While setting up a robot, this line should be the one not commented out.
INPUT_TYPE = PC_ONLY_INPUT
This should make it easier to set the motor speeds by using the keyboard. Once the every is setup, the input type can be changed. The option "AUTO_DETECT_INPUT" will first look for a Wii Nunchuck and if one is found it will use it as the input device. If a Wii Nunchuck isn't found it assumes a RC receiver is attached and will use it for the input device.
Once the motors and encoders are setup, the wheel mode can be set to one of three options.
' wheelMode enumeration #0, INDEPENDENT_WHEELS, TREADED_WHEELS, MECANUM_WHEELS
'WHEEL_MODE = INDEPENDENT_WHEELS '' Use this when first setting up robot
WHEEL_MODE = TREADED_WHEELS '' The target speeds of each side will be matched.
'WHEEL_MODE = MECANUM_WHEELS
The only difference between "INDEPENDENT_WHEELS" and "TREADED_WHEELS" is the "TREADED_WHEELS" option will force both wheels on one side of the robot to the same speeds.
Feel free to ask questions.
I have plenty of things I still want to improve with this code but I wanted to make available in case anyone else is attempting to try to get a Rover 5 or similar robot working.
BTW, none of the constants used to drive a figure 8 are the correct values right now. I changed the run times to shorter values will testing an my original figures were all wrong after slowing down the PWM frequency.
Edit(3/11/15): Warning, the code attached is an old version. There are likely better options available.
I plan to upload this program or an improved version to my GitHub account
If there isn't code similar to what is attached here on my on GitHub, send me a message and I'll make and check for any improved versions of the code.
Comments
if you wanted to custom make a set. I don't see why you could not have the crown and a slot for the V drive.(or Cogs).
But I think that chassis would need a better wheel alignment system, before you can hope to keep those treads from falling off.
I think four motors would be the way to go with a track setup. more power is always good. :thumb:
-Tommy
Edit: Hey, why not try wrapping some of that Polymorph stuff around your rims.
See if you can form a semi smooth crown and V channel, I bet that might do the trick, eh?
It doesn't look like the spikes will need to be removed after all. The barrel shaped wheels did the trick!
Here's a picture of the two I've made so far.
I also came up with a better method of keeping the gearboxes aligned than my previous attempts.
I had previously drilled holes in the gearbox housings in order to attach plastic standoffs. This time I used 2" 4-40 machine screws in the holes. I added a threaded spacer to the outside portion of the screw with an additional nut to lock it in place (not shown).
By joining the two screws in the center with a 1" threaded spacer, I was able to precisely control the space between the two gearboxes. Once I had the spacing correct (110mm), I used additional nuts to lock all the screws and spacers into their positions and reassembled the gearboxes. A pretty cool trick if I do say so myself.
I haven't taken a picture of the final assembly but you can see it in the video pretty well. Speaking of video:
BTW, I used the same parameters for speed and loop times in the above video as in this figure 8 attempt with my Mecanum wheeled Rover 5.
The right side of the robot is using the normal wheels. The right side also only has one of two motors connected to see if not driving both ends of the tread would reduce the likelihood of the treads derailing. I don't think one verses two motors per tread affects the treads ability to stay on the wheels.
Both sides did relatively well. Of the four times I ran the program, the treads on the left only came off twice (an improvement from earlier tests without aligned gearboxes but comparable to previous tests with aligned gearboxes). The right side with the barrel shaped wheels didn't have a single problem with the treads. I ran the loop (was a figure 8 with my other Rover 5) twice since both treads stayed in place through the first run of the program.
This is just so weird! The rims make it more likely the treads will come off. It was even harder to remove the treads on purpose from the barrel shaped wheels. The tread on the rimmed wheels are relatively easy to remove by just getting the tread started coming up on to the rim. One the tread is on the rim, it's easy to get it the rest of the way off by rotating the wheels while pulling sideways on the tread. The barrel shaped wheels resisted my efforts to remove the tread. It kept pulling the tread back on. It was very odd.
Thank you erco for your great idea! Very, very cool!
Now I need to make two more of these barrel shaped wheels.
I see just a hint of barrel shape. As with most things, more is better. An innovator like you could go even fsrther, filling in the ID of the hub with Sugru so you have more material to shave away.
In your video, why does the bot turn left (first part) fairly smoothly, but chatters a lot when turning right (last part)?
You noticed that, huh?
I'm pretty sure it was my proportional control algorithm having a hissy fit about not having two motors in the left side. I hadn't tuned the control algorithm to compensate for the single motor so it oscillated pretty heavily particular when the left side was the side requiring fast, outside of the loop, speed. I think the problem will go away once I reinstall the gears to the back left gearbox.
Hey, if a hint of a barrel shape works, I say don't fix it.
I feel like I should be spreading the word to all the other Rover 5 owners struggling to keep their treads from coming off. This method works great.
Better yet, tell the manufacturer!
BTW, is "hissy fit" in the tech manual? I didn't see it in the index.
If you love something, set it free...
Some horses can't be broke...
I got more.
Until you build a conveyor belt (flat rubber treads work the same way) it's hard to visualize how the shear in the belt actually helps center it up on a barrel roller, as that previous video shows, despite the wild oscillation.
My 1911 player is awesome and works great. Here's someone else's video. The "sensor" is on the left edge of the paper.
http://www.youtube.com/watch?v=0VPv7vb2Vpg
You can also see I now have four barrel shaped wheels. I can hear it crying out to drive a figure 8.
You need some kids. You can borrow my twins for a week while I take the wifey to Cancun...
The barrel shaped wheels work great!
I recall in my past experiences with the Rover 5 the easiest way to get the treads to come off the rollers was to make relatively tight turn. Turns with a small radius were more likely to cause a tread to come off than turning in place. The turn radius in this figure 8 is would normally peel the treads off the Rover 5 very quickly. As you can see in the video below, the treads stay put through the entire figure 8.
I don't know what was happening at the end of the figure 8. I think my control algorithm needs some tweaking.
I'd be very interested in seeing other videos of a Rover 5 making circles like these without losing a tread. All the videos I could find showed the Rover 5 making very short turns to correct direction or turning in place. I couldn't find any showing a Rover 5 making continuous rounded turns like those in this figure 8 attempt. If any of you know of a video showing a Rover 5 making these kind of turns please let me know. I'm not sure it a Rover 5 can make these kind of turns without being modified.
I'm very pleased with how well the Rover 5 is now performing.
I plan to add a radio control to allow the robot to be driven remotely. I know I'll be working on autonomous navigation soon, but I'm not sure if I'm going to pursue autonomous navigation with either of my Rover 5 robots right way. I was mainly interested in testing my four motor/ four quadrature encoder objects but erco's suggestion of barrel shaped wheels looked so promising, I couldn't stop myself from seeing if the tread problem could be solved.
For me, the jury is still out on the Rover 5 chassis. It's an awful easy and inexpensive way of getting four motors with quadrature encoders, but the drawbacks keep me from giving it an unqualified recommendation.
Here are a few pictures of the completed (so far) robot.
You may have noticed a strong similarity between the Rover 5 with treads and the Rover 5 with Mecanum wheels. (Here's the Mecanum wheeled version performing a figure 8 (same video as the one in the figure 8 thread).)
I've been using a stacked deck to hold the battery, motor controllers and QuickStart board. It's a pretty simple process to disconnect the motors and encoders and switch the deck from one robot to the other.
I do plan to make a second deck so both Rover 5s can be operational at the same time.
I'm already wired up a RC receiver to the QuickStart board, but my initial test of the software wasn't successful. I should have the RC version of these Rover 5s working soon.
Thanks again erco for setting me straight with the barrel shaped rollers. Those rim extenders I initially tried seem pretty silly now. I think the rim extenders were worth the effort for the information they provided. The only failed experiment is the one that doesn't provide data.
From the figure 8 thread:
I ran the figure 8 three times on carpet. All three were about the same. I did pick the best of the three to post.
You're right about the treads behaving differently on a hard floor. With the same code still loaded in the Rover 5, I tried a figure 8 in our kitchen. It wasn't pretty; no one would be crazy enough to want to see that attempt.
Really? Okay, you asked for it.
This was the first of two attempts. Both attempts were very similar. I'm guessing the treads get a better grip on carpet so it makes it around the loop rather and than when it's on vinyl?
So yes, the treads behave differently on carpet than vinyl but the multiple carpet runs were very similar to each other and the multiple vinyl runs were also very similar so the treads are reasonably consistent if the surface is consistent.
I partially agree. I agree that navigating is much easier at slow speeds. I'm not so sure if I agree about the 30:1 gearmotors being a bad thing. . . if they could be used with encoders.
I've been amazed at how helpful encoders can be in getting a robot to move slowly. These Rover 5 robots wont start moving with a PWM below about 50% duty cycle. It usually takes about a 60% duty cycle before the robot starts moving and once it starts moving it moves relatively quick. It's just about impossible to get these robots to move slowly without encoder feedback. With encoders, the algorithm brings the duty cycle up to about 60% but then quickly reduces the duty cycle to around 30% in order to keep the speed low. It's a really cool thing to watch the various numbers as the control loop tries to maintain a set speed. I'm still working out a few kinks in the control algorithm but I'm already very pleased with how well it works.
I'd think the 30:1 gearmotors could also be finessed to move slowly with the proper control software. The motors would then also have the option of fast speed when desired.
I now have the Rover 5 radio controlled. There have been a couple of times when I've been having the robot driving in tight loops that a tread has started to come off. If I drive the robot in a straight line after the tread comes partially off, the tread get pulled back to the center soon after I begin driving straight. It's really kind of freaky to watch. I'll need to make yet another video to show how this works. It's very cool.
First, thank you for all of your posts. I have a few questions and comments. But first a little background on my project(s). I am trying to make an autonomous wheelchair, and I bought a couple of Rovers to test out control logic and sensor integration on a package that won't destroy my living room. This is a very long term project:) I originally started out with a Dagu 4 motor controller... destroyed it. Bought another... destroyed that one and then gave up on the Rover and moved on to the actual wheelchair design. Your posts have given me new resolve to try again.
You have probably already answered these questions, but looking through everything... and there is a lot to look through:)... I can't seem to find the answers.
Is this the controller you are currently using http://www.ebay.com/itm/380520063503?ssPageName=STRK:MEWNX:IT&_trksid=p3984.m1497.l2649
Are you modifying the board in any way? How exactly do you hook up to your Propeller. Do you start everything... power to motors, power to boards... at the same time?
About PWM... PWM just produces a voltage equivalent. Since this is intended to be a 5V equivalent... doesn't that mean that you are going to be missing the high end of power with a 3.3V PWM signal... since at most you are going to get 3.3V and not 5V?
IF so.... would this be useful: https://www.sparkfun.com/products/8745
To increase control at the slow end... have you tried PWM signals at or under 1Khz? On my wheelchair I am getting good results with such a pulse width and I can get 10 bit resolution on my PWM, but I also have to have current limiting and a about a 1uF capacitor between my prop and board(sabertoot).
Thanks,
Rich
If you still have your boards can you post a picture of how you connected everything?
Agreed. I think the Rover 5 is damaged as it sits in its box waiting to be shipped. The Rover 5 arrives with the gearboxes in thier most extended position which would be fine if the treads hadn't been installed. As it is now, the treads end up warping the Rover 5 to the point of their being a noticable "bow" to each side which increases the problems with the treads.
I'm still not ready to completely endorse the Rover 5 as a good robot chassis, but I do like them much more lately than I had previously liked them.
I used a belt sander to remove the bulk of the rims. On a couple of the wheels, I used a Dremel cutting wheel to cut off a couple of pieces of the white plastic. I wanted to have a few scraps in case I need it for repairs. I cleaned up the edges with a Dremal sanding wheel and tried to give the wheels a bit of a barrel shape. I think the pictures in post #34 shows the shape I ended up with pretty well.
To be honest, I'm still amazed these treads work as well as they do. As I previously mentioned, I can get the treads to start to come off, but if I just straighten out my driving, the treads pull themselves back on. It's kind of eerie.
I should have a second set of treads somewhere. When I find them, I'll likely try removing the internal spikes. I'll probably modify the other set of wheels to an even more extremely rounded shape to see if it makes a difference in how well the treads stay on.
I glad you liked them. I always feel like I was more productive with my time if, in hindsight, I can see my efforts were useful to more than just myself.
I'm glad sorry to hear I'm not the only one who has those kinds of projects. Hopefully I can explain what I did (that worked) well enough for you and others to reproduce the results. (BTW, don't add extended rims.)
No problem. Ask away.
Yes. Those are they. I purchased four of those controllers. What's nice is they have an on board 5V regulator. I run the QuickStart from the 5V regulator from one of the controllers. I'm powering the robot with the same battery packs I use in my ELEV-8. These are 3 cell LiPos which output about 12V when charged. I try not to run the motors at full power since I believe the motors are rated for around 7.2V.
I plan to provide step by step instructions for setting up a four motor/ four encoder robot when I post my updated software. I'll go over this a bit now.
The only modification to the ebay L298N boards I made was to remove the jumper between the two 5V headers and the two enable headers.
I used m/f jumper wires to connect the QuickStart (QS) to the motor controllers. I'm not sure if series resistors are needed between the QS and the motor controllers, but I've found voltage levels to be higher than 3.3V on some h-bridge "IN" pins so I used 10K ohm resistors between the QS and motor controllers. Since I planned to add resistors to the m/f jumper wires, I decided to shorten some of the jumper wires in an attempt to reduce the height of the rats nest of wires above the robot. I used three pieces of clear heat shrink per jumper wire. Two pieces to cover the wire end/resistor leads joint and a single larger piece to cover the resistor itself. With the clear heat shrink I can still read the color lines on the resistor (thank you NASA for the idea of clear heat shrink tubing).
Each motor controller PCB had six connections to the QS. A total of 12 I/O pins are used to control the four motors. I think this total could be reduced to 8 by using inverters in the "In" lines. The In lines are only used to control the direction. The speed is controlled by pulsing the enable pin for each motor. Erco showed in one of the L298N threads that pulsing the enable pin gave better results than pulsing one of the "In" pins.
The encoders are powered by the motor control 5V pins (the ones previously jumpered (or is it "jumped") to the enable pins). I use more resistor enhanced jumper wires to connect the encoder outputs to QS. My encoder software requires each encoder pair be plugged into two consecutive I/O pins. The eight pins don't all have to be grouped together, be each pair does. The order each pair is connected isn't important; if encoder pins are reversed, they can be fixed by setting a few constants in the robot's header file.
The motor pins don't need to be consecutive at all. You also don't need to worry about the direction the motors turn when connecting the wires. The direction the motor turns will be adjusted with more constants in the header file.
When I'm running the robot connected to the PC with a USB cable, I don't connect the QS to the motor controller's 5V line. If I plan to use the motors while connected to the PC, I do connect a ground line between the QS and the motor control boards.
When not connected to the PC, I power the QS from one (and only one) of the motor controller 5V outputs (I use the screw terminal connection since the header pins are taken by the encoders).
I have the negative of my battery (3 cell LiPo) connected to the grounds of both motor controllers, the QS, and all four encoder grounds. The positive wire from the battery is connected to a switch to make it easier to turn the robot on and off. The other side of the switch branches into two wires, one for each motor control board. The switch sends power to the two control boards which in turn powers the encoders and one motor control board powers the QS. (I'll try to make a schematic to include in the Spin file).
So just one swtch powers up the whole system.
I currently have the software automatically start a figure 8 unless input is received from the terminal window or if the landing gear switch is moved on the RC transmitter.
I'll try to get a couple of features added to the software to make it easier to set encoder pin and motor pin directions and post these changes later today. There will still be lots of problems with the software, but it hopefully will be useable.
I think the PWM produces the voltage equivalent on the output side of the motor controller. My understanding is the inductors in the motor resist change in current, so the pulsed voltage get smoothed out by the motor. I think the motor controller chip itself just sees ons and offs, not an average voltage. (Please, someone correct me if I'm wrong.)
I've heard Phil many times say that these semiconducting switches shouldn't be held in the "linear" zone, but should be either all on or all off. Apparently 3.3V is enough to turn on these L298N controllers, I'm not sure if it's enough to turn them "all on" or not, but it seems to be working as it is.
I have several of those SparkFun level shifters. I haven't tried them with these motor controllers. I may hook up some measuring equipment to see if using a level shifter matters helps or not. My "gut" feeling is it wouldn't make much difference (but what does my gut know?).
I think I'm running the PWM at about 20KHz. I tried lowering the frequency but then their was an audible whine which was very annoying to me and I know my wife well enough to know it wouldn't be a good idea to run the robot when she's at home with the robot running at lower PWM frequencies.
I don't know if I've tried it at 1KHz or not. I may give it a try while my wife isn't home to see if there's a noticeable difference.
If you get your Rover 5 running, I hope you share it with the rest of us.
Thanks. I don't have any pictures and I disassembled it.
The first puff of smoke was a mystery until I read somewhere on the web that with that particular board, if you supplied power to the motors before power to the logic... it was not good... There were several cases I came across, where this apparently destroyed the board.
The second time, being aware of this, as nearly as I can figure... I didn't do anything wrong. The board seemed to be dead on arrival. I'm not the complaining type, I got it from a vendor I like, and I couldn't be positively sure that I didn't do something wrong in my sleepless state. So, I just moved on to the sabertooth board and my 24v wheelchair motors. No problems.
I think I understand what a PWM signal is and how to program it on a Prop... but I'm not expert. My characterization of it as merely a way to create an analog voltage came from the forum. Up til I read that on the forum, I always thought that the signal had to be decoded in some way before being used on the other side of the control circuit. I suspect that there are examples of both but I haven't seen them and my reading on the forums here hasn't suggested it.
My comments to Duane about PWM derive from my experience with the Sabertooth, which uses a 0-5V analog signal to control the motor output. On the sabertooth the same switch settings are used for PWM and potentiometer control. In that context, the Prop can doesn't fully control the input port of the Sabertooth without either using a logic level translator... as from Sparkfun above... or by changing the sensitivity of the control port by changing switch settings. When you do change the sensitivity, you end up with a control range of 1.25v with a center point at 2.5v. As Duane has said... as you increase your PWM frequency, you decrease your control resolution.
I'm open for education. This stuff is important to me, and I don't know enough to keep me out of trouble yet.
Thanks for your advice.
Rich
Wow... thank you so much.
I already ordered the controllers... glad I got the right ones. I will post pictures. But I'm thinking I will go all normal tires... that's what my other project will be using.
One interesting divot is that on the wheelchair project, I have been stockpiling wheelchairs... and so far, no two have the exact same motors. It will be a 4 wheel drive system...with
two different kinds of motors... I little hard to emulate on my Rover platform and something for you guys to think about:)
Thanks again.
Rich
Part of the confusion for me, when first learning about this stuff, was the loose way PWM is used. The pulses sent to control a servo or hobby ESC are often referred to as PWM signals. So in the servo example the pulse does need to be decoded, but with "normal" h-bridge circuit, the pulse just gets amplified.
One problem with using a Prop with a h-bridge circuit is many h-bridge chips expect 5V signals to turn the chips on and off. Many chips work with a 3.3V logic signal but not all. My experience so far suggests the L298N works with 3.3V logic.
I also understand that some chips of a limited PWM frequency before the fast switching times will cause a problem. I think the main concern here is for the motor control circuit and not necessarily for the microcontoller. With the L298N PCB being so cheap, I'm not really worried about this.
I still don't get why 99% of motor controllers use PWM frequencies in the kilohertz range. All they do at low power is squeal, without delivering any usable power. That's no better than a resistor or a few diodes to drop voltage. I learned from the low gutsy growl of my HERO 2000 robot that you can have stump-pulling torque down to very low speeds if your PWM frequency is VERY low, like 10-20 Hz. My own L298 tests confirm this. Works great...
http://www.youtube.com/watch?v=RJDu233hO1k
I have yet to test a Picaxe's hardware PWM generator, which does a range of frequencies, but the minimum is still 61 Hz, higher than I like.
That's more of an indictment of the speed controller PWM frequency being too high IMO. Bit bang 10-20 Hz PWM to your motors through your $4 L298s and you'll see what I mean.
That's more of an indictment of the barrel rollers and how they need more curvature IMO.
PS: You never replied about taking our twins for a week since you have all this free time on your hands. Next week OK?
At 50Hz the wheels move at about 10% duty cycle. I hardly even need my super duper propotional feedback code now.
Okay, once I find my other set of treads, I'm going to cut off the little spikes on the inside and make another set of rounded rollers. This time the rounding will be more extreme.
Next week is great. They know how to use a soldering iron right? I have a much headers that need to be soldered to a bunch of PCBs, it would be great to have some help.
BTW, it may look like I'm working on multiple projects at once, but this is really the same four motor / four encoder project. The Mecanum wheeled Rover 5 and the treaded version even share the same controller board.
I'm hoping to get some video of this robot outside in the snow today.
I thought it was kind of fun.
Our camera does not play nice with audio. Everytime the zoom lever was moved it produced an audible "click". I'm on the lookout for a better camera.
I managed to get the treads to come off on my first attempt in the snow. Warning, the audio is even worse in this one.
LAY FIGURE 8 TRACKS IN FRESH SNOW!
You better rush if you want to beat me to it, it's 70 degrees here in LA!
I'll wait to do a figure 8 in the snow until later in the week so I can have the "8" drawn around your twins. They could each be making a snow angel while the robot drives around them.
I thought getting a treaded vehicle to make consistent loops on carpet was hard, I think trying to get a consistent loop in snow will be next to impossible.
Maybe I could cheat and use the switch on my radio to tell the robot when it has reached the center of the "8" and it's time to switch directions.
I've decided I don't mind (much) a rats nest of wires on an indoor robot but I don't like have a bunch of wires hanging out on an outside bot (particularly one driving in the snow). I'll need to figure out a way of making a cover this robot.
BTW, your twins would love it at our house. We've got a great Duplo collection and our Lego collection is probably the largest in South East Idaho. Just tell your twins you're sending them to Legoland Idaho.
I'm still cleaning up my four motor with encoder feedback code. I should be posting the code with proportional feedback (and other cool stuff) soon.
Cool as in snow tracks in a figure 8?
I'm attaching the code for the treaded Rover 5 along with the header file I use with my Mecanum Rover 5.
There are a few restrictions on how the pins can be used. If a RC receiver is used, it needs to have six channels and all six channels need to be connected to six sequential I/O pins. I mainly did it this way out of laziness /s] for time management reasons. It wouldn't be hard to change the code to use a four channel radio connected to any four I/O pins (they wouldn't even need to be sequential). If anyone needs this modification let me know. It kind of bugs me that I left the code as it is now. Now that I think about it, I think fewer than six channels may be used. See the "BotCommand" object for the channel names. The channels "THROTTLE", "X", "Y", "ROTATION", and "GEAR" are used by the program.
I added a bunch of comments to the beginning of the top object with additional comments in the header files. All but the Nunchuck pin settings are done in the header file (the Nunchuck uses the Prop's I2C pins 28 & 29).
I've given instructions on how to set up a robot using this code. The directions of the encoders and motors need to be checked to make sure they are going the right direction.
I've left constants in the header file set for this initial setup. Once the motors and encoders are setup correctly then the various input options my be selected.
' inputType enumeration #0, PC_ONLY_INPUT, WII_NUNCHUCK_INPUT, RC_INPUT, WII_AND_RC_INPUT, AUTO_DETECT_INPUT INPUT_TYPE = PC_ONLY_INPUT '' Use this when first setting up robot 'INPUT_TYPE = WII_NUNCHUCK_INPUT 'INPUT_TYPE = RC_INPUT 'INPUT_TYPE = WII_AND_RC_INPUT '' Not yet supported. If used it will behave the same '' as AUTO_DETECT_INPUT. 'INPUT_TYPE = AUTO_DETECT_INPUT '' Priority given to NunchuckWhile setting up a robot, this line should be the one not commented out.
This should make it easier to set the motor speeds by using the keyboard. Once the every is setup, the input type can be changed. The option "AUTO_DETECT_INPUT" will first look for a Wii Nunchuck and if one is found it will use it as the input device. If a Wii Nunchuck isn't found it assumes a RC receiver is attached and will use it for the input device.
Once the motors and encoders are setup, the wheel mode can be set to one of three options.
The only difference between "INDEPENDENT_WHEELS" and "TREADED_WHEELS" is the "TREADED_WHEELS" option will force both wheels on one side of the robot to the same speeds.
Feel free to ask questions.
I have plenty of things I still want to improve with this code but I wanted to make available in case anyone else is attempting to try to get a Rover 5 or similar robot working.
BTW, none of the constants used to drive a figure 8 are the correct values right now. I changed the run times to shorter values will testing an my original figures were all wrong after slowing down the PWM frequency.
Edit(3/11/15): Warning, the code attached is an old version. There are likely better options available.
I plan to upload this program or an improved version to my GitHub account
If there isn't code similar to what is attached here on my on GitHub, send me a message and I'll make and check for any improved versions of the code.
Certainly not. Just ask the wife!
Here's a spirited thread on PWM frequency, featuring opposing views from two "professional" motor controller designers: http://www.electro-tech-online.com/robotics-mechatronics/19246-suitable-pwm-frequency-motor-control-4.html