Unbending Bender

Today I worked mostly on testing and familiarizing myself with our development robot, which we as a team named ‘Bender’. To begin the day, I began driving Bender through our various practice courses whilst only navigating using the cameras. I then proceeded to navigate through looking directly at the robot with my own eyes. This was in an attempt to better familiarize myself with how the robot moves as well as how and why it struggles to maneuver in certain situations. In doing this, it is improving my overall knowledge in regards to the robot, how it moves and its limitations. Whilst driving around, the wheel disconnected from the axle, due to the bolts securing the wheel to the axle simply not having been checked or tightened for the last little while, meaning all driving and bumps/jolts to the wheels would have slowly loosened these bolts. This was the first time bender had broken on an actual run.

A disconnected wheel was essentially the best case scenario, when I picked the robot up and out of the test course, I thought I may have burned out a motor, disconnected the axle from the motor or broken a track link. Luckily it was just the wheel which had disconnected from the axle. The fix to this problem was simply finding the right size Allen key and tightening up the screw connecting the wheel to the axle. Doing so however resulted in me having to take apart the tracks, test each motor to see if it was burned out and then tighten the screw and then re-connect the tracks. This not only fixed the problem but also improved my familiarity with the robot, its components and how it works.

Then after re-securing the wheel to the axle, I ran the robot full forward to test if it would go straight, implying all motors outputting the same amount of force, or if the robot pulled to one side, it would signify that the motors on one side were not outputting the same amount of force as the two motors on the other side. To my surprise, the robot did pull left, meaning that I thought that one motor was indeed damaged or had a loose connection, however after further inspection and consulting the teacher, Mr. Elias, we put it down to the fact that in the past, one motor had been burned out and was replaced with a slightly bigger, and more powerful one. This then explained the robot pulling to the left, as the more power motor was situated at the front right of the robot, meaning that there was a greater power output on the right side than the left, resulting in the robot pulling left.

After doing a bit more driving, it was suggested by the teacher that the course we had were checked with the standardized test track of the 2017 rules (same rules used in ‘18 and ’19). We realized that the hardest of practice courses was far harder than the one specified in the rulebook, as the flat blocks in our course were half as high as the ones in the rulebook. Although this doesn’t sound too bad, the added depth of the flat blocks meant that it was harder for the robot to get out of the hole and therefore maneuver through the course, as it was easier for the tracks to catch on other blocks. After re-arranging the course to be the same as that defined in the rulebook, the course became a lot easier for me to drive through.

Not to say that added difficulty is not beneficial, as it can help getting out of difficult situations and train the driver to cope with harsher tracks and terrain, however focusing on traversing more challenging tracks than what is specified in the rules means that more strain is placed on the robot, more jolts and impacts (and therefore damages) are taken to the robot, resulting in more time taken for repairs, more wear on parts and generally speaking more battery is utilized per run, as the terrain in more challenging to get through. Also training on tracks harder than specified in the rules can mean that you may train for situations which you never use in the competition, whereas training on the specified track can mean that you can fine tune skills needed for driving through the easier tracks which will be needed regularly and in the competition, and the increased number of reps between the easier tracks. I figured that more difficult tracks versus less challenging tracks should be considered, as more driving on less challenging tracks can be completed, however driving on more challenging tracks can make the driver more experienced in challenging situations.

To increase ability when driving backward, an alternate, rear-mounted camera was fitted, so that you could see when the robot was driving backward. This rear mounted camera will be increasingly useful in situations where you don’t want to reverse too far, the only way before to prevent this before was going slow, as the frontward facing camera had a slight delay, meaning that you heard the robot crash into the wall in the test tracks before you actually saw it on camera. A backward facing camera will be able to negate this, even with a slight lag/delay, due to actually being able to see where you are going, instead of having to guess where the other end of the robot is based off the surroundings you can see.

Connor, one of the mentors helping us, who is also part of the Major SART helped me get both the front and rear cameras displaying simultaneously on Sights, the software we use to control the robot. Getting both cameras displaying on the same screen was done by simply reconfiguring a few settings and a small amount of code, which I was unsure how to do. Since Connor made Sights however, it was an easy task for him. Sights is in End of Life (EOL), Sights 2 will make this process, along with many other processes a lot easier.