Software Strategy

-= Maximizing Customizability =-

Having recognized the likelyhood of a lengthy testing and tweeking process, the team knew a customizable software structure would be a purdent design goal and strategy. In particular the Lego Mindstorms lacks the features of object oriented and functional programming languages which provide simple and powerful methods for modifing code. As a result the structure of the program should provide a means to easily tweek the code without much redesign of the program structure. Dividing the functions of the robot into sub groups would assist this process. In general wherever possible seperate code which handles input from the environment from the code that handles the output as well as from the code that handles the control.

The major outputs of RoboPele would be the speed and timing of the robot-ball collision. To accomodate these outputs initally two variables were taken into consideration. The amount of time after the speed was measured, a delay before the robot starts moving, as well as the speed at which the collision should occur. The first allows for proper timing of the collision, the second allows for the correct reaction angle after collision.

Interestingly, initial trials found that if RoboPele waited until the second sensor was triggered it was incapable of collision with a fast moving ball. Therefore a feedback loop was introduced into RoboPele's software to accomadate this problem. The feedback loop was quite simple, essentially RoboPele's cart would begin moving as soon as the first sensor was triggered and would stop if the cart had traveled a set distance before the second sensor was triggered. The cart would continue its normal behaviour after the second sensor was triggered. The end result was a cart that could correct its timing depending on the speed of the ball.

 

[prev|up]
[guide|design|hardware|software]