There are countless ways to do this but I'd go with optical encoders. There proven and very accurate. Sure if your wheels slip then they lose all accuracy but there are ways of telling if your wheels slip. In the past teams have measured the current draw of the motors. If your bot collided with another bot your amps would suddenly increase because the motors are having to output alot of power. Then if you overwhelmed and the wheels slip the crrent will drop because the kinetic COF friction is less that the static so once your wheels start to slip there will less draw on the motor. Also there should be a noticeable change in current when you hit the ramp.

It may take some experimentation to figure out what can be done with current draw but its a possibilty. Saying that though no system will be 100% accurate. If a 300billion dollar defense budget can only get a bomb within 10 feet of a target. I predict even the best guidance system will only get a bot within a foot of its target.

To wysiwyg:
Like what sevisehda said in his post, wheels can and probably will slip. Though he did mention a fix for it, the solution is way to complicated and still has a good chance of failure. What if something else makes the current reading shoot up? Your robot will try to correct something that didn't even happen! Also your robot could be slipping while its in place(it hit a wall), or it could just be slipping a little(hits a box), or maybe its just hit something so hard to push, its moving very slowly(and still drawing a lot of current). Those are all cases that a robot has to respond differently too.

The problem with dead reckoning is that is invokes most people to think in terms of a procedure. If any of you have taken a Computer Science 1 course, your programs could be moved in functions, and the main() function would look like a procedure.

int main()
{
//Do this until that

//Start doing this...

//Last stage now do that

return 0; //End of program
}

To compare what that is in a looping program:
while( auton_mode == 1)
int stage;

if(stage == 1)
{
//Do what it should do
//If "this" happened" set stage to 3 to fix it.
}
else if(stage == 2)
{
//Do whatever
//If "that" happened" set stage to 1
}
else if(stage == 3)
{
//Do whatever
//If this happens go to someother stage
}
} //while loop

Of course the code was oversimplified, but the point is that the robot shouldn't do "this" until "that" is done correctly.And doing "that" correctly is harder than most think. Not only that, but supposing you have a flawless procedural algorithm. The robot runs like games today - it's looping extremely fast and doesn't really do much code different from the previous frame. Converting that procedure into looping code takes a lot of memory because most conditions can only be assured to be true over a large number of loops(iterations) soyou have to remember what happened 20 or 30 loops ago (assuming you need to remember the condition of the robot about a second ago). Thats a big strain on memory, and processing such data to find out a certain condition would be too slow, resulting in big packet losses.

To Brian_Lim :
I have no clue how a robot will work without a single sensor in autonomous mode. It should know if its going left or right unless you wanna reduce your chance of having it work by 50 percent off the bat.

My two sides
 

I like sensors. I could care less whether dead reckoning makes your bot really fast. I want to learn elegant solutions that work well and are more fail-safe than your solutions.

:D

I like dead reckoning. We have at least one dead reckoning program on our robot. Dead reckoning is great when you only need it for a short time. We should all try our best and do what we can to do what we want.




Everything has its faults. There is no end-all, beat-all, solution. But what we must do is try and limit the faults, and learn how to make it work. That is what FIRST is about.

Lead programmer of 783 here.

We were poking around with the optical sensors from last year, and discovered a rather large problem. They trigger on anything reflective.

We pointed it in the general direction of the reflective tape. It detected that, and that was all fine and dandy. We then pointed them at the diamond plating used for alliance stations, it detected it. Not such a big problem, the wall would probably be out of their range anyways. We pointed it at last years bot, and it detected. This was a large problem. There was no way to tell our alliance robot from our targets on the bottom of the boxes.

So, we decided to switch to a dead reckoning program, and that hasnt given us too much of a problem, except for a slight miscalculation on my part that left a rather large hole in our drywall wall. Oops. The price of knowledge I guess.

Azash
No, these tag lines are never the same from me.

I wouldn't really consider it a sensor, but we have a dial on the robot that selects the program to run. There are 16 positions on the dial, so we can have up to 16 different programs. Some of those positions will be used for duplicate runs on different sides of the field. It really isn't that difficult.

I don't know what kind of experience you have programming, but you seem to be way off base in some of your statements. A "looping" program can pretty simply be implemented with a state-machine. If you remember that you have scratch RAM to play with or even the EEPROM, you can do some really creative stuff.

Just because you can't imagine it, doesn't mean it can't be done.

Ryan

Actually I have a solution. Mount the encoder disk onto a free wheel that is not connected to a motor. Now the disk only registers pings when the robot moves(hopefully). Of course this is probably the best way to place an encoder disk but unfournatly it is still not perfect. Of course nothing is perfect.

I dislike useing an idler, plus you'd have to use 1 on each side so you could calculate the turn as well. I threw out the idea of current monitoring because it has other uses. For example the amps increase when there is a heavy load on the motor, so if your bot had a CVT. The bot would be able to read this heavy load and drop to a lower ratio in order to start shoving. Also if it read slipage you could pulse the motors in order to reestablish traction. Some cars use similar principles to drive in snow::cough cough::. Either way you would have to experiment with this and see what really happens to the current and then have the code recognize each scenario.

I am getting a whee bit confused. How this relates to dead reckoning?

I thought we were disscussing ways to makes bots ridiculously complex in order to make the bot be slightly more accurate in getting to were we want it to go. Personnally dead-reckoning is good enough for me. I was trying to making the point that if one didn't feel comfortable with deadreckoning he could place optical encoders on the wheels to track distance. Then if you were afraid of slipping throwing off those numbers then you could check the current draw from the motors to identify slipping.

I find it highly unlikely that robots will slip. If a 5lbs container causes you to loose traction, think of what a 130lbs powered robot will do. If your robot slips, you have 20 hours to redesign it, or prepared to get pummeled;)

Jeff_Rice: I agree. I'm just more towards using the sensors.

Azash: Last year's sensors could be quite different. They do seem to be the same, I haven't actually looked at the part number though. I also realized that the sensors trigger anything reflective, but unless you are going to have them point anywhere else but the floor, it will only trigger on two things, the white tape, and myabe the wire mesh. They work if you put them on the bottom of your robot looking down. Hence, when then sensor goes off, you know where the tape is relative to your robot to a pretty high degree.

RyanKM: I know what you mean about the different programs running. But that dial, I assume, is something you have to set before the autonomous code. Will we know wether or not we are going left or right before the match start and be allowed to change something on the robot? If the answer is yes, then good for you. Select the dead reckoning program before the match.

All you need to know is that I have enough experience. I don't want to get into how many years. And if you looked at my psuedo code, that is a basic state machine. Maybe you just overlooked that I posted a solution. In case you care about my background, I have been an aspiring game programmer so I know plenty about looping code, and running differently on a frame by frame basis to achieve a psuedo procedural algorithm. Also, I can imagine it - heck, I can see it put to code, just bug ridden and very flawed. Please try to sound less insultive next reply.

wysiwyg: Excellent solution. And that one I can't see failing unless that wheel is lifted off of the ground, which I'm almost sure won't happen in autonomous mode. I know our team has a caster wheel that wouldn't be slipping, but since that could be in any orientation, I wouldn't know what direction it move over that distance unless I had some other form of input about the orientation of the wheel.

sevisehda: I don't know if i was clear in the original post. I think most teams have overcomplicated autonomous code. Not that I have seen, but based on the questions I see on these forums, people seem to be attempting pretty complicated things that have a high chance of failure.

No. The people who put the robot on the field will be blindfolded and given small shock collars. As they move randomly around the field, the judges will stop shocking them when they reach the proper position.

Are you saying my code is "bug ridden and very flawed"?
I don't believe he was trying to insult you as very few people ever do that on these boards; he was just pointing out that looping is very easy and doesn't require huge amounts of memory or a lot of resources. I agree with him whole-heartedly. Our autonomous code takes up 2 bytes, both of which are used for other things during regular operation.

They are the same.


And many (including myself) would argue that line-following is overly complicated.


Please, take a deep breath and relax for a few minutes. You don't need to argue with everyone. What you may consider "overcomplicated" may be the easiest solution for some and may be a better solution for some types of robots. For example, read back to the first page and notice that Jeff Waegelin said dead-reckoning "works better" for his team. Are you saying that you are more qualified to assess what solution is best for every robot? As far as I know, such a uber-leet programming god doesn't exist. Especially not when it comes to FIRST.

I believe there may be a way to get foward information and how far the turning information is by only using one idler. Hmmmmm.... I came up with the idea yesterday. Of course this is something to fool around with during the summer when I have the time.

If your gonna get this complicated, why not just get a spring loaded mouse. It will be lighter and easier than an idler and optical sensors.

Heheh thank you. A mouse is nothing more than two optical encoders in one castor. I knew something like that would have been built but I could not figure out what.