LEGO ROBOT SOCCER SOFTWARE REQUIREMENT SPECIFICATION IEEE 8301998 A

2 ROBOT HJÄLPER FORDS TEKNIKER MED ”DEN
!doctype Html html Langptbr head meta Charsetutf8 meta Namerobots
!doctype Htmlhtml Langsv Classh100headmeta Charsetutf8meta Nameviewport Namerobotsmeta Namedescription

!DOCTYPE HTMLHTML LANGSV CLASSH100HEADMETA CHARSETUTF8META NAMEVIEWPORT CONTENTWIDTHDEVICEWIDTHTITLETITLEMETA NAMEROBOTSMETA NAMEDESCRIPTION
1 GUIAS PRÁCTICAS PARA LA PROGRAMACION DE ROBOTS
1 WAS KÖNNEN ALGORITHMEN? KONTROLLBLATT FUSSBALLROBOTER 1 D ENNIS

Lego Robot Soccer Software Requirement Specification

Lego Robot Soccer

Software Requirement Specification


IEEE 830-1998



A. Introduction


A.1 Purpose

The robot soccer competition is a popular game that offers a set of challenges for intelligent agent researchers using a friendly competition in a dynamic, real-time, multi-agent domain. Here we are trying to build up a robot with MINDSTORM NXT robotics tool set and coding the robot to make it intelligent.


A.2 Scope

The robot here is only designed for one to one soccer competitions. We are trying to make the robot know what to do automatically rather than be controlled by human beings in the competition. We are trying to design a robot which has a good AI. The number of the team members will be extended in future in order to make the competition more canonicity. And there will be different tasks for each member in the team.


A.3 Definitions

A3.1 Robot: The competitor, which is controlled by pre-set program. The most important aim of it is try to make the goal without committing the rule of the competition

A3.2 Nxtbrick: the core part of the robot which can control all the action of robot either by downloaded program or by virtual controller provided by software.

A3.3 Sensor: the robot parts which are connected to Nxtbrick get the information of the conditions around the robot.

A3.4 Motor: the robot parts which are connected to Nxtbrick make the robot move.

A3.4 NXTsharp: a C# language software which provide a interface for the user can control the robot by sending the control command to the Nxtbrick wirelessly.


A.4 Reference


A.5 Overview

This document can be separated into three sections. Section A gives you a briefly introduction of the whole project. Section B talks about the general description of the whole system, like product perspective, product functions, user characteristics and so on. Section C is the most important section in the document. It will introduce you the function and non-function requirements of the project.


B. General Requirement


B.1 Product perspective

“It is an attempt to promote AI and robotics research by providing a common task. Soccer, for evaluation of various theories, algorithms, and agent architectures. ” [Kitano, et al., 1995; Kitano et al., 1997a; 1997b]


B.2 Product functions

This product is aimed at making the robot intelligent enough to attend a one to one competition without human controlling. The one who got the highest goal in a fixed time will be the winner. However you can control the robot by computer if you want to.

The interface of the controller perhaps is the key term if you focus on the robot controlling by human.

B.3 User Characteristics

The robot can know the orientation of the goal by the light sensor, know where the ball is by the ultrasonic sensor, and decide what to do next. In addition, robot can make some pre-set action if it is invoked by the touch sensor. Beside sensors, the robot also has three motors to make the robot run. The NXTbrick is the core of the whole robot, it can load the pre-set code to control the robot. Control commands may also be delivered to the NXTbrick from a PC via a Bluetooth wireless connection. This allows direct control of the robot from a PC keyboard by a human operator. In this case, you can write code by yourself and put them into software like NXTsharp to modify the interface (virtual controller). This kind of open source software will allow you to control all the sensor parts and motor parts via Bluetooth.


B.4 Constraints

There exist severe memory limitations with the NXTBrick. Large programs cannot be downloaded into the NXTBrick. The virtual control panel provided by NXTsharp is the solution to this specific constraint.

In so much as this competition is considered to be a soccer competition, competitors should also be held to the rules of said game where possible. Ball handling, fouls, time-outs, and the like should conform to the game of soccer.



B.5 System dependency and assumptions

The system can only use in a especial area. The robots must scan the especial flag in the area by light sensor, ultrasonic sensor, etc. However, you can also use the system in un-special area, if the robot which we will develop in the future would be enough intelligent.


C. Specific requirements


C.1 External interface requirements

CLEGO ROBOT SOCCER SOFTWARE REQUIREMENT SPECIFICATION IEEE 8301998 A
.1.1 User Interfaces

Visibility of system status

The system should always keep users informed about what is going on, through appropriate feedback within reasonable time.

User control and freedom

Users often choose system functions by mistake and will need a clearly marked "emergency exit" to leave the unwanted state without having to go through an extended dialogue. Support undo and redo.

Error prevention

Even better than good error messages is a careful design which prevents a problem from occurring in the first place. Either eliminate error-prone conditions or check for them and present users with a confirmation option before they commit to the action.

Aesthetic and minimalist design

Dialogues should not contain information which is irrelevant or rarely needed. Every extra unit of information in a dialogue competes with the relevant units of information and diminishes their relative visibility.

Help users recognize, diagnose, and recover from errors

Error messages should be expressed in plain language (no codes), precisely indicate the problem, and constructively suggest a solution.

Help and documentation

Even though it is better if the system can be used without documentation, it may be necessary to provide help and documentation. Any such information should be easy to search, focused on the user's task, list concrete steps to be carried out, and not be too large.


C.1.2 Hardware Interfaces

The Bluetooth contains all necessary hardware toe run a completely self-contained Bluetooth node. The main NXT Processor that controls our use interface provides drivers for peripherals and runs user code.

Control Signals

Reset: Active low signal initiated by the ARM7 that reset the Bluetooth Chip.

ARM7_CMD: Active high signal that signals the state of the UART channel seen from the ARM7. Input at BlueCore PIO(11).

BC4_CMD: Active high signal that signals the state of the UART channel seen from the ARM7. Output at BlueCore PIO(10).

SPI Interface

The SPI enables firmware updates of the BlueCore chip through CSR’s DFU-algorithm. The SPI signals are shared with the display.

UART Interface

High-speed full-duplex interface with handshake signals. UART settings used both in stream and command modes:


C.1.3 Communications Interfaces

C.1.3.1 Click on the appropriate checkbox to enable the functionality that you wish to use in the Lego NXT. Enabling a particular section will start the correspondence between your PC and the NXT brick. This will increase the Bluetooth traffic and can slow down the reaction time that your Lego NXT will take so be sure to only enable those parts that you need.


C.1.3.2 The motor control variables can be specified by either using one of the existing variables provided in the dropdown list or by typing in a new variable. Once you select a variable you will not be able to manually adjust the motor bar as it will now respond to the value within the variable. Be sure to select the appropriate minimum and maximum values to ensure that the variables do not exceed the motor limits. Note that the values for the motors range from 0 to 255 with 128 being neutral.


C.1.3.3 If you would like to receive information about the rotation of the motor (aka encoder values) then select the rotation checkbox and specify the variables that should contain the values sent by the encoders. If you enable this area and then move the motor by hand you will notice the value field change in accordance to the rotation of the motor.


C.1.3.4 The NXT has several different kinds of sensors. You need to let RoboRealm know which kind is attached to which port. To do so simply select the appropriate dropdown to indicate the type of sensor attached to the port. Then select the variable or type in a new one that is meant to receive the value of that sensor. Be sure to click on the checkbox above the Sensor group to enable reading of sensors. Note that the current sensor value will be shown in the right hand box.


C.1.3.5 If at any time you would like to STOP the robot press the stop button (this can save many crashes). Pressing start will re-enable the motors and reactivate communication with the NXT robot.


C.1.3.6 Communicating with NXT G-Programs

You can use RoboRealm to communicate specific values from the PC to a running program within the Lego NXTbrick. The reason one would do this would be to communicate a specific condition that RoboRealm has picked up on (for example seeing a large red cup) so that the G-Block program can change its behavior based on this information. In this manner RoboRealm is acting like an additional sensor that can be tested for specific conditions.


C.1.3.7 Receiving

The way this communication occurs is by using the Lego NXT Mailboxes. These are akin to the "Variables" known in the Lego Mindstorms RCX system (the former Lego system). You will need to add in the G-block "Receive Message" (yellow square menu) to receive messages sent from RoboRealm. In this Block you will have to specify the type of data to be received and which mailbox the message will be received in. The mailbox number MUST correlate with the same mailbox number seen in the mailbox list on the right side of the RoboRealm Lego NXT interface. If these numbers do not match, no values will be received in the correct mailbox. In the RoboRealm interface, specify a variable name (NOT TEXT) in the dropdown/text editable box. RoboRealm will only transmit the contents of variables so be sure to specify a variable that has some content in it. If you are just testing the communication you can select the IMAGE_COUNT variable which will increment by one for each image being processed. Also be sure to select "send" radio button in the RoboRealm interface so that RoboRealm knows to send the contents of the specified variable to the Lego NXT.


C.1.3.8 Sending

To send a value from the Lego NXT back to RoboRealm you can add in the "Send Message" G-Block within the Lego programming interface. You MUST specify the 0 Connection in that G-Block's options. 0 means that when the NXT is acting in slave mode it should buffer the sent messages in outgoing mailboxes that the PC can request the contents of. You can then type in the message and the mailbox that should be used to send the message. Again, the mailbox MUST match one of the mailboxes in RoboRealm and a variable MUST be specified in the RoboRealm interface that will receive this value from the NXT. Note that your NXT must be in slave most with respect to the PC for this to work. In other words, allow your PC to first connect to the NXT rather than use the NXT to connect to the PC. Since the PC is not another NXT the connection option needs to be set to 0 which allows for master/slave communication.



C.2 System features


C.2.1 Light Sensor Module

C.2.1.1 Introduction/Purpose of feature

NXT get the location of goal by light sensor in the robot. It is very important for the NXT to get the exact location of the goal in getting the points.

C.2.1.2 Associated functional requirements

C.2.1.3.1 Scan the enemy goal location by light sensor

C.2.1.3.2 Calculate the distance and angle between robot and rival’s goal


C.2.2 Ultrasonic Sensor Module

C.2.2.1 Introduction/Purpose of feature

The robot can get the location of the ball by ultrasonic sensor, and calculate the upright angle and distance between the ball and robot, and execute an order.

C.2.2.2 Associated functional requirements

C.2.1.3.1 Get the location of the ball by ultrasonic sensor

C.2.1.3.2 Calculate the upright angle and distance between the ball and robot

C.2.1.3.3 Get the location that robot should move

C.2.1.3.4 With light sensor data getting robot’s crank

C.2.1.3.5 Execute turning and moving


C.2.3 Touch Sensor Module

C.2.3.1 Introduction/Purpose of feature

Robot can deal with the event by touch sensor. When robot touches an object, he will bump it once, if the distance got by ultrasonic sensor is not zero the object is not a ball, then the robot will turn right (90 degrees) and go ahead.

C.2.1.2 Associated functional requirements

C.2.1.3.1 When robot touches an object, he will bump it once

C.2.1.3.2 Check the object is either a ball or another

C.2.1.3.3 If the object is not a ball, turn right (90 degrees) and go ahead


FLEGO ROBOT SOCCER SOFTWARE REQUIREMENT SPECIFICATION IEEE 8301998 A
igure C.2.1.3.3

C.3 Performance requirements

Only one individual may control the robot during the match.


C.4 Design constraints

The system can only be used in a special area. The robots scan the special flags in the area with light sensor, ultrasonic sensor, etc.


C.5 Software system attributes

The software system is applied for MINDSTORM NXT robots. Robots will be used in soccer competition. The software will be developed by Microsoft Visual Studio 2005.


C.6 Other requirements

N/A
















Project Development Plan

(List of Tasks, Timeline, and Milestones for each member)


Purpose:

Produce robot(s) from Lego boxed set to complete in the following competitions:

  1. Soccer competition

  2. Map Explorer competition


Team Members:

Jiangchuan Wang (Chase) -- Programmer & Team Lead

Guanting Tang --------------- Programmer & Milestone I writer

Taiheng Jin (Jackie) ---------Web Designer

Weijun Cheng (Frank) ------ Negotiator & Technical writer

Richard Brown (Rich) ------ Programmer & Milestone I writer


Timeline:

Days 1-2 -- Pre-Design

Days 3-6 -- Design

Days 7-10 -- Build

Days 11-16 – Test

Day 18 -- Competition


Stages:

Pre-Design – Days 1 & 2 -- Team, parts

Design – Days 3-6 -- Bots, Rules, Software Scheme

Build – Days 7-10 -- Bots, load software

Test – Days 11-16 -- Bots (modifications), software modifications


Pre-Design: (Days 1 & 2)

Inventory and familiarization with Lego boxed set

Classify and separate parts

Decide initial software platform

NXT or Microsoft

Divide team members into specific tasks

Determine work location and install computer

Set-up team meeting schedule


Design: (Days 3 to 6)

Determine play fields and rules

Produce initial task sets, timeline, and member milestones

Basic body designs for each competition



Soccer Bot:

Ball control methods and mechanisms and parts associated

Any other offensive mechanisms and parts associated

Any defensive mechanisms and parts associated

Determine software function concepts


Map Explorer:

Any physical changes from soccer competition design

Remove ball control mechanisms, if any

Remove defensive mechanisms, if any

Add external bumpers

Determine sensor placements

Determine software function concepts


Design (Rules):

Bot size limits

Ball handling Restrictions

Aggression Restrictions

Goal defense Restrictions

In-game Bot modification Restrictions


Design (software):

Select software platform/package (NXT or MS)

Install on selected single computer

Determine software properties

Coding

Up-loading to Bot

Transmission issues

Code functions and methods

Offensive and Defensive strategies


Build (Bots, Load coded algorithms): (Days 7 to 10)

Build basic body design concepts to working configuration

Check stability and durability

Build ball control devices to working configuration

Check functionality and durability

Build defensive mechanisms to working configuration

Check functionality and durability


Model basic body designs (both competitions)

Test for stability and durability

Select and produce final basic body design


Model ball control devices (soccer)

Test functionality and durability

Select and produce final ball control device(s)


Model defensive mechanisms (soccer)

Test functionality and durability

Select and produce final defensive mechanism(s)


Model any changes to basic body design used for soccer competition (map explorer)

Test functionality and durability

Test speed to make said changes

Is change practical during competition???


Model sensor placements (map explorer)

Test functionality and durability

Test speed to make said changes

Is change practical during competition???


Model any additional add-ons (map explorer)

Test functionality and durability

Test speed to make said changes

Is change practical during competition???


Load software functions and methods (map explorer)

Test load times, functionality, and accuracy of algorithms


Web page design initialization

Initial page development

Upload and update of team progress journal

Upload “work in progress” images of team efforts

Care given to not revealing any secret team information


Test (both competition design builds): (Days 11 to 16)

Test soccer Bot design in competition environment

Ensure functionality and stability over entire field

Ensure mobility and ball control meet design concepts


Test map explorer in competition environment

Ensure functionality and stability over entire field

Ensure software code and algorithms meet design concepts in competition environment


The testing phase will normally entail re-works of designs. It is generally left open and flexible due to the large number of potential faults, defects, or failures that might or might not be envisioned. All mechanisms of all designs must be tested, preferably to failure to learn operational envelope. Sufficient time must be available for major re-works of designs should such conditions arise. At the least, new potential designs and functions will become apparent and should be tested for inclusion.


Web page building continuation

Page construction completed through all pre-competition phases

Remaining competition images, results, and documentation added post-competition


Team Members & Milestones:

Jiangchuan Wang (Chase) - Programmer & Team Lead

Pre-Design – End of Day 2

Ensure completion of Pre-design list of tasks

Design – End of Day 6

Ensure completion of Design list of tasks, load necessary software, and oversee construction of algorithm design

Build – End of Day 10

Ensure completion of Build list of tasks, program coding, and algorithms

Test – End of Day 16

Ensure completion of Test list of tasks and ensure functionality of robot

Post-competition – End of Day 18

Oversee completion of web page and all technical documentation through post-competition


Guanting Tang - Programmer & Milestone I writer

Pre-Design – End of Day 2

Assist with Pre-design list of tasks and complete sections A, B, & C of project 6 Milestone I documentation

Design – End of Day 6

Assist with Design list of tasks with special attention to algorithms and software coding

Build – End of Day 10

Assist with Build list of tasks

Ensure functionality and accuracy of algorithms

Test – End of Day 16

Assist with Test list of tasks giving special attention to software and algorithms

Taiheng Jin (Jackie) -Web Designer

Pre-Design – End of Day 2

Assist with Pre-design list of tasks

Design – End of Day 6

Assist with Design list of tasks and begin initial web page design and development

Build – End of Day 10

Assist with Build list of tasks and continue web page development

Test – End of Day 16

Assist with Test list of tasks and complete all web page construction through all pre-competition phases

Post-Competition – End of Day 18

Complete and finalize web page


Weijun Cheng (Frank) - Negotiator & Technical writer

Pre-Design – End of Day 2

Assist with Pre-design list of tasks

Design – End of Day 6

Assist with Design list of tasks, set play field specifics, and set initial rules set

Build – End of Day 10

Assist with Build list of tasks and finalize rule set

Test – End of Day 16

Assist with Test list of tasks and compile and finalize all technical documentation through end of test phase

Post-Competition – End of Day 18

Finalize all technical documentation through end of project


Richard Brown (Rich) - Programmer & Milestone I writer

Pre-Design – End of Day 2

Assist with Pre-design list of tasks and complete sections D & E of project 6 Milestone I documentation

Design – End of Day 6

Assist with Design list of tasks with special attention to algorithms and software coding

Build – End of Day 10

Assist with Build list of tasks

Ensure functionality and accuracy of algorithms

Test – End of Day 16

Assist with Test list of tasks giving special attention to software and algorithms


14 LAPORAN HASIL PENELITIAN INDIVIDU ANALISIS INFRASTRUKTUR ROBOT LINE
2 A ROBOT DOG A ROBOT DOG BY CLARK
2 KOD CPV 454530007 ROBOTY REMONTOWE I RENOWACYJNE ST


Tags: 8301998, software, soccer, specification, robot, requirement