EEPROM and Encoders

[Bharat Nain]

In the past, I have seen teams use EEPROM to record an autonomous mode at the click of a joystick. Of course this makes life SO MUCH SIMPLER except it has some major flaws. The results will vary every time you run it because of battery power(big one), wear and tear on wheels, motor damage, slight modifications etc. So I thought of a neat idea although I haven't yet figured out how this is feasible - record encoder counts into the EEPROM. We would have to avoid time as a variable(unless someone thinks up of a clever scheme). Any ideas?

[Rickertsen2]

The idea solution would be to record distance in 2 dimensions as a series of waypoints. This is complicated by the fact that the robot does not travel in perfectly straight lines at 90 degree angles.

You could record time vs speed and then use closed loop feedback to stick as close as possible to that speed. Feedback seems like it should work better than the normal way but like you say something time independant is far better.

Perhaps distance vs. speed? IE: when we had traveled 815 ticks we were going 65 WheelTicks/Sec. Distance would be defined as how many ecoder ticks since the start. This still has a problem of the two sides being out of sync. They may reach their relative distances at different times cusing improper turning.

Somehow special attention needs to be payed to the phase of the left side and right side.

[KenWittlief]

Originally Posted by Bharat Nain

In the past, I have seen teams use EEPROM to record an autonomous mode at the click of a joystick. ...

So I thought of a neat idea although I haven't yet figured out how this is feasible - record encoder counts into the EEPROM. We would have to avoid time as a variable(unless someone thinks up of a clever scheme). Any ideas?

you are describing a state machine. The EEPROM holds the 'next condition' that must be met until the it advances to the next state

an encoder input to a counter could be one of the inputs its looking at.

You could store it all in an EEPROM table or you could implement it as a SW algorithm - both will work.

[DonRotolo]

Originally Posted by KenWittlief

you are describing a state machine. The EEPROM holds the 'next condition' that must be met until the it advances to the next state

A good discussion of state machines in an easy-to-follow writing style is in a description of Isomax, find it at IsoPos Manual (It's a 3.6 MB Download of a .PDF)

Regarding reading & writing to EEPROM, that's what it's meant for, as non-volatile RAM.

Don

[ConKbot of Doom]

If you are using encoders for feedback then you probably have a PID loop to make the motor speed relative to the joystick input, right? Well if you let the eeprom store your joystick inputs then your PID loop should correct for when the battery starts dying.

[Kevin Watson]

Originally Posted by Bharat Nain

In the past, I have seen teams use EEPROM to record an autonomous mode at the click of a joystick. Of course this makes life SO MUCH SIMPLER except it has some major flaws. The results will vary every time you run it because of battery power(big one), wear and tear on wheels, motor damage, slight modifications etc. So I thought of a neat idea although I haven't yet figured out how this is feasible - record encoder counts into the EEPROM. We would have to avoid time as a variable(unless someone thinks up of a clever scheme). Any ideas?

If I had to do it, I would setup the 'bot to keep track of it's position on the field, and when a joystick button were pushed, store the current location as a way point to EEPROM. If you kept your moves to straight lines and turns-in-place, you could modify the 2005 scripting code to play back the commands from EEPROM.

-Kevin

[Bharat Nain]

Another question: Is there any way to retrieve information from the EEPROM and put it back. In other words manipulate information in the EEPROM. I have not read up about it so that's homework for tonight.

[Mike]

iehi

Originally Posted by Bharat Nain

Another question: Is there any way to retrieve information from the EEPROM and put it back. In other words manipulate information in the EEPROM. I have not read up about it so that's homework for tonight.

Check out the EEPROM read/write code created by Chief Delphi's resident programming genius, Kevin Watson.
http://www.chiefdelphi.com/forums/sh...ad.php?t=39973