I keep watching for ideas to use on my treaded robot. Thanks for documenting this.
I'm not powering the encoders from an I/O pin; I'm just powering the pin with same supply as the Propeller chip. I'm using a Propeller Project board with my robot. The Project Board doesn't have a 5V source on it. By using 3.3V, I don't need to add a 5V regulator. If I use large enough resistors on the encoder output, I could power the encoder with the motor's supply of 12V. Using 3.3V seems like the safer option.
I see you have a rubber band to limit the movement of the wires. I use a couple of pieces of Gorilla tape to hold the wires against the motor so they don't bend where they meet the encoder PCB. I had to solder a broken wire back in place before I learned to limit the movement of the wires.
Gotcha on the 3.3v, I don't like having a 5v bus either if you go linear there is too much heat from a 12v supply. I have run my encoders down to 3.12v before they start to drop out. That is a pretty small margin though. I think 3.3v is better choice than 12v and either way if it drops out on 3.3v it won't be that hard to switch to 12v. I love the wide voltage range. I don't love that they're soldered on but I'm getting used to it.
The rubber band was more for when they were new and had that heat shrink around all the wires. It was so stiff I thought for sure I was going to pull the connector from the PCB. After I sliced off the shrink wrap I just left the bands there to keep the stress of the connector. I have caught myself pressing the encoder wheel pretty hard into my palm by accident a few times.
I have another motor controller coming tomorrow. http://www.pololu.com/product/708 It has current sensing which was another reason I wanted the Roboclaw. It's also another thing like the encoder the Prop will eventually do, just nice to have working right away.
I hope to have some kind of working chassis tomorrow. I already have a ton of code I can use from other bots
The MC33926 also has current sensing. It can handle much less current than than the VNH2SP30 but I think the MC33926 should work fine with these motors (I'm using the MC33926 myself).
The MC33926 will be on sale in a few hours for $17.95 (regularly $29.95)
These motors (normally $39.95) will also be on sale for $24.89 (if you spend at least $100).
I'm seriously thinking about getting a set of four motors with MC33926 controllers during this sale (I purchased the set of four motors I have now last year at Pololu's Black Friday sale).
I think I will get at least two more so I can do a four motor setup and maybe mechanum. After this experience I'm much more inclined to use small motors. I never knew they had so much power.
Couple more pics -
The ePVC cracked a little around the bearing, but it is still super strong. I still think that these pieces will need to be metal before it does anything too crazy.
Just something to try when I get the motor controller. The chassis has a long way to go still...
That looks really cool! You've got me itching to get back to work on my treaded vehicle.
It's too bad there's not a way of mounting the motors higher. The way they're mounted now kind of kills your ground clearance. I can see why there are so many triangular configurations around. A triangular tread would allow for more ground clearance.
Your design allows for a low profile which might be a benefit in some situations.
I just may end up raising the motors. I am more concerned about dirt and water than ground clearance. I've been watching a lot of videos of small tracked robots with very little ground clearance traveling pretty smoothly over rocky terrain.
Anxiously waiting some motor controller action hehe. Good thing work is busy I'd probably have it going using relays by now...
I got the motor driver. It doesn't want to play. It's pretty simple like a stepper driver. I have enable and 1INa pulled high, 1INb pulled low, 5v and gnd hooked up, and PWM'ing the PWM pin. Tried it connected to each channel individually and nothing.
Trying to get out of going to the movies to figure out how I can possibly not be able to hook up two motor controllers in a row now
I had the power supply end of my power leads going to the motor controller unplugged. It's got no power LED so ya know.... ehhh. Works like a charm now. I want to make some cool PWM tones with my motors.
I guess I'm going to either use the Prop and XBee or Dx6i to drive it around. I have until a movie is over plus "20 minutes" to play with so the pressure is on!
I have been meaning to check out that object. I am using a different one. I'm working PWM code into the encoder code and using XBee as a quick and easy way to test. I will definitely add that object next.
So far so good. I like these VNH2SP3s. So far they have been cool to the touch. I wish the carrier board had 4 holes for standoffs though.
Actually I'm really not sure which Object to use. The only dual motor driver is http://obex.parallax.com/object/211 and I'm not really sure how it would work with something that requires PWM, all I see are the direction control pins.
Actually I'm really not sure which Object to use. The only dual motor driver is http://obex.parallax.com/object/211 and I'm not really sure how it would work with something that requires PWM, all I see are the direction control pins.
I'm pretty sure I have a modified version of that object to use PWM on enable and two direction pins. I'll try to find it.
I couldn't find the modified version of Kye's driver (if I ever made one).
I did find several different drivers but they didn't have a good demo to go with them.
I ended up adding a short demo to the object I'm currently working on. I just recently started adding PWM motor control to my encoder object. I commented out the encoder parts since I'm not satisfied with how that part works right now. I also trimmed off two of the motors (if was originally for four motors).
The demo uses "+" and "-" to control the motor on channel zero and "*" and "/" to control the motor on channel one. Instead of these particular keys you could use numbers to set the speed. As you'll see in the demo (included in the object) you'll want to set the "targetSpeed" value. "targetSpeed" would normally be in the parent object so it's address is passed to the start menu so the object can read the speed.
You can refresh the terminal window by pressing "c" (for clear).
As the program is right now, the "RefreshSpeed" method had to be called whenever the target speed is changed. I need to added the math to the PASM section to convert the speed to clock cycles.
This motor with encoder object is currently a high priority project for myself. Hopefully I'll have it working well enough soon enough to be useful in your current project.
If you do search "crayrobotgirl" you'll find an object by Hanno I modified that should also work with your motor controllers. I don't think Hanno's object has an advantage over the one attached here.
Notice the PWM frequency is currently set to 200Hz. You'll probably want to change this. You can also change the resolution. Currently the resolution is 1000 which allows speed settings between -1000 and 1000.
If you use an inverter on one of the direction pins, you can control both pins with one I/O pin. If you do this use "-1" as the pin for the negative direction pin in this object. I haven't test this aspect of the driver but I think it should work.
Wow this is great and needs to be in OBEX. I wish I could contribute more (maybe I can) but a driver for a robot with encoders using regular PWM would be pretty popular I bet. Hopefully we can work out the encoder issue.
I added some provision for the directional control pins. I love the low PWM frequency noises so I actually left it at 200hz lol...
I'm going to implant the RC object into this code. Thanks a lot for posting the code!
Your turkey just needs a bit more stuffing (sensors, etc.).
I realized after I posted the object last night, it's almost of waste of a cog. I'm pretty sure the counters could take care of the pulses without needing to use the PASM portion of the code. It makes more sense using PASM to generate four PWM signals. Adding the encoders will also make it not waste a cog.
As of now I'm not getting any closed loop action, that is because it is not yet implemented in this code?
Those are motor direction pins. I used "red" for forward and "black" for reverse.
On my board, I'm using P8 on the PWM pin for motor control #0. P9 and P10 connect to the two direction pins. The second motor uses P11 - P13 for its control pins.
With four motors there are lots of pins which need to be passed. I was exceeding the number of parameters allowed in a method so I needed to pass pin assignments as a pointer.
The program should lend itself to being a child object relatively easily. Just move all the "parent object" marked parts to a parent object and delete those same portions from the child object.
Yes, it's currently not closed loop. I just commented out the encoder portion but I don't think the encoder portion would do you much good without seeing how it's used in the parent object.
I'm in the process of overhauling how the encoders work. Right now speed is measure as ticks per unit time (not per second some arbitrary time amount), I plan to change it to measure the time between ticks to allow better low speed control. So currently the closed loop portion is broken. Once I get the closed loop portion working again, I'll post it if you like.
I do think I'll try to get the closed loop to work again with the combined motor and encoder driver before I continue modifying the encoder portion. The speed is currently computed by adding speed values of a circular buffer. The speed derived this way will depend on the frequency the speed is sampled and the number of samples in the buffer. I haven't done the math to figure out what these units are (though it shouldn't be too hard to do so).
Thanks Duane, I guess I need to retry the direction pins for some reason I wasn't getting any movement without manually pulling them. I think things were getting a little messy on the bench. Here is where I'm at now-
This should be a lot less confusing and much shorter runs for everything.
Okay I see where I went wrong with the direction pins. I have everything working now, just deciding on how to translate the PWM output of the RX to the PWM output for the motors.
Edit: wait sorry hold the phone I didn't really look at the object yet lol... Makes sense now.
I always configure my motors so positive speed will move the robot forward. You can always swap the direction pins on the motor controller if you need to.
The above code is actually a bit simplified. I ignore input within a dead band area.
repeat result from 0 to HIGHEST_CHANNEL
tempChannel[result] := Rc.GetRc(result)
if tempChannel[result] < -deadBand[result]
long[channelPtr][result] := tempChannel[result] + deadBand[result]
elseif tempChannel[result] =< deadBand[result]
long[channelPtr][result] := 0
else
long[channelPtr][result] := tempChannel[result] - deadBand[result]
The code I pulled this from is kind of complicated since it allows for several different input types (Wii Nunchuck, etc.).
I used the "GetRC" method since it uses zero for center.
Sorry I meant to edit that post, I am using RcGet now, so easy a caveman could do it hehehe. I like how the zero value can be sent straight to the motor driver! This is way more than I had anticipated getting done today and I really appreciate the code you have provided!
I have a couple different thoughts on mixing the channels. Something also tells me that none of them will work, trying a couple different methods right now.
The problem with the above mentioned code is it does all things for all robots (well sort of). It allows various input devices and wheel configurations. I'm afraid it may be harder to figure out how to use the code than to finish the code you're working on.
I do suggest you look through my earlier post and see how I scaled the input and checked for a dead zone.
After some test driving I bumped up the PWM freq to 20khz and set the PWM resolution down to 800. It's about three times faster. It will literally go anywhere and over anything unless it flips over. When I drive in a circle the outer tread breaks loose and does a burn out like it's drifting.
In summation I would have to say that these motors on a similar sized robot with Vex tracks (much lighter and less current) will be a lot like a muscle car. Where are you at with your tracked robot? Have you driven it around at all?
I'm going to make a video of it in performance mode tomorrow. A 3S 2200mah battery drops about one volt in 10 minutes of driving. Kinda cool since that is worst case scenario. I noticed at high speed I have some kind of clicking. Should be a simple adjustment, one can hope.
Comments
I also think they look better aesthetically this way.
Very nice.
Gotcha on the 3.3v, I don't like having a 5v bus either if you go linear there is too much heat from a 12v supply. I have run my encoders down to 3.12v before they start to drop out. That is a pretty small margin though. I think 3.3v is better choice than 12v and either way if it drops out on 3.3v it won't be that hard to switch to 12v. I love the wide voltage range. I don't love that they're soldered on but I'm getting used to it.
The rubber band was more for when they were new and had that heat shrink around all the wires. It was so stiff I thought for sure I was going to pull the connector from the PCB. After I sliced off the shrink wrap I just left the bands there to keep the stress of the connector. I have caught myself pressing the encoder wheel pretty hard into my palm by accident a few times.
I have another motor controller coming tomorrow. http://www.pololu.com/product/708 It has current sensing which was another reason I wanted the Roboclaw. It's also another thing like the encoder the Prop will eventually do, just nice to have working right away.
I hope to have some kind of working chassis tomorrow. I already have a ton of code I can use from other bots
The MC33926 will be on sale in a few hours for $17.95 (regularly $29.95)
These motors (normally $39.95) will also be on sale for $24.89 (if you spend at least $100).
I'm seriously thinking about getting a set of four motors with MC33926 controllers during this sale (I purchased the set of four motors I have now last year at Pololu's Black Friday sale).
Couple more pics -
The ePVC cracked a little around the bearing, but it is still super strong. I still think that these pieces will need to be metal before it does anything too crazy.
Just something to try when I get the motor controller. The chassis has a long way to go still...
It's too bad there's not a way of mounting the motors higher. The way they're mounted now kind of kills your ground clearance. I can see why there are so many triangular configurations around. A triangular tread would allow for more ground clearance.
Your design allows for a low profile which might be a benefit in some situations.
I just may end up raising the motors. I am more concerned about dirt and water than ground clearance. I've been watching a lot of videos of small tracked robots with very little ground clearance traveling pretty smoothly over rocky terrain.
Anxiously waiting some motor controller action hehe. Good thing work is busy I'd probably have it going using relays by now...
Trying to get out of going to the movies to figure out how I can possibly not be able to hook up two motor controllers in a row now
I guess I'm going to either use the Prop and XBee or Dx6i to drive it around. I have until a movie is over plus "20 minutes" to play with so the pressure is on!
Have you seen this object? My contribution was to allow it to work with any six of the I/O pins.
So far so good. I like these VNH2SP3s. So far they have been cool to the touch. I wish the carrier board had 4 holes for standoffs though.
I'm pretty sure I have a modified version of that object to use PWM on enable and two direction pins. I'll try to find it.
I did find several different drivers but they didn't have a good demo to go with them.
I ended up adding a short demo to the object I'm currently working on. I just recently started adding PWM motor control to my encoder object. I commented out the encoder parts since I'm not satisfied with how that part works right now. I also trimmed off two of the motors (if was originally for four motors).
The demo uses "+" and "-" to control the motor on channel zero and "*" and "/" to control the motor on channel one. Instead of these particular keys you could use numbers to set the speed. As you'll see in the demo (included in the object) you'll want to set the "targetSpeed" value. "targetSpeed" would normally be in the parent object so it's address is passed to the start menu so the object can read the speed.
You can refresh the terminal window by pressing "c" (for clear).
As the program is right now, the "RefreshSpeed" method had to be called whenever the target speed is changed. I need to added the math to the PASM section to convert the speed to clock cycles.
This motor with encoder object is currently a high priority project for myself. Hopefully I'll have it working well enough soon enough to be useful in your current project.
If you do search "crayrobotgirl" you'll find an object by Hanno I modified that should also work with your motor controllers. I don't think Hanno's object has an advantage over the one attached here.
Notice the PWM frequency is currently set to 200Hz. You'll probably want to change this. You can also change the resolution. Currently the resolution is 1000 which allows speed settings between -1000 and 1000.
If you use an inverter on one of the direction pins, you can control both pins with one I/O pin. If you do this use "-1" as the pin for the negative direction pin in this object. I haven't test this aspect of the driver but I think it should work.
Time for bed.
Happy Thanksgiving.
I added some provision for the directional control pins. I love the low PWM frequency noises so I actually left it at 200hz lol...
I'm going to implant the RC object into this code. Thanks a lot for posting the code!
Here is my Thanksgiving "turkey"
I realized after I posted the object last night, it's almost of waste of a cog. I'm pretty sure the counters could take care of the pulses without needing to use the PASM portion of the code. It makes more sense using PASM to generate four PWM signals. Adding the encoders will also make it not waste a cog.
Stuffing is inbound soon hopefully. That thing was a mess. I just pulled all the jumpers, mounted everything to the robot and re-wired it.
One thing about the motor driver, just to be sure
Those are encoder pins not direction pins right?
As of now I'm not getting any closed loop action, that is because it is not yet implemented in this code?
I almost have the RC code massaged into the PWM driver code
Those are motor direction pins. I used "red" for forward and "black" for reverse.
On my board, I'm using P8 on the PWM pin for motor control #0. P9 and P10 connect to the two direction pins. The second motor uses P11 - P13 for its control pins.
With four motors there are lots of pins which need to be passed. I was exceeding the number of parameters allowed in a method so I needed to pass pin assignments as a pointer.
The program should lend itself to being a child object relatively easily. Just move all the "parent object" marked parts to a parent object and delete those same portions from the child object.
Yes, it's currently not closed loop. I just commented out the encoder portion but I don't think the encoder portion would do you much good without seeing how it's used in the parent object.
I'm in the process of overhauling how the encoders work. Right now speed is measure as ticks per unit time (not per second some arbitrary time amount), I plan to change it to measure the time between ticks to allow better low speed control. So currently the closed loop portion is broken. Once I get the closed loop portion working again, I'll post it if you like.
I do think I'll try to get the closed loop to work again with the combined motor and encoder driver before I continue modifying the encoder portion. The speed is currently computed by adding speed values of a circular buffer. The speed derived this way will depend on the frequency the speed is sampled and the number of samples in the buffer. I haven't done the math to figure out what these units are (though it shouldn't be too hard to do so).
This should be a lot less confusing and much shorter runs for everything.
Edit: wait sorry hold the phone I didn't really look at the object yet lol... Makes sense now.
I am able to control the motors manually and also see the pulselenghts on the pst at the same time now which is good.
Any ideas?
I think I scaled the values by two and saved them in globalX and globalY.
This was the speed calculation for the Rover 5.
I think this might work:
I always configure my motors so positive speed will move the robot forward. You can always swap the direction pins on the motor controller if you need to.
The above code is actually a bit simplified. I ignore input within a dead band area.
repeat result from 0 to HIGHEST_CHANNEL tempChannel[result] := Rc.GetRc(result) if tempChannel[result] < -deadBand[result] long[channelPtr][result] := tempChannel[result] + deadBand[result] elseif tempChannel[result] =< deadBand[result] long[channelPtr][result] := 0 else long[channelPtr][result] := tempChannel[result] - deadBand[result]The code I pulled this from is kind of complicated since it allows for several different input types (Wii Nunchuck, etc.).
Next hurdle is mixing. I completely forgot about mixing the channels so I can use one stick. Do you have any examples of that handy?
This is what I have now -
repeat repeat result from 0 to Rc#POSSIBLE_CHANNELS - 1 elevator_ch := Rc.GetRc(0) aileron_ch := Rc.GetRc(1) pst.dec(Rc.GetRc(0)) pst.newline pst.dec(Rc.GetRc(1)) pst.newline targetspeed[0] := elevator_ch targetspeed[1] := aileron_ch waitcnt (clkfreq / 5 + cnt) RefreshSpeedSorry I meant to edit that post, I am using RcGet now, so easy a caveman could do it hehehe. I like how the zero value can be sent straight to the motor driver! This is way more than I had anticipated getting done today and I really appreciate the code you have provided!
I have a couple different thoughts on mixing the channels. Something also tells me that none of them will work, trying a couple different methods right now.
targetspeed[0] := elevator_ch + aileron_ch targetspeed[1] := elevator_ch - aileron_chSeems to work okay, steering is a little sensitive. I guess I can use expo on the radio to cure that for now.
This is so cool!!
The problem with the above mentioned code is it does all things for all robots (well sort of). It allows various input devices and wheel configurations. I'm afraid it may be harder to figure out how to use the code than to finish the code you're working on.
I do suggest you look through my earlier post and see how I scaled the input and checked for a dead zone.
[video=youtube_share;CPXZLOYdER0]
That's fantastic! Very fun. Thanks for the video.
What frequency are you using? Is that 200Hz? The squeal from the motors sounds higher pitched than mine.
I think erco likes to use 50Hz.
[video=youtube_share;Ty8gJW0cilk]
In summation I would have to say that these motors on a similar sized robot with Vex tracks (much lighter and less current) will be a lot like a muscle car. Where are you at with your tracked robot? Have you driven it around at all?
I'm going to make a video of it in performance mode tomorrow. A 3S 2200mah battery drops about one volt in 10 minutes of driving. Kinda cool since that is worst case scenario. I noticed at high speed I have some kind of clicking. Should be a simple adjustment, one can hope.