After being inspired by team 1717 from 2007, and also from looking at a RI3D team, we started work on what we call project “Butterfly”. It’s the idea that we will be able to carry two robots with us on the way up for when we climb. We built our first Proof of Concept today, and we found out that there was a lot of weak points at the corners/wherever we used a gusset. Our plan for tomorrow is to remove all of these week points by replaced it all with solid quarter inch plate, and adding triangle braces to the spots that are inside of the bumper. We will be redoing a lot of this prototype tomorrow.
Because Sagas are “Long Stories”
Ritik investigated the code for 15 minutes. The first issue was an issue of “circular reliance”, if you will. A variable was being assigned a value given by a method, which itself used the value of the variable. At the very beginning of the pure pursuit, this variable would be null, as it would not be assigned a value. Once this code was tested, the robot jerked before another
Ritik thought it was another instance of a variable not being initialized to a value; rather, a variable was being assigned a value from a method which happened to return null. In particular, this variable stored the location of the point that the robot should drive towards. Since the robot was too far away from the path, the method got confused and returned null. Ritik worked around this issue by changing the location estimator to use the encoders and changing the path from a complicated turn to a straight line.
This time, the robot drove in a straight line, and didn’t stop until disabled. However, when the path was changed, the robot would jerk around, and wouldn’t stop until disabled.
After some deliberation, Isaac Ash decided to look at the encoders. After all, if something was wrong with the encoders, then the robot cannot know where it is, and therefore will get confused.
2 things were wrong with the encoders
- The wire of 1 encoder had been slaughtered by the merciless drivetrain chain
- The code assumed that the other encoder was a different type of encoder.
These issues were fixed, the code was deployed, and the robot was enabled.
To be continued
After installing the right mag encoder yesterday and finally having two mag encoders working, the left mag encoder was very nice and suddenly gave 0 input. The wires were all connected. We then attempted to flash the talon, but the Microsoft Silverlight web server was not displaying anything — not even one single talon. After getting tired of trying to fix it with successive restarts/reboots of the RoboRIO, robot, and web server, we left for a short period of time. When coming back, it magically fixed itself. ¯\_(ツ)_/¯
Also navX was “interesting”. Due to (probably) magnetic fields from the motor, the navX thinks the robot is at a pitch of ~33 degrees, and is about 20 degrees off when doing a full rotation when getting yaw values.
We are now using GitHub Issues for a variety of different purposes, including (but not limited to) bugs, electrical problems, and ideas. If there is something you want to see happen (or don’t) include it here!