Where are you at with your tracked robot? Have you driven it around at all?
The only driving I've done with the Vex treads is when I plugged a battery pack into the motors without any sort of control and let the treads drag the battery pack across the living room.
Your project has sure got me anxious to get some sort of Vex treaded robot up and running.
I'm guessing the main increase in speed is from lowering the resolution to 800. From the code you posted, it didn't look like you scaled your x and y values to take advantage of the full range of power settings (doubling the speed values would have had similar results).
I made the frequency adjustable on the fly. I'm curious what frequencies perform the best with various controllers. The controllers we're currently using should work fine at 20KHz but if you try to use 20KHz with a L298N, you'll get really bad performance.
20khz is great, with the Dx6i it feels like you're at one with the motor. Yes, the speed increase was from lowering the resolution to 800. I had set it even higher than what you initially specified for testing. We don't need anything else spinning out of control over here. I will fix the X and Y. I just wanted to get something working so I could show everyone this afternoon and made haste with the code.
You HAVE to get your tracked system going. I would put it right up there with mechanum in cool factor. You may even be able to imitate mechanum wheeled behavior with Vex tracks on a hard surface and the 150 rpm gear motors. When you see the video I post tomorrow you will resume work on it I bet.
Have you tried other frequencies at the new resolution.
I was just testing my MC33926 controller at 20KHz and it worked fine at high speed but at low speed it did not perform nearly as well at at low frequencies. As erco had predicted, 50Hz was even better than 200Hz for low speed control.
I bet you're right about my wanting to continue work on my treaded robot. It's been a lot of fun watching your come to life and I'm sure I'll need a treaded robot of my own (oh, not counting the Rover 5).
This robot has very little ground clearance, 0.75" to motor casing, 1.25" to chassis. I was pretty skeptical about doing this and started to bail on the idea, but continued while waiting for parts. I'm glad I did. When the tracks are close together, you don't need a lot of ground clearance, something I didn't realize until I drove it over all kinda of weird stuff.
The other really cool thing is the center of gravity is really low. Low center of gravity in addition to the tracks being close together may be just as good as more ground clearance with a higher center of gravity. There are obvious trade-offs. The point is I wouldn't normally consider something like this but as it turns out, it works quite well.
Works quite well indoors, on a nice dry floor. I guess next up will be getting it ready for outside.
I have tried lots of freqs and rez. So far 20khz/800 (even with a bad X and Y) had been the best result for going really fast and really slow. An easy way for me to test is to use the elevator trim one click at a time. At 20khz I can go slower than 200hz both keeping the same 800 resolution. My puppy loves this thing when it is quiet. He was giving it his ball earlier, so cute, both of them.
I'll just admit now I haven't done any of the math on anything yet. I know the RC is centered at 1500 and that becomes 0 or in my case 0 and -1 on the aileron. Add 800 and it's 2299 but I didn't load the RC demo code and see what the max the TX puts out is. I will take care of that on Black Friday, like a Black Friday SPIN sale.
Before I made any more changes to the code I decided to do some chassis debugging. The right track is making a clicking sound at high speed. I wasn't too concerned because I figured once I have the side panels made out of aluminum everything will be perfectly aligned. At the same time I still need to add a few things. The tracks are pretty forgiving, there is a little play in the track but it is still critical to align the sprockets. Since the front idler sprocket was only attached on one side I decided to work on that next.
I added a little support to it like this -
[IMG][/img]
The was a little slop because the idle sprocket was only riding on one side. Honestly I don't even know how that was working, I pressed the bearing into the ePVC, that must have a lot to do with it. I'm going to test this setup for a bit and see if it needs anything else.
Now the tracks have about .25" of play. For example if you lift the robot up the bottom of the tracks drop .25". That isn't tight enough to cause additional load and seems about the right amount of play.
It was raining today so I didn't get to do any outdoor testing. I did a lot of indoor testing, making big piles of computer stuff and books for it to climb. I'm happy with the flat track and will stick with it. I need the larger sprockets still, they will allow me to enclose the motors inside of the chassis to protect them, the motor stalls very easy if anything touches the encoder disk. I don't want them getting wet either. They don't put out much heat so they should be fine with everything else.
I started doing some CAD work, I think the design I have now is worth saving as a file. This would be a good profile for a high speed treaded robot:
I plan to post all of the drawings for the designs I test. I can also provide .dfx files when they're ready.
I've been doing some rough estimation and two tracks won't be long enough with the larger sprockets. I would need to order an additional track to compensate for the larger sprockets.
The clicking I've heard from sprockets turned out to be the ePVC warping from tightening down the motor screws. The sprockets are tapered at the tip of the teeth that bite the tracks, so they don't need to be perfectly aligned to work. I guess the thing to do would be countersink the screws into the ePVC instead of letting them deform it.
I just ordered another set of track, wish I had thought about it earlier, guess this buys me lots time to start messing with encoders
Here is some light outdoor action. Since the motors and encoders are exposed I picked something bumpy but dry and not too much dirt.
[video=youtube_share;i_fC3jvSGGU]
I'm going to do something like this with the chassis when I get the larger sprockets. That way it can be water resistant. The way the tracks are designed I don't think it would handle mud, snow and sand very well. The sprocket's teeth ride in grooves and those groves have no way to drain anything that accumulates in them without modification.
The picture above is what the size would look like using two tracks and the larger sprockets. It's a little to short for me so I will order a third track to divide in two and extend the chassis. The will also be 1" of ground clearance.
You can make the chassis square all day long but there is no way to make a square piece to hold the motor and idlers. The track will hit the corner. You can see in the drawing that if it were square it would hit the tracks.
So I'm still going to have a square chassis but the motor mount is what I'm working on now. The design below will allow the tracks enough room to operate, as well as provide a solid connection point for the idlers.
Update, I removed the +5v linear regulator and added a +5v switching power supply that can be scripted for battery management - http://www.mini-box.com/DCDC-USB?sc=8&category=981 It is rather large, but it beats the linear power supplies heat when I drive additional servos and my IP Camera. I will need to figure out something better once I know the interior size of the robot. Won't know that until I get the larger sprockets, but rough guestimating tells me I'll have more than enough room for something that size. Since the chassis will be completely enclosed heat is going to be a factor, so I might as well start dealing with switching power supply issues now.
I need to deal with one more custom connector for the connection to the Spectrum Rx, and the resistors as well. I think I will make a cable with the resistors in-line and shrink wrapped.
Black: 2200mah 3 cell lipo
Yellow: Mini-Box PSU
Green: Propeller Project Board cut in half (pending custom propeller board
Grey: RC Receiver
Blue: Motor Driver
Purple: +5v and Gnd x10 .1" headers on perfboard
I have also decided that 0.2" ePVC is a lot thicker than the T6 I will have the chassis made on. Because of that it is hard for me to prototype because I need both the physical object in front of me, as well as CAD to be effective (noob).
After the chassis is done I will move on to creating a carrier board for most likely the QuickStart. It would host all of the power buses and fuses as well as connection points for the motor encoders, and other sensors. Essentially there will be three boards;
Board #1: Motordriver
Board #2: Power Supply
Board #3: Stacking or neatly cabled removable Propeller board
These blue wires are the problem area. Surely other people have made cables with inline resistors for prototype work? It only needs to last a couple weeks until I have my custom boards.
Right now I have female headers crimped to the resistor and plugged into the Prop pin.
I know I said this robot had a purpose, but before that purpose is met there will be some side adventures. What kind of adventures?
How many?
All of them. This is the size platform I've been looking for. Purpose aside, having the space and power to play with is very inviting. So what kind of fun can you have with a half built robot?
I know that the answer around these parts is obvious. Put those eight cogs to work. In my spare time I'd like to implement machine vision. It is completely outside the "scope" of the project however, idle hands, on call all night...
I have a commercial license for Roborealm from a nice paid job a few years ago. Roborealm directly supports Parallax BOE Bot robots and the servo controller (and probably more example code than that), you can try it for free as well!
Anyway it does require a CPU. I use a wireless IP camera and roborealm captures it frame by frame. So it's like this;
It's fun because it's easy. Not something that you will learn a lot from, in the meantime I've been teaching it Parallax parts. I would love to have the Pixy I ordered, and Duane when I get it I'll try not to bother you too much
Xanadu, thanks for sharing your continuing efforts while you perfect the various systems necessary to achieve your goal.
In post #10 you referenced a modified version of Kwabenas encoder code. Since then I laser cut a 30 slot disk and am rotating it through 2 TCST2103 optical sensors to form a quadrature encoder. Although Im not interested in measuring speed at this time, I have used the code to experiment with tracking tick counts.
I could attach an oscilloscope photo that shows a very clean and a quite accurate phasing of the encoder but it s probably not necessary at this time to discuss my findings. (I am using a Quickstart board.)
Although I have no way to verify the accuracy of the tick counts accumulations, they seem to be accurate and repeatable. But what I have found is: The channel named Encoder_A_Pin_A allows the tick count to be changed by 1 count up or down consistent with the fore or aft edge triggering of the A channel pulse. I am not using Encoder_B_Pin_A and I have not observed this condition on Encoder_A_Pin_B.
To duplicate this, rotate your encoder disk just enough to edge trigger the encoder pin A, then back off, then edge trigger it again, and back off again - observe the tick count accumulation change as you continue this process. If youve done this for the rising edge and observed the accumulation change, now repeat this process for the falling edge of the pulse and observe the accumulation change in the opposite direction.
Granted, it would likely be a rare event this same edge toggling would occur in practice, it does seem to happen and can offer imprecise results. Id be curious to know if you can duplicate my findings.
Im sorry to say that I dont have PASM programming skills else Id look at Kwabenas code and offer additional remarks. Do you have any thought of porting the encoder code to C and add dead reckoning to the code too? Eg: In C, continuous rotation servo go to tick-count xxxxx at speed xxx. (I know youre using DC motors for your crawler.)
. . . To duplicate this, rotate your encoder disk just enough to edge trigger the encoder pin A, then back off, then edge trigger it again, and back off again - observe the tick count accumulation change as you continue this process. If you’ve done this for the rising edge and observed the accumulation change, now repeat this process for the falling edge of the pulse and observe the accumulation change in the opposite direction.
Granted, it would likely be a rare event this same edge toggling would occur in practice, it does seem to happen and can offer imprecise results. I’d be curious to know if you can duplicate my findings. . . .
This is a serious shortcoming of the object if this problem is the result of the software (which seems very likely). One of the main advantages of quadrature encoders is the ability to distinguish direction. If the software isn't getting the direction information right then it's not doing its job.
I'll start a thread with my version of a quadrature encoder counter today. Hopefully you both can try it out and let me know what you think about it.
The QEDengine does indeed track direction changes - that's not the problem. It also picks up a change of direction based on the fore or aft edge toggling of ONLY Encoder_A_Pin_A. The issue is that increasing or decreasing tick accumulation can be observed based on repetitive edge toggling of Pin_A. It seems possible for the tick accumulation to continually change while the rotating shaft stays within just +/- 1/4 distance of the encoder cycle.
Duane, I'm sure we'll all find your proposed encoder thread of interest, but because Xanadu is using QEDengine in this project, I'm hoping that he/she will attempt to duplicate this condition. I certainly don't want to suggest that QEDengine has a problem unless it can be confirmed by others.
Sorry, I'm not sure what I'm looking for. If you purposely trick the encoder to make this happen I'm not sure the code or hardware could ever help.
Pardon me if I'm not understanding this correctly, but you want me to pulse a leading or trailing edge a few times without letting the sensor pass the opposite edge?
I could see how some slop or backlash could cause something to be a tick or two off. I don't think that a single quadrature encoder is capable of not being tricked by the method you're using. I think you'd need to have a higher and lower resolution sensor on the same wheel, use the lower resolution for counting ticks for navigation and the higher resolution one to make sure that the wheel actually turned and not just bounced off the tick a few times?
If I understand what you're saying completely, and software can fix that, that is pretty amazing.
I have to run out and help some people get their spam, I'll try this out when I get back.
Duane, looking forward to testing your code as well. I need to really buckle down and start working on code as well but it's kinda cool that the AR1 can tell me what part I'm holding and read bar codes hehe.
Pardon me if I'm not understanding this correctly, but you want me to pulse a leading or trailing edge a few times without letting the sensor pass the opposite edge?
Yes, exactly. This would be to simulate a potential jitter condition that could send your crawler completely off course. Try it both ways exactly as you described it above and observe the accumulated count.
You can't "trick" a properly designed quadrature encoder.
Yes. And there are actually lots of applications were the same edge can kind of "vibrate" back and forth across one of the sensors. The quadrature encoder software should know its seeing the same edge multiple times and not continuous increase the count in a single direction.
I'll try to duplicate this result myself with Kye's object. If there's a problem with the code, it would be good to make people aware of it.
Do you have any thought of porting the encoder code to C and add dead reckoning to the code too? Eg: In C, continuous rotation servo go to tick-count xxxxx at speed xxx. (I know youre using DC motors for your crawler.)
At some point I would like to try. There are lots of things in C that are easier for me. The tracks skid a lot so ded reckoning might not be a priority over sensors. At this point I need it to be radio controlled to do a small proof of concept to impress someone. After that I'm sure that I will continue to build in new stuff regularly. I'm having the chassis made out of T6. It's going all the way
Yeah, I figured I didn't get what was going on lol.
It's quite straight forward... If you want to learn how an encoder should NOT work, you can easily run the experiment by:
1. Connect a LED to Pin_A of your encoder. Slowly rotate the encoder to make sure that the LED is flashing on Pin_A. (The problem doesn't seem to happen on Pin_B.)
2. Change the code you referenced in #10 above as follows:
3. Now rotate the encoder shaft exactly as you described above according to the off and on visual of the LED. Repeatedly (and separately) approach each edge to light the LED and then back off to turn it off while running the code. You'll notice the accumulated tick count increase or decrease depending on which side of the pulse you're observing.
It would also help to draw both A and B phase shifted wave forms. You'll see how the code ignores the other 3 conditions of the "A" and "B" combination to change direction and add or subtract tick counts.
I'm sure Duane will explain that which is necessary for proper encoder operation in his coming post. Having experimented with the above, quadrature encoder operation will then make sense to you..
Thank you for that explanation and also contributing to this project. It's great to work out any encoder issues since that will be handled by the Propeller instead of the previous motor controller.
The part I don't understand is how this works with just one sensor pin. I will follow your instructions above and see.
Using a single Roomba motor and encoder with the sample code I can see what you meant. The Roomba motor has less resolution and you can see the disk, plus they're easy to turn. It was a lot harder with the Polou motor. I am making adjustments to try it in a closed loop to observe its behavior.
My calculated RPM didn't agree with the RPM I was measuring by counting the rotations so I opened up one of the gearboxes.
These are the gears I found (teeth counts):
Gear attached to motor shaft:10
1st gear: 25 outer, 10 center
2nd gear: 30 outer, 12 center
3rd gear: 28 outer, 10 center
Final gear: 40
So I figure the reduction should be = 25/10 * 30/10 * 28/12 * 40/10 = 5/2 * 3 * 7/3 * 4 = 5*7*2 = 70
70 * 64 = 4,480 transitions per revolution not 4,331 as listed on Pololu's website.
While I had the gearbox removed from the motor, I double checked the number of transitions per rotation of the motor shaft. The figure of 64 was correct.
IMO Pololu's claim of 67.67:1 instead of the correct reduction of 70:1 is a pretty big error.
They also provide bad advice about using their h-bridge boards. They give instructions to pulse the direction pin instead of the enable which causes the motors to brake between each high pulse.
I still like Pololu, but I'm disappointed with some of their documentation.
I believe Kye's object may not accurately count the encoder pulses. Between the problems with the encoder object and the incorrect encoder data, it's no wonder your initial rpm readings didn't agree with what you observed.
I'm just putting some finishing touches on the documentation of my encoder object. I should be able to post it within a few hours.
Yes that very same motor. I didn't think 4331 was correct. I'm glad you figured that out because even now messing around with it things still weren't adding up. I also thought there were less ticks, not more - but I think I see why that is as well.
Pulse the direction pin? That would be interesting. Haven't seen that yet, do they have some tutorial for h-b on their site?
I'm using the VNH2SP30 datasheet since my motor controller is really just a breakout board for two of them. I like these a lot and thankfully have some code to use them.
Apparently I ordered the wrong sprockets. Lynx customer support is great and expediting the correct ones. I'm sure that my computer has a bad memory address that screws up my orders when I'm not paying attention. New ETA: December 19th, 2017, or so it feels.
Comments
The only driving I've done with the Vex treads is when I plugged a battery pack into the motors without any sort of control and let the treads drag the battery pack across the living room.
Your project has sure got me anxious to get some sort of Vex treaded robot up and running.
I'm guessing the main increase in speed is from lowering the resolution to 800. From the code you posted, it didn't look like you scaled your x and y values to take advantage of the full range of power settings (doubling the speed values would have had similar results).
I made the frequency adjustable on the fly. I'm curious what frequencies perform the best with various controllers. The controllers we're currently using should work fine at 20KHz but if you try to use 20KHz with a L298N, you'll get really bad performance.
You HAVE to get your tracked system going. I would put it right up there with mechanum in cool factor. You may even be able to imitate mechanum wheeled behavior with Vex tracks on a hard surface and the 150 rpm gear motors. When you see the video I post tomorrow you will resume work on it I bet.
Have you tried other frequencies at the new resolution.
I was just testing my MC33926 controller at 20KHz and it worked fine at high speed but at low speed it did not perform nearly as well at at low frequencies. As erco had predicted, 50Hz was even better than 200Hz for low speed control.
I bet you're right about my wanting to continue work on my treaded robot. It's been a lot of fun watching your come to life and I'm sure I'll need a treaded robot of my own (oh, not counting the Rover 5).
This robot has very little ground clearance, 0.75" to motor casing, 1.25" to chassis. I was pretty skeptical about doing this and started to bail on the idea, but continued while waiting for parts. I'm glad I did. When the tracks are close together, you don't need a lot of ground clearance, something I didn't realize until I drove it over all kinda of weird stuff.
The other really cool thing is the center of gravity is really low. Low center of gravity in addition to the tracks being close together may be just as good as more ground clearance with a higher center of gravity. There are obvious trade-offs. The point is I wouldn't normally consider something like this but as it turns out, it works quite well.
Works quite well indoors, on a nice dry floor. I guess next up will be getting it ready for outside.
I'll just admit now I haven't done any of the math on anything yet. I know the RC is centered at 1500 and that becomes 0 or in my case 0 and -1 on the aileron. Add 800 and it's 2299 but I didn't load the RC demo code and see what the max the TX puts out is. I will take care of that on Black Friday, like a Black Friday SPIN sale.
I added a little support to it like this -
[IMG][/img]
The was a little slop because the idle sprocket was only riding on one side. Honestly I don't even know how that was working, I pressed the bearing into the ePVC, that must have a lot to do with it. I'm going to test this setup for a bit and see if it needs anything else.
Now the tracks have about .25" of play. For example if you lift the robot up the bottom of the tracks drop .25". That isn't tight enough to cause additional load and seems about the right amount of play.
I started doing some CAD work, I think the design I have now is worth saving as a file. This would be a good profile for a high speed treaded robot:
I plan to post all of the drawings for the designs I test. I can also provide .dfx files when they're ready.
I've been doing some rough estimation and two tracks won't be long enough with the larger sprockets. I would need to order an additional track to compensate for the larger sprockets.
The clicking I've heard from sprockets turned out to be the ePVC warping from tightening down the motor screws. The sprockets are tapered at the tip of the teeth that bite the tracks, so they don't need to be perfectly aligned to work. I guess the thing to do would be countersink the screws into the ePVC instead of letting them deform it.
I just ordered another set of track, wish I had thought about it earlier, guess this buys me lots time to start messing with encoders
[video=youtube_share;i_fC3jvSGGU]
I'm going to do something like this with the chassis when I get the larger sprockets. That way it can be water resistant. The way the tracks are designed I don't think it would handle mud, snow and sand very well. The sprocket's teeth ride in grooves and those groves have no way to drain anything that accumulates in them without modification.
The picture above is what the size would look like using two tracks and the larger sprockets. It's a little to short for me so I will order a third track to divide in two and extend the chassis. The will also be 1" of ground clearance.
So I'm still going to have a square chassis but the motor mount is what I'm working on now. The design below will allow the tracks enough room to operate, as well as provide a solid connection point for the idlers.
I need to deal with one more custom connector for the connection to the Spectrum Rx, and the resistors as well. I think I will make a cable with the resistors in-line and shrink wrapped.
Black: 2200mah 3 cell lipo
Yellow: Mini-Box PSU
Green: Propeller Project Board cut in half (pending custom propeller board
Grey: RC Receiver
Blue: Motor Driver
Purple: +5v and Gnd x10 .1" headers on perfboard
I have also decided that 0.2" ePVC is a lot thicker than the T6 I will have the chassis made on. Because of that it is hard for me to prototype because I need both the physical object in front of me, as well as CAD to be effective (noob).
After the chassis is done I will move on to creating a carrier board for most likely the QuickStart. It would host all of the power buses and fuses as well as connection points for the motor encoders, and other sensors. Essentially there will be three boards;
Board #1: Motordriver
Board #2: Power Supply
Board #3: Stacking or neatly cabled removable Propeller board
Right now I have female headers crimped to the resistor and plugged into the Prop pin.
I know I said this robot had a purpose, but before that purpose is met there will be some side adventures. What kind of adventures?
How many?
All of them. This is the size platform I've been looking for. Purpose aside, having the space and power to play with is very inviting. So what kind of fun can you have with a half built robot?
I know that the answer around these parts is obvious. Put those eight cogs to work. In my spare time I'd like to implement machine vision. It is completely outside the "scope" of the project however, idle hands, on call all night...
I have a commercial license for Roborealm from a nice paid job a few years ago. Roborealm directly supports Parallax BOE Bot robots and the servo controller (and probably more example code than that), you can try it for free as well!
Anyway it does require a CPU. I use a wireless IP camera and roborealm captures it frame by frame. So it's like this;
Robot+IPCAM >>wifi>> computer+roborealm <<Xbee>> Robot
It's fun because it's easy. Not something that you will learn a lot from, in the meantime I've been teaching it Parallax parts. I would love to have the Pixy I ordered, and Duane when I get it I'll try not to bother you too much
In post #10 you referenced a modified version of Kwabenas encoder code. Since then I laser cut a 30 slot disk and am rotating it through 2 TCST2103 optical sensors to form a quadrature encoder. Although Im not interested in measuring speed at this time, I have used the code to experiment with tracking tick counts.
I could attach an oscilloscope photo that shows a very clean and a quite accurate phasing of the encoder but it s probably not necessary at this time to discuss my findings. (I am using a Quickstart board.)
Although I have no way to verify the accuracy of the tick counts accumulations, they seem to be accurate and repeatable. But what I have found is: The channel named Encoder_A_Pin_A allows the tick count to be changed by 1 count up or down consistent with the fore or aft edge triggering of the A channel pulse. I am not using Encoder_B_Pin_A and I have not observed this condition on Encoder_A_Pin_B.
To duplicate this, rotate your encoder disk just enough to edge trigger the encoder pin A, then back off, then edge trigger it again, and back off again - observe the tick count accumulation change as you continue this process. If youve done this for the rising edge and observed the accumulation change, now repeat this process for the falling edge of the pulse and observe the accumulation change in the opposite direction.
Granted, it would likely be a rare event this same edge toggling would occur in practice, it does seem to happen and can offer imprecise results. Id be curious to know if you can duplicate my findings.
Im sorry to say that I dont have PASM programming skills else Id look at Kwabenas code and offer additional remarks. Do you have any thought of porting the encoder code to C and add dead reckoning to the code too? Eg: In C, continuous rotation servo go to tick-count xxxxx at speed xxx. (I know youre using DC motors for your crawler.)
This is a serious shortcoming of the object if this problem is the result of the software (which seems very likely). One of the main advantages of quadrature encoders is the ability to distinguish direction. If the software isn't getting the direction information right then it's not doing its job.
I'll start a thread with my version of a quadrature encoder counter today. Hopefully you both can try it out and let me know what you think about it.
Duane, I'm sure we'll all find your proposed encoder thread of interest, but because Xanadu is using QEDengine in this project, I'm hoping that he/she will attempt to duplicate this condition. I certainly don't want to suggest that QEDengine has a problem unless it can be confirmed by others.
Pardon me if I'm not understanding this correctly, but you want me to pulse a leading or trailing edge a few times without letting the sensor pass the opposite edge?
I could see how some slop or backlash could cause something to be a tick or two off. I don't think that a single quadrature encoder is capable of not being tricked by the method you're using. I think you'd need to have a higher and lower resolution sensor on the same wheel, use the lower resolution for counting ticks for navigation and the higher resolution one to make sure that the wheel actually turned and not just bounced off the tick a few times?
If I understand what you're saying completely, and software can fix that, that is pretty amazing.
I have to run out and help some people get their spam, I'll try this out when I get back.
Duane, looking forward to testing your code as well. I need to really buckle down and start working on code as well but it's kinda cool that the AR1 can tell me what part I'm holding and read bar codes hehe.
You can't "trick" a properly designed quadrature encoder.
Yes, exactly. This would be to simulate a potential jitter condition that could send your crawler completely off course. Try it both ways exactly as you described it above and observe the accumulated count.
Yes. And there are actually lots of applications were the same edge can kind of "vibrate" back and forth across one of the sensors. The quadrature encoder software should know its seeing the same edge multiple times and not continuous increase the count in a single direction.
I'll try to duplicate this result myself with Kye's object. If there's a problem with the code, it would be good to make people aware of it.
I just posted a thread with my test program in the Propeller forum.
Thanks for catching this Wildatheart.
At some point I would like to try. There are lots of things in C that are easier for me. The tracks skid a lot so ded reckoning might not be a priority over sensors. At this point I need it to be radio controlled to do a small proof of concept to impress someone. After that I'm sure that I will continue to build in new stuff regularly. I'm having the chassis made out of T6. It's going all the way
It's quite straight forward... If you want to learn how an encoder should NOT work, you can easily run the experiment by:
1. Connect a LED to Pin_A of your encoder. Slowly rotate the encoder to make sure that the LED is flashing on Pin_A. (The problem doesn't seem to happen on Pin_B.)
2. Change the code you referenced in #10 above as follows:
repeat
pst.str(string(" "))
pst.str (string("Motor 1 "))
'getSpeedA
pst.dec(channelADeltaTicks)
pst.str(string(" "))
'pst.str(string("Motor 2 "))
'getSpeedB
'pst.dec(channelBTickFrequency)
pst.newline
waitcnt (clkfreq * 1 + cnt)
3. Now rotate the encoder shaft exactly as you described above according to the off and on visual of the LED. Repeatedly (and separately) approach each edge to light the LED and then back off to turn it off while running the code. You'll notice the accumulated tick count increase or decrease depending on which side of the pulse you're observing.
It would also help to draw both A and B phase shifted wave forms. You'll see how the code ignores the other 3 conditions of the "A" and "B" combination to change direction and add or subtract tick counts.
I'm sure Duane will explain that which is necessary for proper encoder operation in his coming post. Having experimented with the above, quadrature encoder operation will then make sense to you..
The part I don't understand is how this works with just one sensor pin. I will follow your instructions above and see.
Exactly... Quadrature encoders require 2 sensors (pins).
The fact that we're seeing direction and accumulation change on only one sensor pin is the reason for this discussion.
Using a single Roomba motor and encoder with the sample code I can see what you meant. The Roomba motor has less resolution and you can see the disk, plus they're easy to turn. It was a lot harder with the Polou motor. I am making adjustments to try it in a closed loop to observe its behavior.
You're using these exact motors from Pololu right?
My calculated RPM didn't agree with the RPM I was measuring by counting the rotations so I opened up one of the gearboxes.
These are the gears I found (teeth counts):
Gear attached to motor shaft:10
1st gear: 25 outer, 10 center
2nd gear: 30 outer, 12 center
3rd gear: 28 outer, 10 center
Final gear: 40
So I figure the reduction should be = 25/10 * 30/10 * 28/12 * 40/10 = 5/2 * 3 * 7/3 * 4 = 5*7*2 = 70
70 * 64 = 4,480 transitions per revolution not 4,331 as listed on Pololu's website.
While I had the gearbox removed from the motor, I double checked the number of transitions per rotation of the motor shaft. The figure of 64 was correct.
IMO Pololu's claim of 67.67:1 instead of the correct reduction of 70:1 is a pretty big error.
They also provide bad advice about using their h-bridge boards. They give instructions to pulse the direction pin instead of the enable which causes the motors to brake between each high pulse.
I still like Pololu, but I'm disappointed with some of their documentation.
I believe Kye's object may not accurately count the encoder pulses. Between the problems with the encoder object and the incorrect encoder data, it's no wonder your initial rpm readings didn't agree with what you observed.
I'm just putting some finishing touches on the documentation of my encoder object. I should be able to post it within a few hours.
Yes that very same motor. I didn't think 4331 was correct. I'm glad you figured that out because even now messing around with it things still weren't adding up. I also thought there were less ticks, not more - but I think I see why that is as well.
Pulse the direction pin? That would be interesting. Haven't seen that yet, do they have some tutorial for h-b on their site?
I'm using the VNH2SP30 datasheet since my motor controller is really just a breakout board for two of them. I like these a lot and thankfully have some code to use them.