1 Turning functions

Rather than sending different levels of power to each motor to implement a turn, a turnAngle
function was written. The function was based on a PI controller and took four inputs; the target
angle, the error and integral gains and the pivot variable to define the centre of the robots turning
circle.

For simplicity, positive input angles corresponded to clockwise turns and negative, anticlockwise. This
was achieved by reading the input value and assigning a multiplier of one or negative one, thereby
sending the correct direction of power to each wheel motor. The relationship between arc length,
angle and radius was utilised to determine the distance to be travelled to reach the target angle. To
make use of this relationship, the input angle was converted to radians and then passed through
equation X below, along with the radius of the robots turning circle. A do-while loop was used to
implement the PI controller until the target angle was reached.

Arc Length= Angle Radius (X)

If the pivot value was set to zero the robot would turn about its central pivot point. That is, both
wheels would receive power and the radius of the turning circle was half of the distance between the
centres of each wheel. If the input for pivot was one, the robot would turn about either of its wheels,
depending on the input angle value. That is, if a positive angle was entered, the left wheel would
drive whilst the right would remain stationary, and vice versa if a negative angle was entered.

During the project, the turnAngle function was called with an error gain of 1.2 and an integral
gain of 0.6. Use of these gains allowed for accurate turning, however the time taken for the control
loop to terminate was too long to be considered practical. To improve loop termination times, code
was added such that the effort gains were increased to allow for quicker summation of control effort,
when the error from the target angle was within ten degrees. Subsequently, the time taken to build
sufficient power to move the robot was reduced. Via testing, it was found that increasing the error
gain to 0.8 and the integral multiplier dt to 0.05, the turn angle loop would exit both quickly and
accurately. Care was taken not too increase the control effort gains by so much that integrator

Figure x, simple if
statement used to
boost gains
windup would occur.

A tolerance of two degrees was allowed as an exit condition for the do-while loop. Again, it was
found through testing, that this tolerance allowed for accurate, consistent and efficient turning.

2 Helper functions
Various helper functions were used throughout the code, and were useful for both simplifying the
code and making the logic of key functions easier to interpret. The helper functions used included;
countToDist: a function used to convert an input value, typically a wheel encoder count, and
returns the corresponding distance travelled by that encoders wheel. encoderAverage: takes the
encoder counts from both wheel encoders and returns the average of the two. averageTravelled:
uses the previous two helper functions to return the average distance travelled by both wheels. The
helper functions referred to above, combine to allow for more accurate power adjustments. This is
because the state of both wheel encoders are taken into account when determining a specified
control effort. Another helper function utilised was blackCount, this was used only in the line
follow function to determine whether the robot was positioned over a black line. The count variable
is increased by one each time a black line is encountered. The blackCount function was essential
for the success of the line follow function, because it allowed the robot to know when to engage and
terminate the line following process.

3 Reflections
On the day of the project assessment, the robot performed poorly. Inaccurate can deposit and failure
to implement line following resulted in the heaviest loss of points. Wheel slip was the cause of
inconsistent and sometimes inaccurate can placement, whilst colour limits were the downfall of the
line follow function. In the week prior to the assessment, the lineFollow function worked as per
requirement, except for the exit condition (the robot continued to follow the black line at the end of
the brown path). Within the final lab this bug was fixed, and the line follow function was working
well when tested on the practice boards. However, when it came to the video recorded assessment,
the robot froze at the brown line.

All other functions worked consistently well, however the program as a whole was let down by these
two aspects. In reflection, three key factors lead to these faults, all of which could have been
avoided. The first factor was time management. Far too long was spent coding functions or cases
within functions that had small influence on the final result. For example, the turnAangle
function was made more robust by allowing for both turning on the spot or about the robots inner
wheel, however in our program, only turning on the spot was used. Subsequently, valuable time was
wasted coding for cases that were never utilised in the run.

The second factor is that gradual acceleration of the robot was not coded for. Although the power
was heavily saturated, the total value was still sent to the motors instantly, resulting in wheel slip and
or robot lurch. Although, the turn angle function worked consistently, the sudden power increases
often lead to variance in angles turned by the robot, therefore, leading to inaccurate encoder
navigation and can placement.

Another factor that hindered robot performance was the distance travelled backwards after the can
was picked up. The distance used meant that the robot wheels aligned exactly with a join of two
board segments. When the following clockwise turn was implemented, the right rear wheel was
momentarily in a groove at the join, causing the wheel to slip before creating any movement, which
resulted an inaccurate turn. Although this was a coincidence, better time management would have
allowed extra time to make code adjustments, whilst a gradual acceleration function would have
avoided the situation all together.

It was frustrating to know that the functions worked individually, however did not combine to create
a successful run. The three factors above were the main reasons for the robots poor performance,
and are therefore what would be changed in future projects.

4 Conclusion
The vex robotics project was a valuable learning curve. Allocating time effectively was perhaps the
biggest setback that could have improved scores, whilst use of a gradual acceleration function would
be the most beneficial adjustment we could have made to our code. Although execution was poor,
the most significant issues faced and mistakes made have been identified. Furthermore, gaining an
understanding of these issues, has meant that they can now be avoided in future programming
projects.