To assist the vision processing, changed the background from black to green, so as to contrast more effectively with red (thanks to the advice of our advisor). This helped make the angle detection both consistent and accurate.
Making the robot move was trivial. Making it move at a given
accelleration was possible. More difficult is retrieving its
velocity. Unfortunately, it was determined that the robot could only
know what velocity it had been asked to achieve, not what its current
velocity is. (This may not actually be the case, but this was all we
were able to find; someone with more knowledge of the API may be able
to correct us (or confirm that there is no way)). To solve this, we
simply calculated its current velocity as:
v = v_old +
acceleration * time_elapsed
We also discovered that the robot's pivoting, unpowered third wheel would rotate as the robot changed directions while moving back and forth. This eventually led to the robot drifting off course. While this was not critical, it was an annoyance. This problem was solved by the judicious application of duct tape.
Calibration was done by hand. At the beginning of every run, the robot would prompt for the pendulum to be moved to vertical. We did so (with the aid of a level). The robot then measured the angle, and used that value to help determine vertical in future measurements. (Recall that this is necessary because the camera is tilted.)
The feedback-controlled system was implemented. Future students who use the Evolution platform may be interested to know that Evolution provides a templated matrix class. The team was thus narrowly averted from having to exercise their amazingly rusty C++ class-making and operator-overloading skills. When tested without actually activating the motors, the system performed as expected.
Given that each individual unit worked, we expected the system as a
whole would work, as well. Unfortunately, this proved not to be the
case. Each sub-system's delay was, in isolation, managable; however,
the combined delay was substantial. After we discovered this, we did
some testing, and determined that the system spent its time in the
following ways (rounded, units in seconds):
0.23 - Acquiring the image
0.17 - Activating the motor
0.07 - Determining the pendulum angle
----
0.47 - Total delay
As can be seen, the entire system was running at approximately 2 Hz.
This was, as might be guessed, infeasably slow. All attempts to speed
up the system were stymied by the fact that the camera could not be
sped up. An alternative method of activating the motors proved to be
slightly faster (0.11 rather than 0.17), but this did not particularly
help. No attempt was made to optimize the angle determination, as it
was the least time-consuming piece of the system.
Fundamentally, we believe that the system, as it stands, is infeasable (empirical evidence would tend to support this conclusion). The following things or combination thereof may result in a successful system:
The other moral to be drawn from this project is:
Don't wait until the night before to integrate the
separate components!
Had this wisdom occurred to us, we may have had time to redesign the
pendulum, investigate more deeply into the robot's operation, etc. As
it was, we were only able to frantically try to get it working as it
was, with results that have already been mentionned.
If future projects are able to overcome the obstacles previously mentionned, it should be pointed out that the next barier that will occur is the motors' ability to accelerate. That is, they have a maximum acceleration rate, which determines the maximum deviation from vertical that is recoverable. So, even with 0 delay, the robot could not recover from, say, a greater than 40 degree tilt. "40 degree" should be no means be taken as an authoritative answer; since we were blocked by challenges that prevented us from reaching this limit, we had no particular need to determine the maximum tilt.