Hall Effect Sensor.

[Nixterrimus]

The 2005 kit came with something a Hall Effect Sensor, after a bit of looking I found the manual for it, it's actually a ATS665LSG made by Allegro Microsystems. Allegro desribes it as a True Zero Speed, High Accuracy, Gear Tooth Sensor. What does that mean? Is this the "gyro" for this year? And does this work in congunction with the accelerometer. There are two of Hall Effect sensors so it seems we need to use them in twos. Also the Allegro manual mentions gears and gear tooth length. So I'm a bit confused and a bit curious and maybe even a bit excited. Anybody know anything about the Hall effect?

[Stu Bloom]

My GUESS is that you would use these to count gear teeth - used for feedback to determine how fast/far your robot moves, or for sensing the motion of anything else using chain/sprocket. However ours were missing when we did our kit inventory ...

[scottm87]

The 2005 kit came with something a Hall Effect Sensor, after a bit of looking I found the manual for it, it's actually a ATS665LSG made by Allegro Microsystems. Allegro desribes it as a True Zero Speed, High Accuracy, Gear Tooth Sensor. What does that mean? Is this the "gyro" for this year? And does this work in congunction with the accelerometer. There are two of Hall Effect sensors so it seems we need to use them in twos. Also the Allegro manual mentions gears and gear tooth length. So I'm a bit confused and a bit curious and maybe even a bit excited. Anybody know anything about the Hall effect?

Okay. A gear-tooth sensor sits in your gearbox and uses a magnetic field in order to sense each specific tooth go by. The Hall Effect is the concept that allows the integrated circuit to take a measurement of the magnetic field surrounding it. (Hall effect compasses are also popular) The amount of time that elapses between the each tooth gives the speed of the rotating gear, which can then be scaled to the speed of the wheel, etc.

This is not a gyro. A gyro returns your angular acceleration (NOT your angular heading... you would need to integrate the acceleration to get that)

[sanddrag]

However ours were missing when we did our kit inventory ...Check the Accelerometer bag. They are very tiny things and many teams have found them stuck to the accelerometer so they look like part of it.

[Joe Ross]

Nixterrimus, Is Ken Wittlief still on your team? He should be able to explain the sensors and demonstrate their usage.

[Tom Bottiglieri]

This is a neat article I found on calculating heading with a rate gyro.

http://www.seattlerobotics.org/encoder/200311/brown/building_a_directional_gyro.html

Not sure if FIRST provides us with this code though, I'll have to dig deeper into the documentation and report back.

[EDIT] I found this article from a Hall Effect sensor manufacturer about how they work. http://www.micronas.com/products/overview/sensors/index.php [/DIT]

[Nixterrimus]

Nixterrimus, Is Ken Wittlief still on your team? He should be able to explain the sensors and demonstrate their usage.

No, sadly Mr. Wittlief's son graduated and he isn't a part of the team this year.

[Nixterrimus]

This is not a gyro. A gyro returns your angular acceleration (NOT your angular heading... you would need to integrate the acceleration to get that)

Alright so this isn't a gyro, I'm good with that, but is this what was Demoed at the kickoff where the robot was able to correct its position? Does the hall effect sensor return your angular heading?

[Nixterrimus]

[EDIT] I found this article from a Hall Effect sensor manufacturer about how they work. http://www.micronas.com/products/overview/sensors/index.php [/DIT]

I looked at that too. Did you think that it was in English?
:o I thought that a lot of it was out there, I suppose I'm looking for just an intro to the hall effect.

[Tom Bottiglieri]

I looked at that too. Did you think that it was in English?
:o I thought that a lot of it was out there, I suppose I'm looking for just an intro to the hall effect.
www.google.com , my friend

[seanwitte]

This is not a gyro. A gyro returns your angular acceleration (NOT your angular heading... you would need to integrate the acceleration to get that)

Gyros measure angular velocity, not acceleration. The first integral of the velocity it the distance, so integrating a gyro provides angular distance, or relative heading.

Using a gyro to measure the robot's heading is pretty common with FIRST robots. The parts teams used last year are the Analog Devices ADXRS150EB and ADXRS300EB. The only difference is that the 150 can measure +- 150 degrees per second and the 300 measures up to 300 degrees per second.

Lots of posts describing how to do it.

[Sparks333]

Alright so this isn't a gyro, I'm good with that, but is this what was Demoed at the kickoff where the robot was able to correct its position? Does the hall effect sensor return your angular heading?

I BELIEVE what was demoed at the kickoff (not 110% sure) was the accelerometer. An accelerometer gives back a reading that tells how fast you are accelerating, i.e. changing speed, in a given direction. Using some programming, you can sense when you are moving and take steps to remedy it. A hall-effect sensor uses a magnetic field to detect a metallic presence, and therefore does not return angular headings. I am pretty sure they put out pulses when a metallic presence is detected. It's just an FET, in other words.

Sparks

[Rickertsen2]

To clear things up, the HAL effect sensors have NOTHING TO DO WITH ACCELERATION, OR HEADING. They are a type of sensor that detects the presence of ferrous materias. They are designed to be mounted up against(but not touching) the teeth of a gear in a gearbox or other assembly. They will output 1 pulse for each gear tooth that goes by them. If for example you were to connect them to your drivetrain, you could count the number of pulses they output to figure out how far your robot had traveled. It is also possible to use them to determine the speed at which your robot (or some subassembly) is moving.

[Nixterrimus]

If for example you were to connect them to your drivetrain, you could count the number of pulses they output to figure out how far your robot had traveled. It is also possible to use them to determine the speed at which your robot (or some subassembly) is moving.

So this is how FIRST is killing dead reckoning? Hooking these up next to gears tell you how far you've gone, the accelerometer could tell you if you were straight and now we can drive the robot any direction and know exactly how far. Right?

[Adam Y.]

So this is how FIRST is killing dead reckoning? Hooking these up next to gears tell you how far you've gone, the accelerometer could tell you if you were straight and now we can drive the robot any direction and know exactly how far. Right?
No. To be honest it's still dead reackoning and you still do not percisely know where the robot is with 100% certainty.

[Caleb Fulton]

Here are a few tips on the Hall Effect sensors:

These guys simply output a digital signal corresponding to whether or not a gear tooth is in front of them or not, and the polarity of the signal depends on the direction of gear rotation wrt the sensor itself (see the data sheet for more details: http://www.allegromicro.com/datafile/0660.pdf). Think of this device as a one-bit wheel encoder when you program for it.

The air gap, according to the manufacturer, should be 0.5-2.5mm, though they assure us that their adaptive sensing technology can make it work for an even bigger gap, especially with larger gear teeth.

The device has an open-drain output stage, but the digital inputs on the RC have pull-up resistors built-in, so you can directly connect the signal to the RC's inputs. Try to avoid grounding the signal wire, though, as this would technically be a short-circuit. Don't worry if you do -- the manufacturer says it has short-circuit protection on the output stage.

[FreakyAntelope]

We are given two Hall Effect Sensors. By using them to count teeth of sprockets on opposite sides of your robot you can calculate the difference in number of wheel rotations, and from that rotation of your robot.

If they are used this way, i believe, they work as a replacement for a gyro, although they would not account for being pushed or otherwise interfered with.

- Toby

[Al Skierkiewicz]

Guys,
Read some of the posts above before making guesses. The Hall effect sensors are easy tachometers that can tell you how fast a gear is rotating and how many gear teeth have passed by the front of it. Using two on the same gear, about 90% apart, can also give you direction information with some simple electronics or software interpretation. The accelerometer can be used only to give an indication of turning. It will give a large output for a bump or fast turn and a small output for a slow turn. Combine the data from all three and you will know that you have traveled "X" inches in some direction relative to your starting direction.
As a caveat, if your wheels are not firmly on the ground, counting gear teeth tell you nothing.

[Stu Bloom]

Check the Accelerometer bag. They are very tiny things and many teams have found them stuck to the accelerometer so they look like part of it.Thanks, I haven't had a chance to re-check our kit yet, but I see that this is documented in the "Guidelines, Tips and Good Practices" document (page 26 - see attachment). IMO this should have been documented on the kit checklist (to look on the accelerometer). Seems these could be easily missed, even for those who know what they are looking for :o

[dez250]

http://www.allegromicro.com/datafile/0660.pdf

I can confirm that is the proper spec sheet for the hall effect gear tooth sensor that is included in the 2005 FRC KOP. It is labled Data sheet 27627.107

[Nucks]

Check the Accelerometer bag. They are very tiny things and many teams have found them stuck to the accelerometer so they look like part of it.

We thought we didn't have it either, but after reading that, we checked and found it, thanks

[xxmaddjxx]

Arghhh! I don't understand lol.

Ok the Hall Effect sensor counts teeth and has to be mounted very close to the gear.

The accelerometer measures acceleration. How is that done and where does it have to be mounted.

How do all these values come together in the RC and help me?

What does the code that we get for both these sensors do?

[Al Skierkiewicz]

Arghhh! I don't understand lol.

Ok the Hall Effect sensor counts teeth and has to be mounted very close to the gear.

The accelerometer measures acceleration. How is that done and where does it have to be mounted.

How do all these values come together in the RC and help me?

What does the code that we get for both these sensors do?

If you know what your final gear ratio is (or you test to find out the correlation between counts and inches moved on the floor) you can determine how far the robot has moved. If it runs straight, you can tell where it is at any moment by keeping track of the counts. If you use the accelerometer, you can tell how much the robot has turned (or if it has turned the amount you want it to) so you now have direction and distance. Combine the two and get a rough idea where you are on the field. Be careful, the accelerometer output is proportional to the acceleration in one direction or the opposite direction. If it is mounted parallel to your direction of travel, it has no output. Read the spec sheet carefully to learn all of the nuances of the device and how to best filter out the info you need.

[cdawzrd]

So... They are sprocket-tooth encoders. Check.

How do we wire them? They have 4 pins, I haven't checked but it seems like they might fit on a PWM cable, but that only has 3 pins, so is it possible to wire it with only 3 pins or do we need to make new cables?

--Jonathan

[scottm87]

So... They are sprocket-tooth encoders. Check.

How do we wire them? They have 4 pins, I haven't checked but it seems like they might fit on a PWM cable, but that only has 3 pins, so is it possible to wire it with only 3 pins or do we need to make new cables?

--Jonathan

To wire this sensor, I suggest you check out the spec sheet that is linked numerous times in this thread. A link to the sheet is on the FIRST site at:
http://www2.usfirst.org/2005comp/Specs/gths1.pdf

For a basic overview, looking from the top of the sensor, the pins from left to right are supply, output, int. connection, and ground. it can take 4.5 to 24 volts input voltage (you would probably use 12), and the output will provide a digital signal whenever a gear tooth passes by (whether or not the output is high or low when a tooth goes by depends on the direction of rotation).

CHECK the spec sheet before you try it. It is helpful to see the diagram and check for yourself.

Scott

[scottm87]

Gyros measure angular velocity, not acceleration. The first integral of the velocity it the distance, so integrating a gyro provides angular distance, or relative heading.

Using a gyro to measure the robot's heading is pretty common with FIRST robots. The parts teams used last year are the Analog Devices ADXRS150EB and ADXRS300EB. The only difference is that the 150 can measure +- 150 degrees per second and the 300 measures up to 300 degrees per second.

Lots of posts describing how to do it.

Oops! You are right... With all the accelerometer discussion, I got all mixed up. The ADXRS sensors are nice, but you need to deal with the packaging. I think (not sure) the price limitations have been loosened enough that you can get an evaluation version of the accelerometer with some support circuitry brought out header pins that can be plugged into a board. This is much easier than dealing with a surface mount part, if you do decide to use it. Since there are more suppliers, it may also be possible to pick up other sensors now (the Memsic ones are also nice... and if it is allowed, you can buy it from Parallax pretty cheap.) Heh, you may even be able to get the old FIRST accelerometers from some supplier.

[xxmaddjxx]

If you use the accelerometer, you can tell how much the robot has turned (or if it has turned the amount you want it to) so you now have direction and distance.

How do you use the accelerometer to know how much you turned and in what direction?

What kind of value does it give out?

[Leav]

Has anyone had any luck with mounting the hall effect sensors?

i haven't found anything that fits them.......

also, if you haven't read the manual it states that you must connect pin 4 to pin 3 externally.

-Leav

[Captain Rich]

Using two on the same gear, about 90% apart, can also give you direction information with some simple electronics or software interpretation.

Ok, someone help me, I'm not understanding how measuring the speed of the same gear twice would turn into a direction.

[Mike Betts]

Ok, someone help me, I'm not understanding how measuring the speed of the same gear twice would turn into a direction.Rich,

Please read http://www.chiefdelphi.com/forums/showthread.php?p=307123&highlight=encoders#post307123.

We were talking about encoders on that page but the theory of quadrature remains the same as what Mr. S is talking about.

[Al Skierkiewicz]

Mike,
I can't get to the page you are listing.
So for the meantime, think of this. You are able to get two pulses from two seperate sensors. As the gears turn, one sensor has an output slightly different in time from the other. (You are positioning them that way for this demo.) Each outputs exactly the same info, (error checking) and if you determine which sensor outputs first for a particular direction then you will always know that you are traveling in that direction. When the pulses change places you have reversed direction.

[Greg Ross]

When the pulses change places you have reversed direction.
Al, there's a problem with your graph. The way you've drawn it. Each sensor is always low whenever the other sensor goes high. Without keeping track of time intervals between pulses, it won't be possible to tell the direction of rotation.

To reliably get direction information, you would need to position the sensors just far enough out of phase that the pulses overlap as illustrated below. Then when you see one of the lines go high, you can just check the other one, and immediately know the direction.

[jzampier]

With regards to sensors in general:

Buy good sensors, but make sure you consider their context of operation:
Example: Last season I used optical sensors with white lines on output
sprockets to count wheel revolutions. Didn't get me very far because the
robot wheels slipped horribly. I probably would have required some kind of
accelerometer to determine forward velocity independantly.
(Think like this: If i know how fast I'm going forward and my wheels are
going faster than that, they don't have full traction)

Also, consider what you are trying to measure, because integrating
sensor values introduces a large amount of noise into the system.
(Little bits of noise, added up over a 'long time')

I'd avoid getting fancy compasses or other such devices. But If you want to
read about them... look here:
Honeywell Magnetic Sensors (http://www.magneticsensors.com/products.html)

If you are interested in the Hall Effect, grab a physics book. I believe
Fundamentals of Physics (http://www.amazon.com/exec/obidos/tg/detail/-/0471232319/qid=1105677174/sr=8-2/ref=pd_csp_2/002-0035531-1895221?v=glance&s=books&n=507846) by Haliday, Resnick, and Walker covers the Hall Effect.

[Al Skierkiewicz]

Al, there's a problem with your graph. The way you've drawn it. Each sensor is always low whenever the other sensor goes high. Without keeping track of time intervals between pulses, it won't be possible to tell the direction of rotation.

To reliably get direction information, you would need to position the sensors just far enough out of phase that the pulses overlap as illustrated below. Then when you see one of the lines go high, you can just check the other one, and immediately know the direction.

Greg,
Thanks for the correction. I need to stop trying to rush a post before I leave work. You don't get a chance to go back and look at what you've done.

[Bob Steele]

Has anyone come up with a good way to mount the Hall Effect Sensors?
We are having a devil of a time figuring out a good way...

Can anyone offer a suggestion?

thanks

[Al Skierkiewicz]

Has anyone come up with a good way to mount the Hall Effect Sensors?
We are having a devil of a time figuring out a good way...

Can anyone offer a suggestion?

thanks

My recommendation is to mount the sensor on a piece of circuit board stcok. Radio shack has a variety of prototyping circuit boards that are prepunched and can be easily cut to size. Make the board larger than needed for the sensor. Make a small bracket from thin aluminum stock with a slot for adjustment. Mount with a screw, near the gear of interest and adjust as needed.

[Karthik]

Has anyone come up with a good way to mount the Hall Effect Sensors?
We are having a devil of a time figuring out a good way...

Can anyone offer a suggestion?

thanksHere's a picture of how Team 60 mounted their tooth counter last year.

http://www.firstrobotics.uwaterloo.ca/resources/galleries/drivetrains/drivetrains025.jpg

[emersont49]

Here's a picture of how Team 60 mounted their tooth counter last year.

http://www.firstrobotics.uwaterloo.ca/resources/galleries/drivetrains/drivetrains010.jpg

I've read the sensor documentation as well as many of the threads and still have one question.

Can the sensor sense the larger gear in this years gearbox or does it need to sense the sproket teeth?

[Al Skierkiewicz]

Here's a picture of how Team 60 mounted their tooth counter last year.

http://www.firstrobotics.uwaterloo.ca/resources/galleries/drivetrains/drivetrains010.jpg


Nice!

[KVermilion]

Hey,

Does anyone know where we can source more ats660s? Allegro seems to have ditched their remaining surplus of the soon to be obsolete sensors on FIRST. Very gracious and professional.

Amiclament.

Right now were are looking for a healthy alternative...

[bobtheblob]

Is the Hall Effect Sensor included with the Kit an ATS660 or ATS665? The KOP lists it as a 665 but the specification sheet on the FIRST website is for the 660. The two models have different placements for the Hall IC element within the sensor. This means the 660 needs to be mounted so the end faces the teeth, while the 665 is mounted so the side faces the teeth. It would be helpful to know which model it is without having to test it by experimenting. Can anyone clear up this contradiction?

Distributors for the sensors can be found through the allegro website. A company called NU Horizons electronics sells the ats660, but the time to deliver looks like it is 16 weeks. Newark in one sells ats665 sensors at $4.30 each.

Thanks
Bobby Sakurai
Team 159

[KVermilion]

Judging from the pictures, it is a 660, but the 665 is much easier to use (less external circuitry) and has a much more convient side mount. :rolleyes:

Oh yeah... and Nu Horizons has a large lead time (194 days IIRC)

[SteveO]

Does anyone know a reliable method to track your displacement using these guys? Our idea is to have something similar to a small idler/roller attached to a sprocket on the ground with positive only motion (perhaps one for forward motion and one for reverse) to eliminate the problems associated with wheels slipping/object contact etc. Any other ideas?

[Andrew]

Has anyone come up with a good way to mount the Hall Effect Sensors?
We are having a devil of a time figuring out a good way...

Can anyone offer a suggestion?

thanks

We made a small mounting piece which we have registered on the inside of the KIT gearboxes. I am waiting for a connector so that I can test it. The sensor faces the big output gear. I'll post up drawings, p/n's, mods to the gb cover, instructions, and output of the sensor once I have tested it. I don't want to encourage teams to make the mods until I'm sure it works.

[Sparks333]

Mike,
I can't get to the page you are listing.
So for the meantime, think of this. You are able to get two pulses from two seperate sensors. As the gears turn, one sensor has an output slightly different in time from the other. (You are positioning them that way for this demo.) Each outputs exactly the same info, (error checking) and if you determine which sensor outputs first for a particular direction then you will always know that you are traveling in that direction. When the pulses change places you have reversed direction.

Al,
I was looking over the allegra datasheets (links up above... Thanks Caleb Fulton!) and on Page 9, it describes something regarding polarity and direction. I think its internal circuity makes it so when you are facing a tooth going one direction, it's high, but when you are going the other direction, it's low. If your gear teeth are fairly far apart, you would have to measure the duty cycle to see which way it's turning... not sure how it would be done, but it may be possible with a single sensor to tell direction.
Here's what I read. Please correct me if I'm wrong.

Output Polarity: The output of the device will switch from off to on as the leading edge of the target passes the sensor in the direction indicated (look at the datasheet for the pic), which means output voltage will be low when the unit is facing a tooth. If rotation is in the opposite direction (again, see URL for datasheet), the output of the device will switch from on to off as the leading edge of the target passes the sensor, which means that the output voltage will be high when facing a tooth.

http://www.allegromicro.com/datafile/0660.pdf (http://www.allegromicro.com/datafile/0660.pdf) , pg.9

[jdong]

Al,
I was looking over the allegra datasheets (links up above... Thanks Caleb Fulton!) and on Page 9, it describes something regarding polarity and direction. I think its internal circuity makes it so when you are facing a tooth going one direction, it's high, but when you are going the other direction, it's low. If your gear teeth are fairly far apart, you would have to measure the duty cycle to see which way it's turning... not sure how it would be done, but it may be possible with a single sensor to tell direction.
Here's what I read. Please correct me if I'm wrong.



http://www.allegromicro.com/datafile/0660.pdf (http://www.allegromicro.com/datafile/0660.pdf) , pg.9

Well, it's difficult and processor-expensive to do so. You'd have to measure the length of each pulse, by interrupting on rising edge, then having the handler switch to interrupt on falling edge. By using a timer to count the ticks between these two, you can obtain the length of the pulse.

However, the time to pulse also varies with the speed (no direction) of the rotations. You sort of have to know the speed to do much with it.


However, I see little wrong with assuming direction. A PID controller reacts in ~20-30 ms -- it's very unlikely a robot can push yours in the reverse direction at that exact velocity...

[Sparks333]

Jdong,
I imagine you are quite right about the complexity, and you bring up a good point about assumptions. I was merely throwing it out as a piece of information that could be used so people could mess with it. I have absolutely no idea about how programming is done, and am rather hopeless (even after 2 C classes!) but what if you were to make the hall-effect sensor read a gear with a large gap between the teeth? that would make the duty cycle difference easier to read. I have other ideas, but most of mine are not that great.

Thanks again!

Sparks

[Al Skierkiewicz]

Sparks,
Sorry this is a little late. I have been looking at the sensor and page 9 is a discussion of the output vs. direction. If the gear is moving in one direction the output will rise from a low state to a high. If the gear is moving in the other direction, the output will move from a high to a low. This is data that I don't think could be useful other that scoping the output while rotating the shaft by hand. The suggestion I made earlier (thanks Greg for the corrected waveform) requires two sensors mounted so that the pulses overlap by 90 degrees (electrical degrees that is). You can see that rather easily in Greg's waveform that the top pulse leads the bottom by some amount. If the direction were reversed, the top pulse would lag the bottom pulse by the same amount. If you were to then compare the pulse trains by sampling when the top pulse goes from low to high, and determining the value of pulse train two, you could determine which direction you were turning. (If pulse two is already high when pulse one goes high you are turning in one direction. If pulse two is low when pulse one goes high you are turning in the other direction.) This is easy to do in software, (don't ask me how) and requires about four gates as I remember, in logic hardware to decode. The Hall effect is actually a pretty neat little package in that it uses two sensors at right angles to each other, to cancel out errors and temperature problems automatically. Please note the restrictions on gear tooth specifications when using and positioning the sensor.

[Gal Longin]

I've been having abit of a problem connecting the hall effect sensors with the 4 pins. i looked at the file on http://www.allegromicro.com/datafile/0660.pdf and it said that one pin is for +v one is for GND and one is the output signal and the one left is also for GND . it seems a bit weird to me. perhaps i'm not understanding it correctly. why would you need two pins for GND. do you really have to connect both the 3rd and the 4th pin to the GND?

please help me figure this out. what is the correct way to connect it?

[Al Skierkiewicz]

I've been having abit of a problem connecting the hall effect sensors with the 4 pins. i looked at the file on http://www.allegromicro.com/datafile/0660.pdf and it said that one pin is for +v one is for GND and one is the output signal and the one left is also for GND . it seems a bit weird to me. perhaps i'm not understanding it correctly. why would you need two pins for GND. do you really have to connect both the 3rd and the 4th pin to the GND?

please help me figure this out. what is the correct way to connect it?

If you scan down from page one you will see a reference that Pin 3 is an internal connection, scan a little further and you will see that it "must" be tied to ground externally.
It may be an electrocstatic shield or it may be the shell of the magnetic structure. Four pins tied to a PCB are better than three.

[russell]

doesnt the program only run every 26miliseconds? Thats about 38 times per second. So if you had 38 teeth moving past it per second wouldnt your program show taht the robot is simply sitting still? These things look way too complicated for me.

[scottm87]

doesnt the program only run every 26miliseconds? Thats about 38 times per second. So if you had 38 teeth moving past it per second wouldnt your program show taht the robot is simply sitting still? These things look way too complicated for me.

First of all, the slow loop runs at something around that speed. The fast loop runs much faster. Even if the fast loop was too slow, there is the magic of interrupts!

Interrupts allow your code to process events that may come in during the execution of another task, and "interrupt" the current processing to handle the interrupt (in a function known as the "ISR", or "interrupt service routine") There are a few magic registers in the controller that control how interrupts are handled (for a good reference, check out Kevin Watson's interrupt code).

So, while the radio may be able to only transmit/recieve information every 26ms, the controller operates much faster, and with interrupts, can handle tasks even faster than the "fast loop" that executes code while waiting for a radio packet.

Scott

[Derder1625]

[FONT=Comic Sans MS][FONT=Comic Sans MS]hm.. so afterall that has been said..
does anyone know where could we find the manual
for the hall effect sensor??~
:) thank yoU~~

[Derder1625]

=] May someone please tell me
where could we find the manual
of the hall effect sensor?? =] thank you

[Mike Betts]

=] May someone please tell me
where could we find the manual
of the hall effect sensor?? =] thank you
Please read this thread. The data sheet link is given.

[Kevin Watson]

Well, it's difficult and processor-expensive to do so. You'd have to measure the length of each pulse, by interrupting on rising edge, then having the handler switch to interrupt on falling edge. By using a timer to count the ticks between these two, you can obtain the length of the pulse.

However, the time to pulse also varies with the speed (no direction) of the rotations. You sort of have to know the speed to do much with it. If I understand this correctly, the duty cycle (time pulse is high/total period) is fixed at some value if the gear is going one way and fixed at a different value when spinning in the opposite direction. If this is true, all you need to do is use a timer to keep track of the delta time between edges to know which direction you're spinning. This *can* be done. In fact, this is very close to how the beacon receiver code worked last year. Perhaps someone can grab a copy of receiver.c and make it work? Last years code is kept here: http://kevin.org/frc/2004.

-Kevin

[Al Skierkiewicz]

Kevin,
The data sheet is really vague on this question. I have not used these sensors but in reading the data sheet, it repeatedly talks about how the duty cycle is fixed at some value and is stable with respect to temperature, air gap, and speed. I found that there is some hidden text as respect to duty cycle in the sheet and the waveforms for duty cycle are missing. (search the pdf for "duty cycle" and at the bottom of p8 you will see highlighted blanks, I selected the text and pasted it in another document to read it.)
Due to the variations in tooth shape, tooth depth, surrounding metal, etc., I believe the magnetic fields vary considerably. I am guessing that the manufacturer tried to compensate for these variables and probably aimed for 50% +/-5% by sensing zero cross. There is discussion that the sensor learns it's environment over the space of 64 cycles, adjusting gain and A/D parameters to make the output stable and accurate.
If anyone has practical experience with this device and can produce a waveform or two, it would be a big help. I will try and dig one out and see if I can get some data, next week. FLL state tournament is this weekend, so it's going to be pretty busy between now and then.

[pludodog]

What's everyone's best place and advice for mounting the sensor? The data sheet is lacking, but from what I would gather, it has to be mounted behind the teeth, so it can record their absence. Has anyone gotten it to work mounted above the gear pointing downwards (reading through the chain)?

[Al Skierkiewicz]

What's everyone's best place and advice for mounting the sensor? The data sheet is lacking, but from what I would gather, it has to be mounted behind the teeth, so it can record their absence. Has anyone gotten it to work mounted above the gear pointing downwards (reading through the chain)?

It is unlikely to read through the chain, there isn't enough of a magnetic change. It is better to mount further up in the transmission. Any error in counting is therefore reduced by the gear ratio between the gear you are sensing and the final movement of the robot.

[Excelsior]

We are having problems getting this particular sensor to work. We are currently testing it with an o-scope, and it appears that all our wiring is done correctly, but we are getting no output at all.

Any suggestions?

[Kevin Watson]

We are having problems getting this particular sensor to work. We are currently testing it with an o-scope, and it appears that all our wiring is done correctly, but we are getting no output at all.

Any suggestions?As noted elsewhere, the color coding is reversed from the norm. Red is ground, black is +5v. Could this be it?

-Kevin

[Joe Ross]

As noted elsewhere, the color coding is reversed from the norm. Red is ground, black is +5v. Could this be it?

-Kevin

That issue is for the accelerometer.


Excelsior, When you tested it, how exactly did you have it hooked up electrically, and what were you trying to test?

[Excelsior]

That issue is for the accelerometer.


Excelsior, When you tested it, how exactly did you have it hooked up electrically, and what were you trying to test?

Well, we mounted it on a protoboard, and hooked up power and ground to the first and fourth pins respectively. We connected the third and fourth pins, and simply put a wire to pin two to hook up to the o-scope. We were really just testing it to make sure it was putting out a signal, and what kind of signal it put out, but we can't get anything from it. Does that help you help me?

[Joe Ross]

Well, we mounted it on a protoboard, and hooked up power and ground to the first and fourth pins respectively. We connected the third and fourth pins, and simply put a wire to pin two to hook up to the o-scope. We were really just testing it to make sure it was putting out a signal, and what kind of signal it put out, but we can't get anything from it. Does that help you help me?

What type of gear did you use, and how good was your rotation mechanism. Also, how close was it? Remember that it needs to see 8 teeth in a row to calibrate, and if you were just moving the gear in and out or rotating it by hand, it may not have ever been able to calibrate.

[mschulkind]

What type of gear did you use, and how good was your rotation mechanism. Also, how close was it? Remember that it needs to see 8 teeth in a row to calibrate, and if you were just moving the gear in and out or rotating it by hand, it may not have ever been able to calibrate.
You will definitely need a pullup resistor on the output line to the specified voltage range or you will not see anything useful at all on the scope. Hopefully that addition works for you.

[Doug G]

We got it up and running last night, very cool. A couple of things... We did not use pin 3 (internal connection), I bet it is a safeguard for grounding and we may hook this up and retry it soon. As far as mounting it, we made a small hole in the top of the transmission closest to the 50 tooth output gear and wired it to a piece of proto circuit board and connected it directly to the analog input on the RC via PWM cable. The sensor must get fairly close to the gear teeth, within a 2-4 mm. Also its "self adjusting" which means you can't move it once your program is running. You have to adjust it then reset the program. Also run a test program in user_routines_fast.c . I'll take a picture of our simple test setup tomorrow and post it here.

[Alan Anderson]

We are having problems getting this particular sensor to work. We are currently testing it with an o-scope, and it appears that all our wiring is done correctly, but we are getting no output at all.
I wired up one of our Allegro sensors with a couple of capacitors and resistors on a teeny bit of proto-board. After a false start trying to test it out with a gear having too-small teeth, our sensor was working great Saturday morning. It seemed quite happy with the gears in an AndyMark shifter, which means it should work fine with the similar gears in a kit gearbox as well (our kit gearboxes are installed on the kit chassis and would be rather inconvenient to open up for testing).

Hoever, after lunch on Saturday, it wasn't working any more. I replaced the sensor with the other one, and it didn't work either. I had a couple of students double-check the wiring to make sure it matched the documentation. I took it apart and reassembled everything in a nicer arrangement with a PWM connector. They still didn't work. They haven't worked since. I can't figure out why. I am discouraged. We will probably use something else to measure the robot's speed.
Any suggestions?
Sorry, no.

[Sparks333]

Alan,
If it were me, I'd check to make sure the gear is rotating in the way described in the datasheet (I think it's so the flat part on the top is pointing away from the middle of the gear. Check the datasheet to be sure.) I hooked up our hall-effect to a proto-board and it wouldn't do anything until the gear was positioned correctly. By the way, I will test some more, but I couldn't get much of a duty cycle change out of the hall effect sensor by changing directions. I may do more testing on this, but as of now, it's software's problem :)
Keep us updated.

Sparks

[Chet Urata]

Pardon my ignorance, but can't you tell direction by how you are controlling the motors? Aside from determining if you are getting pushed in the wrong direction by another robot, what is the purpose of using the encoders for determining direction?

I was just informed of the fact (at least for our setup) that if you fully power motors for each side to make the robot go forward, that the motor for one side will be going running "forward" while the other will be going in reverse. I was told the motor going forward will run slightly faster than the one going in reverse meaning that the robot will tend to angle off of a straight path.

If what I was told is correct, using an encoder on each side (rather than two on one side) would allow you to determine if this is happening. Also, as mentioned elsewhere, this could replace dead reckoning.

c h e t !

[Matt Leese]

Pardon my ignorance, but can't you tell direction by how you are controlling the motors? Aside from determining if you are getting pushed in the wrong direction by another robot, what is the purpose of using the encoders for determining direction?

I was just informed of the fact (at least for our setup) that if you fully power motors for each side to make the robot go forward, that the motor for one side will be going running "forward" while the other will be going in reverse. I was told the motor going forward will run slightly faster than the one going in reverse meaning that the robot will tend to angle off of a straight path.

If what I was told is correct, using an encoder on each side (rather than two on one side) would allow you to determine if this is happening. Also, as mentioned elsewhere, this could replace dead reckoning.

c h e t !
For the CIM motors, they run the same speed forwards and backwards. We did a little experimentation with it last Saturday.

[Alan Anderson]

I was just informed of the fact (at least for our setup) that if you fully power motors for each side to make the robot go forward, that the motor for one side will be going running "forward" while the other will be going in reverse. I was told the motor going forward will run slightly faster than the one going in reverse meaning that the robot will tend to angle off of a straight path.
That was only significant with the drill motors used in past years. The motors in this year's kit of parts don't have a "forward/reverse" bias that makes a real difference.

Still, having feedback on the actual motor speed is important if you do want to control things well.

[Al Skierkiewicz]

Pardon my ignorance, but can't you tell direction by how you are controlling the motors? Aside from determining if you are getting pushed in the wrong direction by another robot, what is the purpose of using the encoders for determining direction?

I was just informed of the fact (at least for our setup) that if you fully power motors for each side to make the robot go forward, that the motor for one side will be going running "forward" while the other will be going in reverse. I was told the motor going forward will run slightly faster than the one going in reverse meaning that the robot will tend to angle off of a straight path.

If what I was told is correct, using an encoder on each side (rather than two on one side) would allow you to determine if this is happening. Also, as mentioned elsewhere, this could replace dead reckoning.

c h e t !

What happens when you stop controlling the motor? What happens when your robot is pushed from behind while running full out or from in front by a more powerful robot? If you are going to add sensors, take it to the full extent and get usable data for your software. Speed and direction are essential to determine where you are in relation to where you once were.

[Mark McLeod]

Pardon my ignorance, but can't you tell direction by how you are controlling the motors? Aside from determining if you are getting pushed in the wrong direction by another robot, what is the purpose of using the encoders for determining direction?
Just to chime in, I have another common example.

-Drive your robot forward and it's no great problem determining direction.
-Now cut all power and coast to a stop.
-You can assume your motors are still going in the last direction commanded, but when is that over? The robot will coast forward, but if it bumps into a wall/goal/robot and drifts backwards the s/w will think the robot is a foot further in one direction when it is actually a foot further back (that's a location error of two feet in this example).

[Chet Urata]

Thanks to all who replied!

First, thanks for the info on the motors. Armed with your information, we will check ours to see if they get the same results.

Regarding Mr. McLeod's comments, good example! You are right about the double error. You made me realize that the accelerometer combined with the gyro would help in the situation you mentioned.

Regarding Mr. Skierkiewicz' comments, while you also are correct, I wasn't clear in that I am not against using the encoders but was wondering if they wouldn't be better used - if you only have two - with one on each side of the vehicle. With the accelerometer and gyro you should then be able to tell direction. Slippage, of course, nullifies the encoders, which might happen if you are being pushed opposite the direction of your motors.

I could be wrong, but it seems to me that with only two encoders plus the gyro and the accelerometer, you would get more information with the encoders on different sides than you would by mounting both on the same side. With mounting on opposite sides, you can count teeth on both sides, yielding distance and difference in speed between the two sides (again, not counting slippage).

c h e t !

[jacob_dilles]

I could be wrong, but it seems to me that with only two encoders plus the gyro and the accelerometer, you would get more information with the encoders on different sides than you would by mounting both on the same side. With mounting on opposite sides, you can count teeth on both sides, yielding distance and difference in speed between the two sides (again, not counting slippage).
In theory you are correct – both sides are better then just one and you should be able to tell what direction the robot is going with an accelerometer. It reality though, having 2 sensors makes everything easier (you don’t have to integrate acceleration data, which may be controlled by a separate processor), and since the kit only supplies 2, most teams will only have 1 side equipped with sensors. If the kit came with 4 or more sensors, you would see people put 2 on each side.

Hope this answers your question

[jimsmith2354]

Has anyone had any luck with mounting the hall effect sensors?

i haven't found anything that fits them.......

also, if you haven't read the manual it states that you must connect pin 4 to pin 3 externally.

-Leav

Mounting of the Hall Effect sensors - We have drilled out the inside of two small connector housings, sanded off the middle ring on the outside, and will use jam nuts to hold them onto brackets placed near either the output gear or a tone wheel.

From another post, connect to controller using a PWM cable - RED to Pin1 - WHT to Pin2 - BLK to Pins 3 & 4

We will wire, test, then epoxy them into these homemade housings.

Mouser PNs 571-14454211 (x2) and 571-16041961 (x4)

Good Luck,
Jim

[MyFeetHurt]

Hey, Stu, it's Christine. I did some calculations.

Wheel radius = 4", Robot speed = 10 ft/sec, gear by sensor has 45 teeth

2 * pi * 4" / revolution

* 1 revolution / 45 teeth

* 1 sec / 120 "

* 1000 mSec / sec

= 4.65 mSec / tooth

In other words, you can't do this by polling the sensors in a 26 mSec cycle, and you probably can't do it in the fast cycle either.

I think the right way to do this is to hook the sensors to a digital counter and poll the counter. I could be wrong. I don't know squat about counters, it's after midnight, and I can't remember how quickly the fast code cycles.

I won't be there this weekend. See you all Monday.

[Joe Ross]

You can get very similar Hall effect sensors from Newark (they are actually just the next version newer, ATS665LSGTN) for $5. So, teams shouldn't limit themselves to just the two in the kit if they want more. There were 762 in stock when I posted this.