Hall Effect Sensor.

[Kevin Watson]

Originally Posted by 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?

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

-Kevin

[Joe Ross]

Originally Posted by Kevin Watson

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]

Originally Posted by Joe Ross

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]

Originally Posted by Excelsior

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]

Originally Posted by Joe Ross

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]

Originally Posted by 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.

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]

Originally Posted by 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 !

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

[Alan Anderson]

Originally Posted by Chet Urata

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]

Originally Posted by 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 !

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]

Originally Posted by 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?

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]

Originally Posted by Chet Urata

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