Overcomplicated Autonomous Code

Lead Programmer on team 623 here. I haven’t been a big part of the threads in this forum, but I have been watching them pretty closely. I’m not trying to sound arrogant or anything…but[there always is one] I am not seeing too many good questions being asked. I’m hearing all of this stuff about timers over and over. I know what they can be used for, but I really don’t think they are a good solution to problems.

I would agree that if you get working dead reckoning code, you can get to the top of the ramp the fastest. The biggest problem is the unpredictability of the match KILLS that completely. If your robot gets hit by your alliance partner’s robot on the way up, how does your robot know how much its been knocked off track? It doesn’t. How does your robot know what angle it is moving at up the incline? How does the robot even know it’s on the incline? How does your robot know in the beginning to turn left or right?(actually there is a simple solution to that one) Basically, I think a lot of effort is being wasted going that path, for something that could fail so easily and badly. Also, there is no garuntee that if your robot reads “this” then “that” is the case. There are many "this"s that will lead you to the same “that” case.

In Computer Science, its good to keep your code and algorithm simple. Usually, if it(the algorithm) is very basic, when you develop it, it will take care of problems that you might not even have considered while making it. If you list all of the specific cases for failure before planning what it should do, you might run yourself into a hole thinking of all of the possibilities and needs to fix it.

Also, if you’re wondering why I’m even discussing this. Here in the DC Metro, we have a shipping extension because of snow, and other than that, any team can still change our program before the actual competition.

Please, feel free to argue against me on any of those points. I would love to be convinced of why timers are the most efficient way of solving the problem.

Timers can be used as PART of the autonomous run. For example, once the robot senses that it is done tracking the line up to the top of the ramp, it will go forward for X amount of time, turn right, open a lifting mechanism after Y seconds, etc…

I can see why it would be unreliable to have the entire autonomous mode running on a timer, though

Originally posted by EbonySeraphim *
**
How does your robot know in the beginning to turn left or right?(actually there is a simple solution to that one)
*

and how would you do that? I haven’t got into the programming much. I do know though that the main reason that we’re using dead reckoning is that we don’t have the space and weight to mount the sensors (yeah I know that the sensors don’t weigh much, but we’re REALLY close)

Neil, lead programmer of 1089.
I agree whole heartedly and think autonomous will get scrapped. if the robot gets knocked off course and veers into NASA’s precious wall it will ABSOLUTELY be disabled. the chance of this happening is quite high and as it is an extremely experimental thing it will fail just as much as it will go perfectly. Just remember, “Murphy was an optimist”. have fun.
~Neil

I agree that if something goes wrong with dead reckoning code you are totally screwed, however, when it works, it works really well, and FAST, and in this competition, FAST is really important.
Also, after playing around with the optical
sensors in the kit, i decided that they weren’t
useful enough to get me where i wanted to go.
I even tried hybrid dead-reckon/line follow code. Its not a code issue, its just that the movement of the robot is too jerky and imprecise to align a sensor. I’d need about 9 sensors to always have at least one on the line, which just isn’t worth the 2^9 states worth of programming.
I considered using an ultrasonic range finder, but didn’t have time to get one/test. I thought a set of three might be useful for collision detection, etc. Other things were a fifth wheel
rotational counter, which we didn’t have weight for and doesn’t compute direction.
In order to have really good autonomous behavior you need so many types and quantities of sensors that its not worth the expense or trouble.
I figure to get a good position and heading
plus obstacle avoidance i’d need 3 ultrasonic sensors, fifth wheel, plus maybe an RF triangulation system (which is highly illegal per FIRST) or something like it.
Basically, all things considered, mostly time and weight and cost, dead reckoning is most bang for buck. Certainly not smart at all, but its useful enough. And FIRST is often about good enough. ( as evidenced by the love of hammers )

Caleb Fulton: You just sort of ran over the hardest case to check as if it was nothing. Unless there is some magical hardware tool that gives your program input on wether or not it is going up the ramp, that’s very hard to know. I actually posted a relatively simple but very flawed solution in another thread. Also why would you want to go forward X amount of time? Wouldn’t you not care how long it takes to get there, but rather, that you DO get there? I’m not saying you’re completely wrong. Just throwing big flaws in the approach. I don’t think there is a solution to autonomous code. Only a way that has the highest chance of success, one that is the fastest(higher chance of failure), and one that tried to be flawless, and ends up not doing much.

To Solace:
That check would have to be done with sensors. One on the far left and right of the robot. Once one goes off, you know thats the way your robot should be going for the rest of the time. The reason that they should be far apart is in case your robot drifts a bit to the right or left. You dont want your robot to think it should go the wrong direction.

To AntmanIV:
I wouldn’t say you should abandon autonomous code completely - but you shouldn’t leave anything there that could kill your robot (or people). Just think of the problem on a very simple level, and make the hardware guys do more work to make your job much easier. If my hardware guys could tell me that when the robot is going up the ramp this will give that input value, I would have near flawless line-tracking code.

Edit To jzampier:
About the dead reckon/line follow code. Why does it matter if the robot is too jerky? The/a sensor shouldn’t always be on a line. Why not just say, keep the line between two sensors? As long as your robot goes foward and the line is between the sensors, you must be going the right way, right? Once again, I agree that dead reckoning is the fastest, but when it goes wrong…it goes wrong. And if you do a pure dead reckoning robot from the start, don’t you only have a 50/50 chance of going the right way in the start? Left or right? I think you should at least know that before doing much else.

What immediately came to my mind as I was suggesting the “when the robot senses when it is on the top of the ramp” idea was that if, assuming that you are trying to keep the tape between the sensors, both sensors are registering for more than 10 or so loops, you are on the ramp.

A gyro could also be used…

(I do argue religiously)

What do you mean by “registering for 10 or more loops?” I assume that you mean both sensors are on for ten loops in a row. The problem is that on the ramp, the sensors will be on and off erratically(or so I think). How will your code distinguish this from actual line tracking data? On a frame by frame input/process loop, you can’t look at the big picture. The robot only knows what happening in the current time.

I think I misread your top of the ramp notion though. The top of the ramp that is white I guess could easily be determined by that condition you stated. It’s being on the incline that is the problem. The line won’t get you all the way to the top, and it’s near impossible to be sure that you’re on the ramp. So you can’t even tell your robot to go straight once you aren’t tracking the line.

I do not understand why there is a need for sensors.

I do not even know if the Banner Sensors even work on the white refective tape.

If using sensors, there would be a need to accurately space the sensors apart to “see” the white line.

The most basic solution is to have the robot go forward a bit, turn in an arc to a specific counter, and then go forward again.

A simple toggle switch wired into the digital input tells whether the robot turns left or right.

To go forward, make code for the robot to go forward until a counter. To turn, make one wheel spin faster than another. To go forward again, another counter.

Our team was considering mounting some sort of sensor on the wheel to see how far it travelled. Just a touch sensor and studs placed at specific intervals on the wheel.

Why is having an internal counter unreliable?

Autonomous-mode seems one-dimensional to me. This looks like the best solution. Get up the ramp the fastest, knock the boxes down. Trying to find the reflective tape with the sensor spinning around? Good luck.

*Originally posted by Brian_Lim *
Why is having an internal counter unreliable?

Because various things can affect how far your robot travels in the period of the counter. A fully charged battery will cause a robot to travel significantly faster and thus farther in the same amount of time compared to a somewhat depleted battery. If someone sets bins in front of your robot it will probably slow you down and screw up your timing as well. This is a fundamental problem with dead reckoning. Ask anyone who has participated in FIRST Lego League about these problems and I’m sure they’ll have a lot to say about it!

*Originally posted by EbonySeraphim *

To AntmanIV:
I wouldn’t say you should abandon autonomous code completely - but you shouldn’t leave anything there that could kill your robot (or people). Just think of the problem on a very simple level, and make the hardware guys do more work to make your job much easier. If my hardware guys could tell me that when the robot is going up the ramp this will give that input value, I would have near flawless line-tracking code.

well we are not abandoning it but were just thinking that if a robot gets shoved ^.- it might do it’s coda at a weird angle and er… break the plastic wall on the ramp and :yikes: oops…

Hmm… so much to think about now with only one day to go… lol.

Break the walls? Dang… they must be really cheap then! Our team made a practice ramp and used 1/4 in. plexiglass or lexion or whatever that cheap plastic stuff they have, and I’ve run into it many times at full speed when testing our autonomous programs… hasn’t broken yet :smiley:

Because various things can affect how far your robot travels in the period of the counter. A fully charged battery will cause a robot to travel significantly faster and thus farther in the same amount of time compared to a somewhat depleted battery. If someone sets bins in front of your robot it will probably slow you down and screw up your timing as well. This is a fundamental problem with dead reckoning.

Actually there is a way to implement dead reckoning that gets rid of the above problems. Use an encoder disk.:cool: These things are circular disks with stripes of black and white running down them. Mount this disk somewhere onto the drive train. Using this and a sensor (usually infrared or banner sensors would even work) you can now calculate how far your robot has gone by reading the pulses of the sensor. A little gear ratio math and you can now figure out how far the robot is going in each pulse. Although using the timing of the controller is almost the same idea this will not get the robot off track due to differnces in speed from a fresh battery. Of course nothing can really correct a big change in the course of the robot. I am just surprised that far fewer teams went the more complicated way to do it than the simpler way.

Break the walls? Dang… they must be really cheap then! Our team made a practice ramp and used 1/4 in. plexiglass or lexion or whatever that cheap plastic stuff they have, and I’ve run into it many times at full speed when testing our autonomous programs… hasn’t broken yet

It must be lexan because Plexiglas has been used at hockey games to protect the people but the barriers have been known to shatter. I think? Plus lexan is used in bullet proof windows so that does not shatter easily.

We had grandiose plans for multiple sensors and all sorts of complex controls, but in the end, our dead reckoning program works better. We may still throw a few impact sensors on just in case, but we found that our basic dead reckoning program works 95% of the time, even when we crash into a faster robot or hit human player stacks.

*Originally posted by wysiswyg *
Actually there is a way to implement dead reckoning that gets rid of the above problems. Use an encoder disk.

This has been discussed several times and I’m well aware of other solutions. However the original poster was asking about why an internal counter doesn’t work so well. When I said “a fundamental problem with dead reckoning” I guess I should have said “a fundamental problem with driving by timing loops”.

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.

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.

:smiley:

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 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.

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