I am helping a local school with their Robotics competition as a mentor. We're currently finishing up the controls and we're stuck at the following problem:
How do you know how many degrees a wheel has turned?
Now I am not talking about forward movement. Iam talking about the wheel rotating to the left or right so the robot can steer left or right. The robot has been setup to work exactly like a car. Steer the steering wheel left the wheels should rotate left; steer to the right, rotate right.
Both wheels are encased in a holding we constructed that should be able to turn freely for up to 30 degress. We have a DC Motor handling the turning. The problem I am having is fining the best way to make sure the wheels are turned a maximum of 30 degrees in either direction.
The only method we could think of was using a potentiometer. We make some sort of cam that will turn the knob on the potentiometer as the wheel turns to the left or right. Then we calibrate the range and add that to the software. Thus if the potentiometer goes out of range one way, we only allow rotation in the other direction. I dont know if this is the best solution. Any better suggestions? Or is the method I have adequate?
Assuming you have used a geared motor to control the steering, could you measure rotation of the armature of that motor with an encoder? Some kind of optical encoder would do it. You can then sense the end-points of the motion of the steering with microswitches, so that the software can calibrate itself for absolute position.
We did think about using an encoder but our problem is there is no way to save a state when the power turns off. The encoder would work fine if the robot always started off in the same position, but if the robot turns off mid way, there is no way for the encoder to know where the wheels are.
there is no way for the encoder to know where the wheels are.
So when you power up you turn the wheel hard left until it hits an end stop or until it stalls. Then tell the encoder it is hard left and go from there.
@weirdo557: Yes this is the FIRST competition! What gave it away I might add?
@Grumpy_Mike: We intially created the chasis without thinking of this issue and there really isn't a way for us to add a controls hard stop (through microswitch, touch sensor, etc). If there was, there would be no need for the potentiometer or the encoder - as soon as you hit the hard stop in one direction, you can't turn any more in that direction.
Therefore I am trying to think of a solution which requires no hard stop, mechanical or electrical, at all. The problem is if the robot accelerates in a turn of more than 30 degress the robot has a high chance of toppling over.
In that case.
There are two sorts of optical shaft encoder, one that gives you pulses and one that gives you position. The latter is what you want but they are quite expensive.
I've never even heard of a position optical encoder!
Just did a quick search on digikey but didnt find anything. Would you happen to have a link to something that might work?
I am seriously considering using and encoder with an Atmega168 to store data to the EEPROM or Flash. Then output a PWM output to the main controller through a low pass filter.
ohh, also, i think the Crio controller that you are using can save text files in the memory of the controller. I'm pretty sure you can use standard C++ fstream library and redirection operators to read and write values that wont be deleted upon powering off.
I've never even heard of a position optical encoder!
Just did a quick search on digikey but didnt find anything. Would you happen to have a link to something that might work?
I am seriously considering using and encoder with an Atmega168 to store data to the EEPROM or Flash. Then output a PWM output to the main controller through a low pass filter.
Coming from an industrial background this is something I've run into. Positional encoders are pretty expensive and not something you'd want to use unless you have no choice. Even most CNC machinery uses rotational encoders. If you move the machine while the encoder is off they lose their position. As you said, you could use a normal encoder and store the position to EEPROM or flash. But you can't write to the flash memory of an arduino from the program (well... you can if you write your own low level code) so you'd have to use external flash or the built in eeprom. The EEPROM is rated for 100,000 cycles so be careful how often you write to it. Ideally it would be nice if you could count on being able to save just before the robot is turned off and rarely if ever before that. Then you'll never wear out the memory. You'll still need a way to calibrate it initially and then whenever the calibration is suspect.
I saw an article in Nuts and Volts a while back on creating an autonomous PowerWheels (TM) vehicle. He used a DC motor to rotate a steering shaft - and he implemented it by putting reed switches on the left and right side of the car and magnets on the steering mechanism (or vice versa) either way, when the reed switch closes, you're at the maximum turn. I don't think it's an ideal solution, but it might work in your case.
I can't seem to find the article online right now, but if you're interested in hearing more, I'll find the issue# when I get home.
US Digital makes two channel encoders with an "index" pin, that only goes high at one place during the revolution. Assuming you mount the encoder such that the index is at the center position, on startup your steering could oscillate until it finds the "index" and then use that as its center point. From there you can count either way, but you'll always have the index as your center reference point. This also assumes that your motor makes less than one revolution from left to right, in which case it might be better to mount the encoder to your gearbox outpt or the steering rack. Quadrature encoders with index pins are no more expensive than those without.
Of all the absolute position encoders you linked to the only one even slighly affordable was this:
The other ones are industrial encoders for big machines. Granted, I've spend way more than $300 on a normal encoder for a mill so your links aren't really that bad for industrial encoders.
@weirdo557: I didn't know that. I was looking through the libraries for some sort of memory storage but didn't find anything. I saw the I2C library and thought I might be able to find an I2C EEPROM chip to interface with, but if I don't have to wait for parts that great. I'll try saving text files tomorrow.
@Grumpy_Mike: I don't think the 39 dollar one was too bad pricewise. Or the 300 dollar either for that matter. Unfortunately, now I think its too late. I tried convincing the team lead of the benifits of going with an encoder earlier on but he didn't budge. I don't think it helps that much that the pot was his idea.
We ran yesterday and were debugging the steering for about 3 hours. The pot idea is doing ok. We calibrated the pot and found our max left, right and center positions and devised a formula for interface with our joystick.
Depending on the surface we drove the robot at we were getting a lot of bounce off the motors. Did not help that our steering chasis is very lose. We kinda have some sort of rack and pinion steering going. The DC motor drives the pinion, which is attached to a belt with teeth. The belt acts like a tie rod as well. It is wrapped around both wheels and turns them left and right.
I think the rubber belt might be the source of the problem. It isn't rigid enough to allow for proper steering and vibrates a lot when the robot is moving. Today the mechanical guys on the team are going to try fabricating a proper metal rack and tie rod for the robot.
One major problem with the potentiometer I am noticing is the need for debounce. The potentiometer keeps giving different values when the robot is moving, even when it is going straight without turning. Tightening the cam that turns it helped, but it still reuires quite a big range for debounce. This seriously effects touch turning left and right, as the joystick has to be moved quite a bit for the robot to move in the corresponding direction due to the high debounce range.
Another issue is the robot seems to sway yo the left. We calibrated both motors so they move at exactly the same RPM but the robot still sways to the left. I think this problem might again be with the rubber belt not allowing us to make both wheels point exactly straight. Hopefully the tie rod will help this aspect.
@jesuz: Team 2356 here in Canada. We'll be competing in Toronto. What do you think of the competition? Are you guys mentors too? I've helped out with this and the skills canada robotics competition and definately prefer the latter. 6 weeks is too short to teach kids all they need to know, especially with 2 weeks lost in between due to exams. I find most of the mentors basicly take over and the kids lose interest. I know I would be competely lost as a grade 10 in high school. Skills Canada allows you 4-6 months to prepare and really have no restrictions on materials used. Way better learnding experience IMO. I am biased though. When I was in grade 12, we won nationals in skills Canada and a few members on the team got to go to Japan to compete in Internationals. Not me though, University got in the way
