Quote:
Originally posted by Joe Johnson
I have heard a lot of folks say they are using "dead reckoning."
Having seen them work so well in Ypsilanti, I am especially curious to learn what team Rush (#27) means by the term. It is hard for me to believe they could be as repeatable and effective as they were by using just time, but I admit I have been wrong once or twice in the past.
Joe J.
|
Hey Joe. I am not the programmer, just the designer/fabricator/machinist/whatever needs to done guy. I donot know all the particulars of the code, but the way we define dead reckoning is this. We have a segment disc (4 Black, 4 White segments) attached to both the front wheels and use a Banner sensor for each. We have the program set to drive x direction so many "transitions" then change direction, drop the arm and scream forward so many "transitions". I believe it is something similar to how the Chiefs count the number of rotations on the Bosch motor. Although you guys have a higher precision sensing device.
The Electronics and Programming sub teams had discussed using some sort of encoder to keep track of the wheel poisition, but decided it was simpler to use the Banner Sensor. Granted you have some variation in the precise postion of the 'Bot due to carpet adhesion, battery voltage, initial machine position, but how close do you have to be? After all, we are not trying to dock the Space Shuttle. Our method has been consistant. As in most anything, consistantcy is the key. And believe it or not, we were really concerned before the season started with FIRST giving us the EduBots and the sensors a month early. We knew they would have something complicated for us to do. We did not want to be the ones left out in the cold, not knowing how to apply the sensor technology to the game. So we went to work for the next 10 weeks, exploring how Banner sensors worked and what code you needed to write to make the 'bot do what we wanted it to. I think we took our biggest weakness and turned it into one of our best strengths.