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

“IEEE Recommended Practice for Software Requirements Specifications” (830-1998)

Hiroaki Kitano, Minoru Asada, Yasuo Kuniyoshi, Itsuki Noda, Eiichi Osawa.“RoboCup: The Robot World Cup Initiative”

Hiroaki Kitano, Minoru Asada, Yasuo Kuniyoshi, Itsuki Noda, Eiichi Osawa, Peter Stone, Manuela Veloso, Silvia Coradeschi, Hitoshi Matsubara. “The RoboCup Synthetic Agent Challenge 97”

“LEGO MINDSTORMS USER GUIDE”

“LEGO MINDSTORMS NXT ARM7 Bluetooth Interface Specification”

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 etal., 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, therobot 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 deliveredto 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 limitationswith 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

C.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:

460.8K Baud

8 bit

No Parity

One stop bit

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.2The 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.7Receiving

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.8Sending

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

Figure C.2.1.3.3

C.3 Performance requirements

Only one individualmay 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 insoccer 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)