To All: I Need Your Help With A DIY Encoder Wheel Using PBasic 2.5 and BS2 Mic

simpsonmichael1

Good Evening All,


I need help with a DIY encoder system utilizing the bs2 micro-controller. Although, I saw kit encoders on the market, my robot is very large. My robot's rear wheels have a 6-inch diameter. I am using two scooter motors via chain drive. I have a simple light circuit using a flashlight and LDR connect the micro-controller. I'm using 2.5 PBASIC software to read in the input values, if true. However, when I try to code...it does not work well. See below.

desiredDX var word
count1 var word
Revcount1 var word



DO

Debug "Enter the distance desired", CR
DEBUGIN desiredDx

FOR count1 1 to 48

If (in3 = 1) then //sensor setup to provide a high on pin 3
count1 = count1 +1
Else
Debug "No input because no light on sensor", CR
Endif
Next

If (count1 > 47) then
RevCount1 = RevCount1 +1 //RevCount would be equal to a predetermined distance like if 100 this would be 20 feet. I
If (RevCount = 100) then
Stop

LOOP


However, even with no light the counter continues erratically or it counts when light is applied, but the RevCount always fails to work. I'm new to programing, so I need a bit of help. I am willing to learn. I find it difficult to do, but robotics is fun and rewarding.

I have read a few examples on counters, but want I really want to do is count the amount of times the spinning wheel (with holes in a CD disk) breaks the light path. If it breaks the light path x number of times, then I want to compare those values to a fixed distance. If the fixed distance is equal to my user desiredDX, then my robot will not move any further (in a straightline). If possible, does anyone know how to reuse an old computer mouse for an "encoder system" and how to write an example program for a bs2 micro-controller? Plead advise. Thank you.

Zoot

It's hard to gauge some of this w/o seeing a circuit, or your setup, however the problem with your code is that you are presuming the input is high and stays that way until you check it. Really what you are looking for is a *change* since the last time you checked it... that said, you still have the possible issue that the sensor is fast enough that it goes "high" and then "low" again (maybe even more than once) between the times it is checked (remember the Stamp is relatively slow). Certainly the DEBUG statements should be removed for testing -- DEBUG is painfully slow SEROUT will easily bloat fast loops that need to check sensors, write to servos, etc.

Second, you are using the for loop to count, then checking to see if the count is bigger. Doesn't work logically. You want to check the count inside the loop, then break out if it gets too high...

In any case, better code would be something like:

sensorIn PIN 3
led PIN 15 ' hook up an LED for "fast" debugging
desiredDX var word
count1 var word
Revcount1 var word
sensorFlag VAR Bit


Start:
LOW led
Debug "Enter the distance desired", CR
DEBUGIN DEC desiredDx  ' you need to convert ascii terminal input to a "number" here

RevCount1 = 0
count1 = 0
sensorFlag = sensorIn ' reset flag to match current state of sensor pin

Main:

  IF sensorIn <> sensorFlag THEN ' did the state of pin change since last we read it?
       sensorFlag = sensorIn  ' yes, set flag and...
       count1 = count1 +1  ' increment count
       led = 1
  ELSE
       led = 0
  ENDIF

   If (count1 > 47) then
      count1 = 0 ' reset 
      RevCount1 = RevCount1 +1  'RevCount would be equal to a predetermined distance like if 100 this would be 20 feet. I
      If (RevCount1 > desiredDx ) then
          DEBUG "Done"
          GOTO Start
      ENDIF
   ENDIF

   GOTO Main

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
When the going gets weird, the weird turn pro. -- HST

1uffakind.com/robots/povBitMapBuilder.php
1uffakind.com/robots/resistorLadder.php

Post Edited (Zoot) : 12/30/2008 11:51:21 PM GMT

Franklin

While you are at it please remove your other post. You can do that by clicking the red X in the upper right of the post. You can also edit your posts (to add a subject if you forgot one) by clicking on the pencil.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- Stephen

simpsonmichael1

Good Evening Zoot,

Thank you for that really fast response. I will try your method. Your inputs are great. I have a large mountain to climb before I can really appreciate robotics, but at least I have a good start with like-minded folks. Thank you.

Mike Simpson

FerretMK4

I'd like to expand a bit on the subject of capturing short-time analog events with a digital sampling system.· It's a very common problem in industrial data acquisition.· The analog event in which the light is sensed on and off is easily thought of as a digital event and it is easily used to increment a counter.· However when you use a digital sampling system, that is one in which the system has a short time window to look for the event, you should look at the counter's output and not try to look at the event itself.· A digital system that has a sampling frequency of say 10Hz may only look at this event channel for a few micro or milliseconds and if something isn't happening during that time the system won't see it at all. ·The event could have come and gone between sample windows and would never be seen, or if the event happens slowly it might be "visible" for two or more looks and you'd never know if you were looking at the same event or multiple events that just happened to occur on successive looks.· ·This latter problem occurs when the sampling frequency matches the event frequency: you see either all event low or all event high.· If you're using the data to calculate distance or speed, you'll get a zero result because the data system never sees a change.· Likewise you'll get other less obvious errors when the event frequency is a multiple or fraction of the sampling frequency.· Essentially you'd be lucky to get good data at all.· This is a difficult problem to avoid when the sampling frequency is fixed but the event frequency varies over a·range.· When you use an optical encoder the physical width of the window is fixed so as the rotational speed changes the length of time that the light is on varies with the speed and will affect whether the event is seen by the sampling system.

If you have a sample rate that's·higher than the event·frequency you can use something like a flip-flop that holds the event logic value (high or low) for at least one sample interval to be sure that the event is seen.· However your program has to count only changes in value and not the number of samples which have the high or low value because multiple samples will see the same event.· This could be done with a logic loop involving setting a flag that indicates the status of the last sample and checking it against the current value to see if there is a change.· Be careful that your event frequency and sample frequency are substantially different to avoid missing a count.

However if your system records the counter output data lines, it will capture all the events even if multiple events occur between sample windows.· This is the most fool-proof way to record events.· If you're trying to calculate velocity from a wheel trigger you will have to be wary of the "divide by zero" or "divide by a small number" problems if your sample rate is higher than the wheel trigger rate.· If you want good resolution of wheel position (ie distance travelled) the opposite is true: you need a high sample rate.· These two requirements are incompatible so you have to design to suit your desired result.

The only catch I know of is that you have to check the counter valid data line to be sure you don't record the counter·output while it's changing its count because the output data will be bogus at that moment.· If your program can't wait for·valid data to be present at the counter output, you have to find a way to deal with the lack of data for that sample, by filling in a duplicate of the previous value or a zero or something.· In the case of measuring distance that the robot has moved, I would assume that the sample rate is fast enough that you would be checking the count multiple times per wheel trigger event so if you missed it just as the count changed you would be no worse off than if it checked the count just after the count changed (at which point the count is valid).· The resolution of distance will be the distance travelled between wheel triggers: one circumference if there is one trigger per revolution, half if two triggers, a third if three, etc.· This is the maximum distance error assuming that the system is sampling fast enough to catch all events.· ·If your robot is moving on several paths, the error in each leg of the trip will add to the previous error and the total can be much larger than you·originally expected. ·The faster you sample, the sooner your system will know that the trigger has occurred so your accuracy in knowing where to stop will improve and will be much better than the resolution that the physical trigger sets; the accuracy is related to sample time and vehicle speed (faster sample and slower speed·yields best accuracy).· Your system will never know exactly when the trigger occurred however.· Its first knowledge of the event occurs at the first sample after it has occurred.· In data acquisition applications where this timing is an issue, such as overlaying data taken on successive revolutions of a shaft, there will be some jitter in the data due to the fact that the event timing error won't be consistent from revolution to revolution.· Hence there is a need to sample at much higher rates than would be needed just to detect the event, in order to reduce the jitter and the·many problems it causes in analysis.· There's a difference between knowing THAT an event has occurred, and knowing WHEN it occurred.

erco

simpsonmichael1:·We have an encoder project unfolding in the Robotics forum to add two encoders to a Scribbler robot for odometry. You might want to peek at some of the info there, but we are using photoreflective sensors, which is much different from your flashlight/photocell application.

Kwinn had a valid point in your duplicate post about spurious signals in your application.·Another robot of mine has a single drive wheel with encoder holes in it, and I·rolled my own encoder·using a "shack" IR LED and phototransistor.·It's simple and FAST, but I had to play a few games to get it to work reliably.·The phototransistor voltage-divider output is an analog signal that vascillates between 0.5 volts and 2-ish volts. I simply feed·that into a Stamp input pin. Anything above 1.3 volts reads high (11111), anything below 1.3 volts reads low (00000). But in the transition,·there is always some noise (00001010101111) which messes up any pulse counting in progress. In order to get perfect results, I·used two different techniques; one hardware and one software. Hardware-wise,·I inserted a Schmidt trigger between the ptx and the Stamp, which adds some hysteresis to the system and filters out noise. Software wise, I ran a sample loop which tests for three consecutive zeroes or three consecutive ones before incrementing the counter loop. Both techiques worked equally well, so I would encourage you to try adding such·a verification routine to your software on your robot.

You might consider switching to IR LEDs & phototransistors. Flashlight bulbs can burn out, while LEDs are bullet-proof. And using photocells·(LDRs)with·the RCtime and IF-THEN checks yield fairly slow results. Phototransistors have much faster response time than photocells and the RCtime can take a long time time to execute, depending on your RC values. It obviously takes longer to execute with a high resistance condition (dark LDR) than a low resistance condition (light falls on LDR).· Going semiconductor has both speed and durability advantages.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
·"If you build it, they will come."

Post Edited (erco) : 1/5/2009 6:11:18 AM GMT

FerretMK4

Also, matched IR source / sensor pairs are far more immune to stray light that can give false triggers. Direct sunlight is a problem regardless but reflected and ambient light are not such an issue.
Flip-flops and Schmidt triggers are similar and once triggered they have to be firmly reset; ie they have large hysteresis. They shouldn't give false switching if you use an optical trigger (a lot of the optical IR sensors have Darlington transistors in them which also switch very quickly and positively). Most counters I've run into have a lot of hysteresis at the input so unless the input is very noisy they shouldn't give false counts.
Reflective optical sensors work fine, but are not as position-accurate as an optical shutter. They are more tolerant of misalignment. Alignment and timing characteristics vary with the reflective quality of the reflector: more spectral reflectors have a wider viewing angle and more timing scatter while mirrors require good alignment but give more accurate timing. For robots and at the speed the Stamp samples, timing isn't a limiting factor. Reflective bumper sticker material makes a good target, and there are special reflective tapes available. Even white and flat black paint works but the signal level change between them is less than with a real reflector.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Someone PLEASE un-subscribe me!!!

$WMc%

Hello All

I see this time and time again with IR sensors. They are not reliable for a wheel encoder. What is a whole lot better is a Hall Effect sensor with a Flying magnet.But don't take My word for it. Look up what the Hi-Perf. Ing. company's use for the NASCAR guys.Here We are talking about $Millions$
of Dollars At stake. And do You think Their using IR? I thank Not. Look up "MSD,Mallary,Crane,Etc.". They All use a flying magnet and a Hall Effect sensor.

Parallax offers a Hall Sensor the MLX90217, Its vary small and is easy to use.

________________$WMc%________________

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
The Truth is out there·········································· E=$WMc%2

FerretMK4

Magnetic (Hall Effect) sensors are great in a dirty environment where IR sensors soon fail so they are preferred in racing.· There are some very nice versions that include Darlington switching to sharpen their response which is otherwise a relatively sloppy sine wave cycle.· · However, the amplitude of the output of a Hall Effect sensor is a function of the rate of change of the magnetic field so there is a minimum speed at which they will work.· If you want to detect the motion of a robot wheel that may be rotating at only 1 rpm, a Hall Effect sensor won't work: you need an optical trigger which will work even if the event occurs only once a year.
Hall Effect sensors are also cheaper and easier to implement.·

Phil Pilgrim (PhiPi)

One thing that helps to make IR interference-resistant is to modulate it and use signal-processing in the detection circuitry to discriminate against constant (e.g. sunlight) and low-frequency (e.g. 60/120Hz) interference. The sensor used in the Boe-Bot Digital Encoder Kit, for example, does this transparently and, as a result, is very resistant to ambient lighting effects.

-Phil

erco

I'll stick with proper optical wheel encoders based on my own experiences with homebuilt robots. Millions of happy users can't be wrong. Plenty of proven applications where they work perfectly for wheel encoders. Besides, I don't want to mount 32 critically-spaced magnets on a wheel for a Hall-effect sensor. Much simpler, faster, and more accurate to print an existing encoder disk pattern and mount it on a wheel. And there are dedicated, sophisticated sensors as cheap as $2 with onboard filtering & signal conditioning. As zoot pointed out, if there's a sampling problem, it is more likely in the software than in a properly-installed optical sensor.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
·"If you build it, they will come."

pwillard

In the case of Dirty Environments and shaft speed determination... I can see where Hall Effect is the right choice.

In the OP's case though, I would opt for methods used with IR remotes. Modulated Transmit Signal with discriminators on the receiving side to cancel out random light reflections and such.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔


There's nothing like a new idea and a warm soldering iron.