./Blog

Robot Movement

This week the team practiced moving the robot around in 2D space. Key takeaways:

• How to use yaw measurement to make turns
• How speed affects accuracy
• How to deal with sampling rate “errors”

For using the yaw measurement, the team created a pattern that would reset the yaw angle to 0, then start the turn hard right (100%) until the desired angle was found. This was placed in a loop, and it was fun to watch the team determine how to have the robot complete circuits of equilateral polygons of varying sides, simply by increasing the iterations of the loop and adjusting the target angle of the turn to be 360 / number of sides (originally 4 sides and 90 degrees, ending with 20 sides and 18 degrees). I think a good challenge for the team in the future would be to create a “My Block” for a polygon circuit that accepts the number of sides and does the angle calculation as part of the block.

Initially the team wanted to push the speed to 100%, but they all saw how that affected the accuracy of the turns. Ultimately they found that around 30% was a good compromise of speed and accuracy. Some alternate strategies for the team to allow for more speed were to leverage acceleration/deceleration and/or using overall angle measurements, rather than resetting to a new baseline after each iteration of the loop.

The first iteration of the program not only went too fast for accuracy, but also relied on an “equals” operator in order to determine when to stop turning. This combination would occasionally result in the robot turning one or more full turns before recognizing the desired angle. To make the program more resilient to sampling rate errors (missed measurements) and more efficient, the team created an “or” comparison, with an “equals” on one side, and a “greater than” on the other. The end result is the same as “greater than or equal to” in many programming languages, which allowed for quick recovering from a missed measurement.