General
This section describes a few technical decisions. All decisions are supported by a rationale or by references to appropriate authoritative publications, showing that the student has carefully considered different design options.
Extract:
Laboratory report: designing a robot football control algorithm in simulation
Laboratory report: designing a robot football control algorithm in simulation
A basic controller was provided with the robot football system and was used as a template. Although the template controller initially utilised random behaviour it still proved useful as it had already configured all system inputs and outputs and distinguished between robots using team colour and identification numbers from 1 to 3. The controller was programmed and developed using the C++ programming language. However, any other third party programming software could have been used, via the TCP/IP development environment software in WebotsTM. The controller represented the orientation of the robots ranging from zero to p and zero to p. This was immediately altered to provide an orientation ranging from zero to 2p. The orientations of the robot, after alterations, relative to the pitch are shown in Figure 5, and were identical for both the yellow and blue teams' robots. The pitch co-ordinate system was also identical for both teams with the centre of the pitch having a co-ordinate of (0, 0).
With no constraining rules as to inter-controller robot etiquette, any strategy used to get the ball into the opposition controllers' goal is viable. A behaviour-based control architecture was selected to design the system controller as the robots are required to react as fast as possible to changes in the environment. In fact, this control architecture has also already been shown by Lund and Pagliarini to successfully control a multi-robot football system. Golderg and Mararic show how avoiding collisions with other robots increases both the robot distance travelled and hence time needed to complete the robots' task. Therefore, as the robot football robots will not be damaged by collisions, no avoidance shall be required, which also allows the fastest and most efficient robot behaviours to be achieved. The high-level system behaviours required by such a robot football system are shown in Figure 6. The controller started from the bottom-up, with an initial collection of reactive rules and basic motor operation behaviours being developed. New more complex capabilities were then introduced by implementing the task-specific behaviours, as shown in Figure 6. Incremental design and continual testing and debugging was utilised throughout the development of the behaviour-based controller. This is in contrast to classical AI controller development, which favours the development of each module independently. Additional modules developed for behaviour-based systems must always be designed whilst keeping the entire system in mind.
As the robots have perfectly flat modelled edges, complex trajectory motions whilst retaining ball control was impossible. Altering the robot trajectory purposely towards the goal, whilst pushing the ball, would almost certainly cause the ball to roll off the robot's forward facing edge. This lack of goal orientated trajectory motions resulted in the robot following the ball until it was jammed against any of the environment constraining edges, unable to get free, as shown in Figure 8. This situation occurred repeatedly and highlighted the need for a means to free the ball in this situation. The free stuck ball behaviour was developed for this reason. Another solution would have been to explicitly represent the goal in the controller as shown by Maes . This however, is not achievable with purely behaviour-based control architecture and would require additional high level-intelligence. It would also require a trade off between the robot's planned behaviour and the robot's reactivity.
Quality: Voice
This description of the programming approach is written appropriately in the passive, third person voice ("was provided", "was used", "proved useful").
When describing experimental results, it is appropriate to use the past simple tense. However in this case the word "were" should have been used, to agree with the complex motions which are the subject of the sentence.
When wishing to state something with certainty, expression such as this can be used. Other appropriate synonyms are "definitely" or "undoubtedly".
Function: Analyse
This is an example of a methodological report being enhanced by consideration of alternatives - in this case the potential to use a range of programming languages to support the same approach.
Decisions taken about programming approach are justified by reference to previous work.
Expressed as a general rule, this sentence actually describes an important implication of the choice of method. This is an example of how a well written description can include elements of analysis and generalisation.
The reasoning for a design decision is clearly and economically provided.
This section describes a problem with the software. The student effectively analyses why this problem occurred and suggests a possible solution, together with reasons why this was not implemented in this case.
Function: Describe
Often, when reporting technical details, one is tempted to use bullet points to list the components of a system. However, a flowing text always reads better and it can allow the inclusion of more explanatory detail, for example why one approach has been chosen above another. This is a good example of how a technical methodology can be reported in fluent text.
An alternative approach is described in case an informed reader is wondering why it was not used in this case. This is a sophisticated approach to description of a method.
This is a nice example of textual description working together with a simple figure to help the reader to understand how the system is put together.
When reporting a programming exercise, it is always a good idea to include screen shots of the work. It is important to describe what the screenshot shows, both briefly in the figure caption and more extensively in the text. As here, an image can convey far more design information than text alone.
Quality: Structure
If there are figures in the report they should be referred to in the text by number, as has been done here. The figure when it appears should be captioned with enough information to make sense of it apart from the main text. Care has been taken to make this figure clear and appealing. It provides information about the orientation of the robots which would be difficult or lengthy to describe in text alone.
Quality: Authority
When using the results or the ideas of others, it is important to name them and provide enough detail for a reader to find the specific results or ideas that have been used. The reference here shows how it is done using a numbered reference system, common in scientific and technological writing.
