System Design Document
Laboratory 5
Revision 1
Groupof Destiny
CS 340
Group19
May 7, 2007
INTRODUCTION
HIGH-LEVEL SYSTEM ARCHITECTURE DESCRIPTION
Stakeholders
System Lifecycle
System Architecture
SOFTWARE ARCHITECTURE DESCRIPTION
High Level Description
Graphical User Interface (GUI)
Backend
Message
Message Generator
Message Handler
Log
Concurrency Description
UML STATIC CLASS DIAGRAMS
UML SEQUENCE CLASS DIAGRAMS
C# CLASS INTERFACES
Approval Sheet
Statement
Pledge
Statement
Revision History
Draft 0Rough draft of document created. 3/16/07.
Draft 1Draft updated with UML and interfaces. 3/19/07.
Draft 2Overhauled document completely. Loosely kept original layout. 3/24/07
1
System SpecificationsLaboratory 02
INTRODUCTION
The aim of this document is to provide a description of the system design sufficiently detailed so that it can serve as the basis for future implementations. The document will describe the system architecture and the software architecture at a high level of abstraction, and then progressively detail the subcomponents of the software architecture. In so doing, various UML diagrams will be presented, as well as other diagrams; and, certain C# interfaces will be provided when it is thought they can give a useful and concrete impression of the design.
HIGH-LEVEL SYSTEM ARCHITECTURE DESCRIPTION
Stakeholders
Before a description of the high-level system architecture is presented, it is useful to recall the staekholders of the project. These are primarily the CS 340 groups 19 and 20, the developers of the remote control station, the remote debugging interface, and the onboard system; the CS 340 staff, who will grade the project and represent the customer and the upper management; and, any potential end users of the system.
System Lifecycle
The system is being developed for the CS 340 Robot Games, to be held in May of 2007.
System Architecture
The system includes a remote control center, a remote debugging interface, an onboard system, a communication protocol, the ER1 Robot and hardware, and a desktop machine for the remote control center and debugging interface to run on. For a graphical description of how these components will interact, see Figure 1 below.
(Figure 1: System Architecture)
The remote control center and debugging interface will run on a desktop machine, remote from the ER1 Robot and hardware. Communication between the desktop machine and the ER1 Robot and hardware will occurr over several sockets and will proceed as described in the Communication Protocol. The remote control center is responsible for accepting input from a user and sending control commands based on that input to the onboard system. The onboard system will then be responsible for taking these messages and relaying them to the ER1 Robot in a form which the latter will recognize. The onboard system will run on a laptop situated on the ER1 Robot and which communicates with the ER1 Robot and hardware.
SOFTWARE ARCHITECTURE DESCRIPTION
High Level Description
The main components of the software architecture are a control and communications layer; the control layer consists of the graphical user interface and the associated backend, and the communications layer consists of a message handler system, a message generator system, and a logging system. For a graphical representation of their interaction, see Figure 2 below. These components are described in more detail below.
(Figure 2: Software Architecture)
Graphical User Interface (GUI)
The GUI consists of various subsystems; among these are, the Connection subsystem, the Movement and Gripper control subsystems, the Status and Log display subsystems, the Telemetry subsystem, the Settings subsystem, the Scripting subsystem, and the Help subsystem. These will each be described in turn, with an image of how the system might be designed where appropriate.
Connection Subsystem
The connection subsystem consists of a modeless dialog, which is to be displayed whenever there is no connection open between the remote control center and the onboard system, or when the connection icon is clicked. It is to include a field where the IP address of the onboard system can be specified; a button to attempt a connection, and one to disconnect; and a field which will display the current connection status (connected or disconnected). See Figure 3 below.
(Figure 3: Connection Subsystem)
Movement Control Subsystem
The movement control subsystem consists of four buttons representing the four cardinal directions, and another button which will cause the robot to stop all movement. The forward button and backward button will cause the robot to move either forward or backward so long as they are held down. The left button and right button will cause the robot to rotate either clockwise or counterclockwise so long as they are held down. There will also be buttons that allow a 90 degree turn for the robot in both directions. See Figure 4 below.
(Figure 4: Movement Control Subsystem)
Gripper Control Subsystem
The gripper control subsystem should have the ability to choose between ‘auto’ and ‘manual’ control of the gripper (in the sense of the ER1 gripper commands), probably by a dropdown selection list. There should be a button, also, which will toggle the current status of the gripper (open/close). The ability to choose the commands ‘release’ or ‘capture’ will be optional; a minimalist and simple user interface should not be sacrificed for their inclusion. See Figure 5 below.
(Figure 5: Gripper Control Subsystem)
Status Display Subsystem
The status display subsystem should display the main status information of the robot. This is to include the luminosity values of the three IR sensors; the status of the gripper as reported by the gripper status command (‘opening’, ‘open’, &c.); and the percentage of battery power remaining on the onboard system. See Figure 6 below.
(Figure 6: Status Display Subsystem)
Log Display Subsystem
The log display subsystem should display the last several (three or four as space permits) messages sent or received. To display a message, the id should be reported, followed by the message field, followed by the parameters. In order to maintain some uniformity, which would prove useful in quickly ascertaining the displayed information, a fixed order of displaying the parameters should be adopted; note that a map generally has no defined order for returning its key-value pairs, so an implementation should adopt its own order. The order in which the properties are listed in the Communication Protocol is suggested.
(Figure 7: Log Display Subsystem)
Telemetry Subsystem
The telemetry subsystem should include the display of the two cameras and the ability to capture images on a regular interval. Two display areas are necessary, for the Pan-Tilt camera and the Collision camera. There should be an option in each window to automatically refresh the image (which should be done on some set basis, say every 10 seconds). For the Pan-Tilt camera there should be fields to allow the camera to either pan or tilt by some specified amount. Additionally, there should be a button to capture a movie, with radio buttons to select which camera. There will also be See Figure 8 below.
(Figure 8: Telemetry Display Subsystem)
Settings Subsystem
The settings subsystem must allow the default translational and rotational speed to be adjusted; and, it must let the movie capture directory be set, as well as the file path for the message log.
(Figure 9: Settings Subsystem)
Scripting Subsystem
The scripting subsystem is to provide for more advanced control of the robot. The user should be able to create any legal message and send it to the onboard system. The user should be able to create (and save) a sequence of such messages, and execute these in step or in toto. As a message is represented as a C# object and not a string, in lieu of creating a special scripting language, there should be a drop down menu which will let the user chose a base command (“MOVE”, “GRIPPER”, “CAMERA”, “REQUEST TELEMETRY”, “SET”, “GET STATUS”). From here, a text box will accept parameters for commands. Simple error checking of data should occurr; e.g., a user should not be able to enter anything but a number in a field specifying distance.
(Figure 10: Scripting Subsystem)
Help Subsystem
The help subsystem will be accessed from a help icon, and will present an explanation of how to use the system to the user. It should be exhaustive, in that it covers every feature which the user has access to, and usable, in the sense that it is easily searchable, and the user can find what he is looking for with ease. This is optional.
Backend
The Backend is the actual implementation of the functionality suggested by the GUI. Its design will be described, therefore, according to which GUI subsystem it is implementing.
Connection Subsystem
When the attempt connection button is pressed, the system should open a socket connetion on the general and telemetry ports according to the Communication Protocol, with the end IP address as specified by the user. It will do this by instantiating a MessageHandler object, with the appropriate IP address.
Movement Control Subsystem
When the forward button is pressed, the system should generate a move command with distance and unit the default values. The same should be done for the backward button. Similarly, for the left and right buttons, a rotate command should be generated with the appropriate default parameters. (The commands are generated, of course, by calling the Message Generator system.) When the stop button is pressed, a stop command is generated.
Gripper Control Subsystem
When the dropdown list is changed to either “auto” or “manual” the appropriate message is generated. Similarly, when the open/close toggle button is pressed, the appropriate message is generated. The current status label should get its value from the status display subsystem, as described below.
Status Display Subsystem
The status display will need to be updated on a periodic basis. Therefore, there should be some timer so that every 20 seconds the Message Generator subsystem is called, and causes that system to generate the appropriate status messages to the onboard system. There should be some sort of RegisterStatus(StatusInfo) method to update the status display when data is received from the socket connection. A StatusInfo class should be provided for convenience.
Log Display Subsystem
When a message is registered with the Logging subsystem, it should be displayed. The system may separate messages sent from those received, but this is an optional functionality.
Telemetry Subsystem
As described in the status display subsystem, this subsystem will need to wait for the telemetry data to arrive from the onboard system. This should be accomplished with some RegisterTelemetry(CamType,Image) method. When the auto refresh option is set, there should be a timer so that a request telemetry message is generated at the appropriate time; when the data arrives, the display should be updated. When the Pan or Tilt buttons are pressed, the appropriate message should be generated. When the capture movie button is pressed, a timer should be set up to generate the request messages at the appropriate times; the auto refresh timer, if present, is to be stopped during the procurement of the movie frames. These frames are to be saved to disk in the directory specified in the settings subsystem, with names such as “frame01”, “frame02”, &c. Capturing a movie is an optional feature, to be implemented only if the customer demands it.
Settings Subsystem
The appropriate messages should be sent to affect the changed settings. For the directory and path information, the private data members of the Backend will be changed.
Scripting Subsystem
This system is optional. Some work still needs to be done in its design. For instance, currently the method to generate messages creates the message object and then sends it. Lacking a scripting language, and using the procedure described above, it might be a better design to let the generation of messages and the sending of messages to be separated. Otherwise the design would be somewhat sloppy, or at least lack a certain elegance.
Message
Messages are serializable, and generated and sent over an appropriate socket by other classes in the communication subsystem. Please see the Communications Protocol for an in-depth explanation of the Message class.
Message Generator
The Message Generator subsystem is responsible for the actual generation of the message object, as per the Communication Protocol, and the sending of that object over the appropriate socket (via contacting the Message Handler). It must register the message sent with the Messange Handler and Logging subsystems.
The following methods and fields will be required.
Class Name: MessageGenerator. Note the class is immutable.
public MessageGenerator(MessageHandler h) / Constructor; MessageHandler specified, thru whom all send commands are relayed.public void GenMoveMessage(int dist, enum UnitType) / Creates Move message with appropraite parameters and calls Send with it.
public void GenRotateMessage(int deg) / Creates Move message with appropraite parameters and calls Send with it.
public void GenGripperMessage(enum GripperCommandType) / Creates Gripper message with appropraite parameters and calls Send with it.
public void GenCameraMessage(int pan, int tilt) / Creates Camera message with appropraite parameters and calls Send with it.
public void GenTelemetryMessage(enum CameraType) / Creates Request Telemetry message with appropraite parameters and calls Send with it.
public void GenSetMessage(int translational, int rotational) / Creates Set message with appropraite parameters and calls Send with it.
public void GenStatusMessage(enum StatusType) / Creates Status message with appropraite parameters and calls Send with it.
Message Handler
The Message Handler subsystem is responsible for handling the incoming messages from the onboard system and the actual sending of messages to the onboard system. Incoming messages will primarily consist of the “OK” message, and telemetry and status data. In order to handle the former message type, it will be necessary to keep a list of all messages sent and the time they were sent. Periodically the Message Handler will cycle through this list; if the difference between the current time and the time sent is larger than some threshold, then, providing a connection is present, the system will contact the Message Generator and have it resend the message. Note that when an “OK” message is received (or a “STATUS” message), the message with the corresponding id is removed from the list. To handle telemetry and status data, the system will contact the Backend via either setPanTiltTelemetry, setCollTelemetry, or setStatus, as appropriate. Note that the handlers must register each message received with the Logging subsystem.
The following methods and fields will be required.
Class Name: MessageHandler. Note the class is immutable.
public MessageHandler(IPEndPoint ip) / Constructor; the IP address of the onboard system is specified. Creates corresponding MessageGenerator object.public void TelemetryHandler() / Hanldes telemetry data (described above); runs in own thread, listening on the telemetry socket. Registers messages received with Logging subsystem.
public void GeneralHandler() / Handles general data (described above); runs it its own thread, listening on the general socket. Registers messages received with Logging subsystem.
public void CheckConnectivity() / Runs it own thread; continually checks time of message sent verse current time, and resends the message as needed.
public void CloseConnection() / Closes the socket connections.
public void Resend(int id) / Sends the Message whose id field is ‘id’ again. (Used when a sent Message is not acknowledged within in some time interval.)
public void getMessageGenerator() / Returns the MessageGenerator object associated with this handler. (Recall the object is immutable.)
public void Send(Message m) / Public method. This will actually send the method over the appropriate socket, and then register it with the Logging subsystem.
private List<int, DateTime> msgIdTime / List of message id’s sent and the time they were sent.
private Socket generalSocket / General port socket
private Socket telemetrySocket / Telemetry port socket
Log
The Logging subsystem will keep track of all messages sent and received by the system. It will have the ability to write the log to disk, and to share the log with the rest of the system.
The following methods and fields will be required.
Class Name: Log. Note the class is immutable and a singleton.
public Log instanceOf() / Static factory method, to enforce singleton property.public void registerMessage(Message m) / Registers message m with the loging subsystem; i.e., adds it to messageLog.
public List<Message> getLog() / Returns system log. (Does a defensive copy first, of course.)
public void writeLog(File f) / Writes the log to disk, at the file f.
private Log() / Private constructor; needed private to enforce singleton property.
private List<MessagemessageLog / List of messages sent or received by system.
Concurrency Description
There are several threads in the system, and so it is important to keep track of them all. The GUI/Backend will run in a single thread, however the Backend may create threads to do various things on a periodic basis (e.g., generate request telemetry messages every 5 seconds). The Message Handler system will have its generalHandler() and telemetryHandlder() methods each run in separate threads.
UML STATIC CLASS DIAGRAMS