HB-25, BS2, and Encoder
Bill Chennault
Posts: 1,198
All--
While testing a setup involving the following . . .
OEM-BS2
HB-25
Banebot gearmotor with encoder
. . . I discovered something very peculiar (at least to me). The published count on the Banebot installed and calibrated encoder is 128 CPR. However, there seems to be no correlation between the count and reality other than multiple motors appear to have the same problem. When I tell the HB-25 to, say, drive the gearmotor at "780" until the encoder reports 128 counts, I expect the shaft to rotate slowly, one time. In reality, it rotates slowly about 1/4th of a revolution.
Well, I figured I was using a gearmotor with a bad encoder, so I switched to the other one and got about the same results. When I increase the PWM duty-cycle the gearmotor turns faster, as you would expect, but also goes much further than you would expect; even far further than shutting it off instead of ramping it down might lead you to believe.
I am counting encoder pulses from the gearmotor with an input pin on the BS2.
Do you have any ideas concerning this problem?
Thanks!
--Bill
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
You are what you write.
While testing a setup involving the following . . .
OEM-BS2
HB-25
Banebot gearmotor with encoder
. . . I discovered something very peculiar (at least to me). The published count on the Banebot installed and calibrated encoder is 128 CPR. However, there seems to be no correlation between the count and reality other than multiple motors appear to have the same problem. When I tell the HB-25 to, say, drive the gearmotor at "780" until the encoder reports 128 counts, I expect the shaft to rotate slowly, one time. In reality, it rotates slowly about 1/4th of a revolution.
Well, I figured I was using a gearmotor with a bad encoder, so I switched to the other one and got about the same results. When I increase the PWM duty-cycle the gearmotor turns faster, as you would expect, but also goes much further than you would expect; even far further than shutting it off instead of ramping it down might lead you to believe.
I am counting encoder pulses from the gearmotor with an input pin on the BS2.
Do you have any ideas concerning this problem?
Thanks!
--Bill
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
You are what you write.
Comments
How are the encoders connected/configured (active-high/low, wiring)? How in the software are you counting pulses?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chris Savage
Parallax Tech Support
Are the encoders before or after the gearing. That can make a HUGE difference in what COUNT reports.
Regards,
Bruce Bates
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"Genius is one percent inspiration and ninety-nine percent perspiration."
Thomas Alva Edison
Remember that I am a newbie and will doubtless answer your questions in that manner. Forgive me.
Chris, I simplified my setup on a different machine I am building. Basically, it is a 90* transmission driven by a·gearmotor driven by an HB-25 driven by a BS2. There is one encoder, factory installed on the armature AFTER the gearing. I have no clue as to whether the encoder is active low or active high. If a resistor is involved, then there isn't one and I suppose the encoder input pin "floats." (?) I am counting pulses by simply saving the state of the last pulse and comparing it to the next. If they are different, I add 1 to a counter. (The results from this configuration are identical to my previous configuration using two HB-25s, two gearmotors/encoders and two BS2s.) Even at this low speed (800 and 700) could inertia be a factor when all that is turning is the gearmotor, two 3/4" bevel gears, and a 3/8", 6" shaft? (Dumb question?)
Forward and reverse work fine. If I add debug statements, the Stamp detects the proper number of encoder counts. The code uses the maximum encoder count to cause the gearmotor to reverse. It works, it just does not work accurately. As you can see, I am turning very slow and very little. If I increase the duty cycle on the HB-25, then the gearmotor speeds up and turns even more than non-ramping should cause. However, I am about to blame that on inertia, as well.
Bruce, the encoders are BEFORE the gearing and the only thing I look at is the shaft on which the encoders are installed (by the factory). I perform counts as outlined above. SHOULD I use the COUNT command?
Here is what the code looks like . . .
'
[noparse][[/noparse] Compiler Directives ]
' {$STAMP BS2}
' {$PBASIC 2.5}
'
[noparse][[/noparse] Program Name ]
' Transmission Demo.bs2
'
[noparse][[/noparse] Program Description ]
'
[noparse][[/noparse] I/O Definitions ]
Channel_A········· PIN····· 15·········· ' This pin looks at channel A of the encoder
HB25·············· PIN····· 14·········· ' This pin controls the HB-25
'
[noparse][[/noparse] Constants ]
·
'
[noparse][[/noparse] Variables ]
oldValue········· ·VAR····· Bit
Distance·········· VAR····· Word
Left_Count········ VAR····· Word
'
[noparse][[/noparse] Initialization ]
Distance = 128
' Wait for left HB-25 to power up . . .
DO : LOOP UNTIL HB25 = 1
LOW HB25··· ·····························' Make I/O Pins Output/Low
PAUSE 20································ ' Wait For HB-25s To Initialize
PULSOUT HB25, 750······················· ' Stop the motor
PAUSE 20
'
[noparse][[/noparse] Program Code ]
·
oldValue = Channel_A
·
Main:
· PULSOUT HB25, 800
· PAUSE 20
· Left_Count = 0
· DO
··· INPUT Channel_A
··· IF oldValue <> Channel_A THEN
····· Left_Count = Left_Count + 1
··· ENDIF
· LOOP WHILE Left_Count < 128
·
·
' Pause a bit . . .
· PULSOUT HB25, 750
· PAUSE 500
·
·
· PULSOUT HB25, 700
· PAUSE 20
· Left_Count = 0
· DO
··· INPUT Channel_A
··· IF oldValue <> Channel_A THEN
····· Left_Count = Left_Count + 1
··· ENDIF
· LOOP WHILE Left_Count < 128
· PULSOUT HB25, 750
· PAUSE 500
·
· GOTO Main
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
You are what you write.
Further, when the HB-25 receives "800" and "700" and counts 128 pulses from the encoder, it only turns about 40 or 45 degrees. When the HB-25 receives "900" and "600" and counts 128 pulses from the encoder, it turns a little more than a full revolution.
I am doing something fundamentally wrong.
When I replace the BS2 with a BS2px24 and change the directive to {$STAMP BS2px} it will recognize the Stamp, compile, and download but do absolutely nothing. (I make sure I start the Stamp before I start the HB-25.)
--Bill
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
You are what you write.
What's with this "Channel A" business? Is this a QUADRATURE encoder?
If so, here is some applications material you will probably find helpful, from Dr. Tracy Allen's web site: http://www.emesystems.com/BS2fsm.htm#twobit
Regards,
Bruce Bates
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"Genius is one percent inspiration and ninety-nine percent perspiration."
Thomas Alva Edison
Yes. It is a quadrature encoder. I thought I could use one side of it to count in one direction. I will read the material at the link you gave me.
Thanks!
--Bill
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
You are what you write.
I read the material on Dr. Allen's site. Obviously, he is a true expert. However, in reality, his code works no better than mine. It does alert the user to direction change, but it counts no better as far as I can tell. (I implemented his code EXACTLY as presented on the site.)
There MUST be something FUNDAMENTAL that I do not understand about encoders.
Both Dr. Allen's code and my code move the motor in the direction first started a bit more than the opposite direction. This prevents the end effector--in my case, two axles--from returning to their origin. At very slow speeds, both Dr. Allen's code and my code move the axles about 90* and indicate a full 128 counts, which should be a complete revolution, not a quarter of a revolution. (Since neither set of code will return the axle to its starting point, just saying that I somehow have a 512 CPR encoder doesn't help, either! <g> )
Chris, you asked if the encoders were connected active high or active low. I am not clear on this point, although I know it is a fundamental electronics question. Would you please give me an example for dummies?
In reality, as it stands right now, the 16 CPR optical encoders I built over 30 years ago with a hand drill worked better. I know the problem must have a simple solution. I know the problem is my lack of understanding. I just do not know where to fix it.
And, I must mention that NEITHER piece of code will do ANYTHING if I replace the BS2 with a BS2px24 and change the directive, accordingly. This should be a big hint . . . to someone.
Thanks.
--Bill
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
You are what you write.
The pull-ups was what I was getting at…Many encoders have them/require them. Without them you can get erratic results. Of course a Quadrature encoder connected properly takes a lot of overhead and probably will be too fast for a BASIC Stamp to keep up with.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chris Savage
Parallax Tech Support
I am about at my wit's end on this deal. ALL the BS2 is doing is watching this quadrature encoder. Taking the DEBUG statement out shortens the rotation, as one might guess since it communicates at 9600 baud.
I am using conditional compilation. The ONLY processor that will cause ANY reaction from the HB-25 is a BS2, with or without conditional compilation. (I have a lot of BS2s. I am currently testing with a BS2 on one of my PDBs. However, I have done the same thing with four other OEM BS2s on a breadboard.) No matter what I do, neither a BS2px24 or BS2p40 will control or affect my HB-25s . . . any of them, I have a bunch. Of course, when I use the faster processor, conditional compilation takes care of timing for me. (I am using Parallax's example. Is there a bug in it?) Here it is . . .
#SELECT $STAMP
· #CASE BS2, BS2E, BS2PE
··· TmAdj······ CON···· $100··········· ' x 1.0 (time adjust)
· #CASE BS2SX
··· TmAdj······ CON···· $280··········· ' x 2.5
· #CASE BS2P
··· TmAdj······ CON···· $3C5··········· ' x 3.77
· #CASE BS2PX
··· TmAdj······ CON···· $607··········· ' x 6.03
#ENDSELECT
I could rig up a simple encoder, which I THOUGHT I had done by using a single channel of the quadrature encoder. Just knowing how many holes have passed is enough for me. I already know what direction I am going. I am developing a potential product and really want to use the HB-25 with the SX/B environment. I wonder if the 20 MIP SX is fast enough? About all it will be doing is watching the encoder, also.
--Bill
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
You are what you write.
For keeping track of the encoder counts you may want to consider the SX processors. I'm using one for a project that has to watch an encoder and so far it has been working out great. It uses some of the Interrupt driven serial receive/transmit code that JonnyMac had posted on the SX group. I added some code in there to watch the encoder so it checks for and updates much faster than the encoder values can ever change. (At least for the project i'm using that with.)
Interesting things happen when you are polling the encoder to see if it changes. It's fine as long as the encoder is moving slower than your polling interval. Once you exceed that some bizarre things happen. If you read SERVO there is an article that is supposed to be in the next months issue that talks about a very similar problem.
Robert
I suppose you have read this entire thread. I am experimenting with these encoders preparatory to building stuff with your SX modules. So far, my code works, but only on a BS2 and not incredibly accurately.
I cannot figure out why my code will not run on a BS2px24 or a BS2p40. I've used the conditional compilation that produces a constant by which the standard pulses can then be multiplied. Zip. Nada. Nugatory. And, I am not talking about the encoder! I am talking about just getting the HB-25 to operate! That SHOULD work.
I hope the problem does not lie within the HB-25. Have you (or anyone else) ever gotten an HB-25 to work on ANY Stamp other than a BS2?
Thanks!
--Bill
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
You are what you write.
I sounds like there are two separate issues here. One is controlling the HB-25 (at least getting the pulses to it) and the other is reading your encoder to check for movement. I've never used an HB-25 but have read a little bit on how they operate. If you want to see if you are getting your pulses out correctly to them one thing you might want to try is just use a regular servo as something else to test with. Either a standard or continuous rotation servo would work as you just want to see it move when told to by your stamp. It's just another way to test. If it works with the SERVO then it should work with the HB-25. Now, from what I understand you don't need to send out the pulses nearly that often to the HB-25 so if that is what you are testing then the sero trick won't work.
What exactly are you using for your encoders? Do you have a part # for the optical sensor portion? Is it just a standard slotted I/R LED/photodiode?
If you are connecting the photosensor directly to the stamp that may be part of the issues you are having with the encoder. On many encoders used in personal robots over the years i've seen some sort of chip between the photo sensor and your micro controller. Usually something like a 74HC14 Hex Schmitt trigger inverter (one inverter for each channel) does the job. The 4 inverters not being used should have their input tied to ground. It helps ensure a nice transition from low/high, etc when the encoder turns.
Just some things to think about.
Robert
As, I've mentioned, my BS2 code works fine . . . sort of. [noparse]:)[/noparse]
I have written a program using trial and error (binary hashing) to figure out what the BS2px24 likes for PULSOUT. It SEEMS that decimal 978 will turn it on (fast) every time and that decimal 1805 will stop it every time. As you approach decimal 1805, the HB-25 causes the motor to turn slower and slower, so there is doubtless a lot in that range I need to discover.
So far, I don't know how to cause the HB-25 to reverse the motor . . . something greater than 1805, perhaps? That will be my next test.
I bet the REAL problem is that I simply do not know how to properly use the conditional compilation tables that adjust for different Stamps.
The quadrature encoder is installed at the factory. Techs at the factory told me to simply hook it to an input pin without a resistor. I did. It worked. Later, I stuck a 470 ohm resistor in. Still worked.
Thank you, as always for your thoughts.
--Bill
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
You are what you write.
The good news is that the conditional compilation tables you refer to really have nothing to do with your current issue. If these are, in fact, quadrature encoders then the BASIC Stamp may simply be too slow to read them. This is, of course, assuming they’re connected as intended, which is the AB outputs would be read as 2 bits. Below is some code for reading such an encoder and increment/decrementing a variable. Note that, even without the DEBUG section, the speed of rotation is severely limited and gets worse and the ppr increases. In other words, higher ppr/ppm encoders have to turn even slower for the BASIC Stamp to keep up. You may need to use an SX as a co-processor. I hope this helps. Take care.
Main: DO newBits = INA & %0011 ' Get State Of I/O Pins 0, 1 IF newBits <> oldBits THEN ' Have Bits Changed? counter = counter - 1 + (2 * (newBits.BIT0 ^ oldBits.BIT1)) DEBUG HOME, DEC3 counter ' Show New Counter On DEBUG Screen oldBits = newBits ' Update oldBits ENDIF LOOP STOP▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chris Savage
Parallax Tech Support
This entire experience has been very educational!
I finally got something other than a BS2 to drive the HB-25. I am now experimenting with a BS2px24. Here is what I have discovered so far . . .
Decimal 1805 shuts the HB-25 down and does not allow for motor/gear-train inertia. When PULSOUT HB25, 1805 is executed, whatever you are driving stops immediately.
Decimal range 1804 to 1200 causes the HB-25 to drive a motor faster and faster until the limit of 1200 is reached.
Decimal range (this one is still rough) 3600 to 4500 causes the HB-25 to reverse the direction and drive the motor faster and faster until the limit of 4500 is reached.
All of this is rough. Perhaps, you could shed some light on it for all of us . . . or just tell me what I am doing wrong with EVERYTHING except the BS2!
Thank you for the code. I will play with it!
--Bill
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
You are what you write.
Gee. I wonder if my success getting the BS2 to correctly count the quadrature encoder pulses (I think I have) is due to SEMANTICS???
To me, "fast" is 125 rpm. Of course, I operate at no where even CLOSE to that . . . more like 10 rpm. Ten rpm is probably even too fast for a walker joint, which is my next project.
Ugly Buster's tracks·would literally rip the carpet at 125 rpm!!! [noparse]:)[/noparse]
--Bill
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
You are what you write.
Okay, so with the BS2px24 timing does come back into the picture. The fact is that the BS2px24 uses different timing durations than the BS2. The range of 500 to 1000 for PULSOUT on the BS2 translates to a range of 1250 to 2500 on the BS2px. Hopefully everyone will benefit from what I am about to say, since there seems to be a lot of misunderstanding in calculating the proper values for PULSOUT between the various models of BASIC Stamp.
When doing a calculation it often helps to look at everything in the same units. In this case servos are usually listed as 1ms to 2ms and the BASIC Stamp PULSOUT durations are listed in microseconds. What helps is to convert everything to microseconds. In this case 1ms is 1000us. 2ms is 2000us. Given that, it’s easy to see how using the BS2 2us durations you get a range of 5000 to 1000…
1000us / 2us = 500
1500us / 2us = 750
2000us / 2 us = 1000
On the BS2px the units are .8us instead so 2us so…
1000us / .8us = 1250
1500us / .8us = 1875
2000us / .8us = 2500
Hopefully this will make it clearer how to simply use the correct range of values without needing the conditional compilation code. In my own opinion conditional compilation is nice when you want to make a program easily compatible with multiple BASIC Stamp models. However when developing code for some it clouds the issue as it’s not always clear what is being compiled. Often it helps to simply know how these things work and use what you need. You can always change constants later if need be. I hope this helps. Take care.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chris Savage
Parallax Tech Support
Gee. I can't believe I might have actually HELPED. [noparse]:)[/noparse]
Thank you for taking time to write that detailed post. I printed it.
--Bill
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
You are what you write.
The BS2px24 is ALMOST working fine with half the quadrature encoder. I have narrowed the problem down by simply ELIMINATING the encoder altogether. In the forward direction, 1875 performs a hard stop. In the reverse direction, 1875 allows the motor to freewheel to a stop. Here is the VERY SIMPLE code . . .
' Notes: The HB-25 control ranges specific to the BS2px were taken from a posting by
' Chris Savage on the Parallax robotics forum . . .
' Full reverse: 1250
' Stop: 1875
' Full forward: 2500
'
[noparse][[/noparse] I/O Definitions ]
HB25····· PIN··········· 15········ ' Dedicated HB-25 output control pin
'
[noparse][[/noparse] Initialization ]
' Wait for left HB-25 to power up . . .
DO : LOOP UNTIL HB25 = 1
LOW HB25······························· ' Make I/O Pins Output/Low
PAUSE 20······························· ' Wait For HB-25s To Initialize
PULSOUT HB25, 1875····················· ' Stop the motor
PAUSE 20
'
[noparse][[/noparse] Program Code ]
DO
· PULSOUT HB25, 1250 ' this code performs a hard stop
· PAUSE 20
· PAUSE 2000
· PULSOUT HB25, 1875 ' pause 2 seconds
· PAUSE 20
· PAUSE 2000
· PULSOUT HB25, 2500 ' this code freewheels to a stop
· PAUSE 20
· PAUSE 2000
· PULSOUT HB25, 1875 ' pause 2 seconds
· PAUSE 20
· PAUSE 2000
LOOP
What might I be doing wrong?
Thanks.
--Bill; new owner of an SX Controller Board with the USB connector!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
You are what you write.
'{$STAMP BS2px} ' {$PORT COM1} ' {$PBASIC 2.5} HB25 PIN 15 ' I/O Pin For HB-25 index VAR Word ' Counter For Ramping ' -----[noparse][[/noparse] Initialization ]-------------------------------------------------- DO : LOOP UNTIL HB25 = 1 ' Wait For HB-25 Power Up LOW HB25 ' Make I/O Pin Output/Low PAUSE 5 ' Wait For HB-25 To Initialize PULSOUT HB25, 1875 ' Stop Motor 1 ' -----[noparse][[/noparse] Program Code ]---------------------------------------------------- Main: PAUSE 20 ' Wait 20 mS Before Ramping FOR index = 0 TO 625 ' Ramp Up To Full Speed PULSOUT HB25, 1875 + index ' Motor 1 Forward PAUSE 20 ' 20 mS Smoothing Delay NEXT PAUSE 3000 ' Wait 3 Seconds FOR index = 625 TO 0 ' Ramp Back Down PULSOUT HB25, 1875 + index ' Motor 1 Forward Slowing PAUSE 20 ' 20 mS Smoothing Delay NEXT PAUSE 3000 FOR index = 0 TO 625 ' Ramp Up To Full Speed PULSOUT HB25, 1875 - index ' Motor 1 Reverse PAUSE 20 ' 20 mS Smoothing Delay NEXT PAUSE 3000 ' Wait 3 Seconds FOR index = 625 TO 0 ' Ramp Back Down PULSOUT HB25, 1875 - index ' Motor 1 Reverse Slowing PAUSE 20 ' 20 mS Smoothing Delay NEXT STOP ' Use STOP To Prevent State ChangeThank you for the code. I will definitely experiment with it!
It may be that my EXPECTATIONS for the HB-25 are incorrect. I EXPECTED to be able to give it a PULSOUT number and then stop it after n seconds and then do the same thing again have it repeat the action precisely.
One of my very important goals for a motor controller is to be able to have it cause the motor or end effector to move about from 0 to 90* in a fairly precise fashion. The HB-25 will not do that. Additionally, if you change the speed sent to the HB-25, the duration numbers must change, as well. For example, sending the HB-25 a speed of x with a duration of y (either via PAUSE or some other mechanism) causes the HB-25 to command the motor to move either more or less instead of precisely the same. This is particularly apparent when you try to move the a motor armature via HB-25 a certain number of degrees and then back the same number of degrees. It simply will not happen.
The only thing I can think of is to use the HB-25 at a single speed and TRY to program a hard stop in that actually causes the HB-25 to reverse the motor for the minimum amount of time necessary to stop it, then send the HB-25 the "stop" or "neutral" command.
I own several HB-25s and am disappointed in my understanding of both the documentation and the advertising of the product.
Of course, there is always the possibility that someone will tell me that I am doing something very stupid--it's happened many times before--and the HB-25 will once again become my dream motor controller.
One can only hope.
--Bill
ps Note to Parallax: Maybe the HB-25 could have TWO command sets. The first would do as it does now and the second would control a motor in a far more precise fashion.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
You are what you write.
I can understand your frustration, but what you want to accomplish here is not easy. The hb25 is doing what is supposed to, move the motor in a certain direction at a certain speed, and stop it. You want a servo positional operation that needs " positional feedback " to determine where the motor shaft is at any given time. Perhaps you are confused with the hobby servo that does have positional feedback from a variable resistor, but limits its' rotational range because of that mechanism. The encoders on the motor you have will do what you want, to read the position of the motor shaft, by counting pulses during the rotation. The motor ramping can still be done, you would just be looking for a positional value, slightly less than the desired end position value, to start the ramp down while still reading the encoder position. I have used a grayhill 256 cpr with a bsp24 at a fair rpm while doing some other routines, and have had good results for positioning. At the rpm you are looking at, it should not be a problem. Also, from prior advice taken here from the pros, go a simple step at a time, it makes things a lot easier. Everyone tends to want everything working at once, it just makes it harder to isolate a problem to fix.
You may find the following brief descriptions of various motor types an interesting and informative read (link below). There are more detailed explainations of the different types elsewhere on the Internet. Here is the link: http://www.arrickrobotics.com/motors.html .
Now that I realize you are looking for PRECISION control, I would have advised against an R/C servo solution. You would be much better off using a stepper motor with a shaft encoder. That will probably give you more precision than you will ever need. Ramping and multiple speed modes are both possible, and easily accomplished through the use of a stepper motor control (driver) chip. Here is a link to a stepper motor tutorial from which many folks have become adept at using stepper motors: http://www.cs.uiowa.edu/~jones/step/
The real problem here is not with the HB-25 itself, but rather with the choice of motor type. Please understand that R/C servos were developed for, and intended for use in R/C (radio controlled) models. The goal there is to use a motor that provides an integrated solution, is light weight, can perform repetitive action, uses as little current as possible, is small in size, and has a reasonable cost. Exact repeatability is not necessarily one of the goals, nor is the ability to ramp the speed up and down, nor to provide exact positioning.
Regards,
Bruce Bates
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"Genius is one percent inspiration and ninety-nine percent perspiration."
Thomas Alva Edison
You are doubtless correct. I am used to ramping up and down with Ugly Buster, but have not been doing so with this 90* transmission because I turn it at something like 5 rpm. That's a guess: My working speed for it is almost the slowest speed the HB-25 will cause the gearmotor to turn. Plus, since its intended application is as a knee or elbow joint, I never turn it more than 90*. In practice, it will probably never turn more than 75*.
Additionally, it is a prototype. I have decided that I MIGHT make a second one like it so I can build something with which I can experiment with walking. However, I believe the next prototype will use a worm and a worm gear. That combination should help quite a bit, even though there will still be inertia in the armature turning the worm gear after power is off. Still, it should be an easier task for me in every way except $$$! (Worms ain't cheap.)
Thanks for the encouragement! [noparse]:)[/noparse]
--Bill
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
You are what you write.
Through this period of experimentation I have learned that an HB-25 is not going to control a motor precisely. However, if additional precision is necessary--in my case, it is--then some consideration to timing the HB-25 a little differently and perhaps stopping every once in a while and figuring out where the end effectors REALLY are, then using that to "re-zero" the software, the HB-25 can be used.
I also found out that using half of a 128 count per revolution quadrature encoder turns it into a 256 count per revolution encoder. This surprised me, as I thought it would be the other way around. In any case, my walker only needs to count up to about 90 at the absolute most. The motor rpm ranges are very, very slow, as well. Although I am currently using a BS2px24, I will switch to a BS2 just to see if that 4 KIPS device will handle my walker joint needs.
--Bill
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
You are what you write.
Given all that I've learned in this thread and all the qualifications I've outlined above, the BS2 is more than adequate to handle the walker gearmotor and encoder. (Remember, I am using half the quadrature encoder.)
--Bill
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
You are what you write.
I found a few minutes to look at your code back a ways and while it’s not the way I would handle things, there is an inherent issue with the code. For starters you’re not resetting the value of oldValue after comparing it to Channel_A. I’ve never seen anyone configure a quadrature encoder the way you did, so I don’t know how well it would work, but in order to compare states you need to know the previous state. In your case that is never changing, unless I missed something.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chris Savage
Parallax Tech Support
Re: Not resetting oldValue to Channel_A.
Gee. I hate it when that happens.
The latter version that DOES work--even with the BS2--has that oldValue bug fixed. (I found and fixed the bug you found . . . it was a stupido bug.) That is the reason the latest version works, even on the BS2. (Remember my incredibly slow RPM requirement.)
I debugged students' and my programmers' code for 30 years and was known as one of the best in the business, but I ALWAYS needed someone to debug mine! It is the hazard of the game and it has not changed.
By the way, the reason I am handling the quadrature encoder differently than anyone you may have seen do so is because I know nothing about them. I am using only a single channel, which magically transforms it from a 128 CPR device to a 256 CPR device. Looks like it would be the other way around, but it is working to my satisfaction, plus I have a far better understanding of the most-excellent HB-25 and what it was designed to do. (Put a BRAKE command in the next version! <g> ) I use the HB-25 to move the transmission shaft from 15* to 75*. If it were ever to make a full revolution, there would be BIG problems! [noparse]:)[/noparse]
I REALLY appreciate all the time you and everyone else spent helping me with this issue. Now, it is back to the mill to build the foreleg, or forearm if I turn it upside down!
--Bill
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
You are what you write.