Navigation: The Importance of Knowing Where You Are
90% of the issues with this competition had to do with navigation. Once you figured out how to drive fairly precisely, and efficiently, to wherever you wanted the game was a lot simpler.
Our first attempt at navigation combined position from the Vision Position System (VPS) for overall positioning and wheel encoders mounted on the driven wheel shafts for shorter distances. Combined we had a reliably functioning, though not always efficient, navigating robot. However, something that worked so consistently couldn't possibly exist for this team. In the third week, the encoder mounts in the center of the robot indicated that they were tired of the abuse and jumped into the gears causing massive issues with simply moving at all.
Following this outright declaration of defeat, we tried many variations of a single follower wheel with no further success. Our final attempt got rid of encoders completely, putting our trust nearly completely in the VPS.
In the code this meant major changes, we deleted functions meant to monitor distance by encoder tiks and bravely went where we dared not go before: the PID library. Using a mashed combination of distance calculations, gyro readings and carefully constructed time outs, the new navigation code drove to given points within a given accuracy allowing us to drive through territories and drive to specific points using the same function.
Like every other team that struggled with being a lost robot, once we got our navigation figured out, the strategic issues became much, much more manageable.
Our first attempt at navigation combined position from the Vision Position System (VPS) for overall positioning and wheel encoders mounted on the driven wheel shafts for shorter distances. Combined we had a reliably functioning, though not always efficient, navigating robot. However, something that worked so consistently couldn't possibly exist for this team. In the third week, the encoder mounts in the center of the robot indicated that they were tired of the abuse and jumped into the gears causing massive issues with simply moving at all.
Following this outright declaration of defeat, we tried many variations of a single follower wheel with no further success. Our final attempt got rid of encoders completely, putting our trust nearly completely in the VPS.
In the code this meant major changes, we deleted functions meant to monitor distance by encoder tiks and bravely went where we dared not go before: the PID library. Using a mashed combination of distance calculations, gyro readings and carefully constructed time outs, the new navigation code drove to given points within a given accuracy allowing us to drive through territories and drive to specific points using the same function.
Like every other team that struggled with being a lost robot, once we got our navigation figured out, the strategic issues became much, much more manageable.
Multiple Files
In a effort to try to keep our code neat and readable, we decided to split up the code into four different files grouped by functionality.
In Navigation.c you will find all of the functions we used to move the robot from a given point to another given point. The main idea of placing navigation code in a separate file was that many of the helper functions we needed used one variable that was defined outside of any one function. In order to protect these variables (rightVel and leftVel) we separated the navigation code and created a function to change these values if we ever needed to access them from another file.
In Gather.c we placed the code dealing with moving around the field without crashing into walls (we used way points located in each section) as well as the code needed to get sheep from a territory. By keeping all the code together, we only needed to call one function in the main file (umain2v2.c) to capture and gather sheep from a territory.
Deposit.c was created for symmetry in organization with the rest of the code (it's always good to be consistent). It contains the code for dumping the balls in the correct city.
Finally Strategy.c contains the beginnings of our game strategy. It's a fairly basic strategy ranking the territories by desirability based on number of balls remaining, distance from the robot, distance from the opposing robot, and current owner of the territory.
In Navigation.c you will find all of the functions we used to move the robot from a given point to another given point. The main idea of placing navigation code in a separate file was that many of the helper functions we needed used one variable that was defined outside of any one function. In order to protect these variables (rightVel and leftVel) we separated the navigation code and created a function to change these values if we ever needed to access them from another file.
In Gather.c we placed the code dealing with moving around the field without crashing into walls (we used way points located in each section) as well as the code needed to get sheep from a territory. By keeping all the code together, we only needed to call one function in the main file (umain2v2.c) to capture and gather sheep from a territory.
Deposit.c was created for symmetry in organization with the rest of the code (it's always good to be consistent). It contains the code for dumping the balls in the correct city.
Finally Strategy.c contains the beginnings of our game strategy. It's a fairly basic strategy ranking the territories by desirability based on number of balls remaining, distance from the robot, distance from the opposing robot, and current owner of the territory.
Puzzling Errors
As accompanies any robot project with fairly inexperienced coders, there are plenty of puzzling errors.
These were three of our best:
-Error: The robot wouldn't run any code Cause: not enough battery power (we didn't have the motor battery yet)
Solution: Hold down the 'Go' button while powering on the happyboard.
**CAUTION: only do this for logic code, like printfs- don't try to run motors**
-Error: uint8_t not recognized Cause: not including joyos.h
-Error: Stack Overflow- not consistent and shows up after printing 'dri' of a printf statement intended to be 'drive Feet' Cause: Unkown. really. Please help us if you ever figure it out. :D
These were three of our best:
-Error: The robot wouldn't run any code Cause: not enough battery power (we didn't have the motor battery yet)
Solution: Hold down the 'Go' button while powering on the happyboard.
**CAUTION: only do this for logic code, like printfs- don't try to run motors**
-Error: uint8_t not recognized Cause: not including joyos.h
-Error: Stack Overflow- not consistent and shows up after printing 'dri' of a printf statement intended to be 'drive Feet' Cause: Unkown. really. Please help us if you ever figure it out. :D