Field Navigation Speculation

By Max

Task: Determine necessities of this year's field navigation code

Today was our very first meet of the year, and as such, not too much got done other than planning and experimentation. For the greater part of the meeting, I worked on concepts for an overhauled field navigation system (Mostly for autonomous, but possibly for tele-op as well). This would include the robot knowing where it is on the field when it starts, the field's and its own dimensions, the locations of potential obstacles, and even an approximation of how far the robot may have deviated from its planned path. The best bet so far is to make locations based on a Cartesian plane (like most graphs), with one corner of the field being the origin (0,0) and the other points being established based off of it. The picture above shows an estimated list of variables as required for the robot (as well as field dimensions). This is likely a minimum, as there will definitely be a rather complex system needed to show obstacles, including linking together groups of points and making sure that both the points themselves as well as the lines between them are avoided, but without making every obstacle point attach to one another in a spiderweb of confusion.

Reflections

Although most of the team has taken several Java classes at school, this will undoubtedly be a challenge to develop. Since we also have a new physical system to work with, the development of the field control system will be time-consuming work. Regardless, with the new navigation challenge of having the field pre-loaded with debris every time, the development of the system will almost undoubtedly save time in the future that we would have spent on last year's process of fixing our autonomous by running it 5 times to work out tiny changes to single lines of code at a time, only to find more problems caused by the change. Since we know this alternative to the system all too well, At least incentives won't be a problem in getting started.