Stingray Motor Shaft Encoders
Sal Ammoniac
Posts: 213
Has anyone come up with a good way to attach a shaft encoder to the armature shaft of the motors on a Stingray?
Comments
look like they would do nicely. From the assembly instructions the motor shown looks the same as the motors used by Parallax.
Duffer
I've ordered a couple of these and will post here after I've gotten them and tested them out.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Check out the Propeller Wiki·and contribute if you can.
Great find. I look forward to hearing how this comes out.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Whit+
"We keep moving forward, opening new doors, and doing new things, because we're curious and curiosity keeps leading us down new paths." - Walt Disney
Anyway, they do have a ton of options and different encoders, so it's a good site to save for possible future needs. Thanks!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Check out the Propeller Wiki·and contribute if you can.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Whit+
"We keep moving forward, opening new doors, and doing new things, because we're curious and curiosity keeps leading us down new paths." - Walt Disney
however, I am having a problem I don't yet understand.
I have connected the A/B signals to Ports 3,4,5,6 on the stingray and am seeing a 4V signal as observed using the parallax usb o-scope, however at the output of the level shifters I am seeing a very intermittent signal. Sometimes at 3V sometimes at 1V or less.
As an aside I have written some test code that spins the wheels and then counts falling transitions stopping when some count is reached but so far it just spins the wheels without stopping (most likely just hangs waiting for a transition but I haven't checked yet)
Anyone have any ideas?
Update:
The problem turns out to be a bad port on the voltage translator. Moving the encoder pin assignments solved the problem.
So the bottom line is that the QME-01 encoders work just fine.
I also just uploaded a new working encoder test program the original had several bugs
Manually bump the wheel to start them turning (Dumb, I know, but hey its only a test)
Ray
Post Edited (Ray0665) : 1/11/2010 6:33:51 AM GMT
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Check out the Propeller Wiki·and contribute if you can.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chris Savage
Parallax Engineering
Check out the new Savage Circuits TV!
·
I got them to "experiment with", and will likely end up getting whatever version you settle on from the Parallax store. I want to be able to use/share code that works with standard stuff.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Check out the Propeller Wiki·and contribute if you can.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chris Savage
Parallax Engineering
Check out the new Savage Circuits TV!
·
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Check out the Propeller Wiki·and contribute if you can.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chris Savage
Parallax Engineering
Check out the new Savage Circuits TV!
·
Using my test program with the speed set to 90 I am seeing about 70 microseconds per pulse so this is well within the props capabilities.
Ray
OK just to get things started, with these encoders here is a short turtle graphics like program that draws polygons with the Stingray.
It uses the Linxmotion QME-01 wheel encoders for distance and turn calculations. Have fun.
Ray
I got my QME-01 encoders today and installed them. I tried your program out and found things to be a little off with my Stingray. After checking out the code and doing some experimenting I believe I have things working reasonably well now.
First, I think these motors might be 25:1 gear ratio instead of 30:1.· Using 2500 pulses per tire revolution resulted in reasonably accurate actual distances travelled by my Stingray. (So in the code if I say go 38cm, it travels 38cm on a flat wood surface.)
Second, in your constants you had some stuff that was ending up doing integer math instead of (I assume) the intended float operations. Also, since runtime code can't do floats without a math library, I changed things so that it uses 10 cm, and 10 degrees in the constants and divides by 10 in the runtime. This made things more accurate for me.
Third, I changed the motor driving stuff to drive each motor until it's counter reached the desired pulses. You were only checking counter A, and driving both motors based on that, but because of possible slipping (especially when turning) it needs to check both counters and drive the motors accordingly.
I've attached my version of the Poly-1.spin code, for you to review.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Check out the Propeller Wiki·and contribute if you can.
Post Edited (Roy Eltham) : 1/13/2010 12:21:32 AM GMT
Thanks for looking at Poly-1, I'm glad you used it to get started, that was my intention.
I am running my bot on a rug (short loop Berber) when I went to the hardwood floor the bot fishtailed on the turns throwing everything off because stop as written apparently just removes power from the motors and allows some coasting plus there is no speed ramping so some differences are expected.
I am getting a repeatable 1 meter square (turning both left and right) and the bot ends up on the starting point oriented as it started with Poly-1 as written.
When I downloaded your modified program I got an open figure with the bot oriented about 30 degrees left and about a foot from the starting point so we obviously have soom differences between our bots.
Epmm is an integer divided by an integer with the results truncated to an integer. Since the units are in mm I did not see the need for more accuracy.
For this simple demo program using one encoder on one wheel is good enough when I get around to actually doing odometry I'll certainly use both.
Ray
Yeah, I'm no longer convinced my code is correct. I get different results depending on the number of sides I pick and at different speeds. I was getting a pretty consistent square 38cm to a side at speed 25 on the wood surface using my version, but with 6 or 8 sides it gets off track, and at faster speeds it is also off. However, I to see it "correcting" sometimes with the DriveMotors code checking both counters. Also, the coasting issue is notable on the wood surface. I think I was just getting lucky with my square working out.
I am attempting to make my code ramp the motors up and down. Including starting the ramp down before it gets to the pulse count to reduce overshooting.
Maybe Chris Savage can give us the definitive answer on the gear ratio for these motors?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Check out the Propeller Wiki·and contribute if you can.
A lot of stuff I read regarding the "Square test" uses 4 meters on a side. I suspect 38cm simply wasn't enough
Good luck, have fun, over and out (for now anyway)
Ray
This is great stuff! Glad you all are getting some good results.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Whit+
"We keep moving forward, opening new doors, and doing new things, because we're curious and curiosity keeps leading us down new paths." - Walt Disney
1. The gear ratio is 30:1, even the docs say so. The reason I thought 25:1 was possible was because of doing things the wrong way and being in a hurry to "get results".
2. Even with a reasonable load, when you tell a motor to stop, it keeps right on going for a little bit. (sometimes as much as 200-300 ticks on these encoders) Ramping up and down will likely help a bunch with this. Especially, slowing the motors down well before you get to the desired tick count so you can hit the count without overshooting it too much.
3. My motors definitely run at different speeds given the same duty cycles on the controller. I need to write some code to drive the motors to a desired tick rate from the encoders instead of just using pwm duty cycles on the controller.
3a. These motors take a reasonable PWM duty cycle level to get moving at all (15-25 depending on the surface), and this causes the slowest speed to not be that slow. Maybe different PWM methods will help here? Or do we need to get motors with higher gear ratios? (Lynxmotion has one with 50:1)
Roy
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Check out the Propeller Wiki·and contribute if you can.
Yeah, the motors were spec'd to be 30:1. If there is a variance it isn't intended on our part and I will do some further testing this weekend. I need to get out the US Digital encoders and check those out as well until we have a solution. This way I can compare with what you're seeing as well. Thanks for the feedback.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chris Savage
Parallax Engineering
Check out the new Savage Circuits TV!
·
It seems like the motors and controller on the Stingray don't really do "braking". I've read some stuff that says typical h-bridge setups can do braking, but my testing on the Stingray shows no noticable difference in how hard it is to manually turn the wheels when the power is off verses when the power is on and the code is driving the motor controller with either 0,0 or 1,1 (the table in the docs say that that should be braking). I tried with 1 7.2v battery and with two in parallel (not that that would change much).
I did notice that my motors make a high pitched whine sound when I have the code drive the motor controller to 1,1, but it didn't feel like it was doing any braking.
Roy
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Check out the Propeller Wiki·and contribute if you can.
I would love to play with this but I just don't have the time. The physics is there but...
Has anyone tried mounting a magnet perpendicular to the shaft with hall effect sensor watching the field?
Does a hobby motor spin up fast enough to distort the field?
Can it·work?
Jim-
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Signature space for rent!
Send $1 to CannibalRobotics.com.
If you're running the code that spins the wheels full speed in one direction and you press the reset button, the wheels should come screeching to a halt. On the other hand, if you run the same code then quickly slide the power switch to the off position the motors should freewheel a bit. When the power switch is on, the H-Bridge is enabled and when both lines are at the same level braking is enabled. I can make a video if you like to demonstrate.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chris Savage
Parallax Engineering
Check out the new Savage Circuits TV!
·
Ok, I just did a test like you described and I definitely notice the difference. I guess I was expecting a stronger braking than I should have.
The thing I was noticing was that when I when I had reached my desired pulse count and stopped the motor, it was still going for another 50-200 pulses (which is ~ 6 to 24 degrees of the wheel). Obviously, this is because the motor can't stop instantly especially when the mass of the moving robot is factored in. I saw a lot less "overshooting" when I ran the motors at very slow speeds, so I know that if I change my code to ramp the speed down as I approach the desired pulse count I can more accurately hit my target distance (of course wheel slipping on the surface can't be accounted for here).
Thanks for putting up with my trial and error learning and being nice and helpful in replies.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Check out the Propeller Wiki·and contribute if you can.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chris Savage
Parallax Engineering
Check out the new Savage Circuits TV!
·
I also got a pair of the LynxMotion wheel encoders (QME-01). They really go on nicely and the MSR1 is laid out nicely to accommodate the little two-wire connectors on the three-pin headers (pic below).
Encoders are connected as follows:
Right wheel power & GND at pin 8, Left wheel power & GND at pin 10.
Right encoder outA to pin 8, Right encoder outB to pin 9, Left outB to pin 10 and Left outA to pin 11
(the A&B outs are reversed in sequence for the left wheel so that forward movement·generates positive numbers·for forward movement and negative numbers for reverse movements just as the right wheel does).
The LynxMotion QME-01 wheel encoders are connected and being read by the·'Quadrature_Encoder'··object.
'PWM_32_v2' object will be used to drive the motors, but this first version lets you turn the wheels
(gently)· by hand to observe and measure both the absolute (sum) of movements and the delta (change) from one reading to the next.
The Absolute and Delta reading are displayed every 2 seconds to the Parallax Serial Terminal using the·'Extended_FDSerial' object
This allows for some very accurate measurements. So far the following has been measured and·calculated:
1 wheel revolution = 12,000 transitions or 15.12" forward movement (both of my wheels·are outputting exactly the same counts)
That's exactly what the specs says it should be: 400 ppr with· 30:1 gearing.
Stingray turning diameter is 10.77" or
33.835" turning circumference or
2.2377 wheel turns or
26,853.2 transitions or
74.59 transitions per degree of turn
The turning figures have not yet been observed...More to follow. Attached is an Archive of what I have so far. I'm sooooo bummed! I have to be away for a few days and won't get a chance to play any more untill the middle of next week.
Duffer
Post Edited (Duffer) : 1/14/2010 11:50:54 PM GMT
I think you just set the standard for hooking up these encoders, I just switched.
Your numbers sound very close to mine except I've been working in metric and trying to stay with integer math.
I was just about to start playing around with that Quadrature encoder object so you made it easy for me.
I'll download your archive now and let you know what I get.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Check out the Propeller Wiki·and contribute if you can.