May 24, 2005
Class Diagram
I made a rudimentary class diagram. I checked in with a coworker and he said that my design makes sense. I'm not exactly sure how to get the correct format in ArgoUML.
Basically, actuators make up components like arms and legs.
Arms and legs make up humanoid robots.
Other set pieces will get an appropriate class later.
Each humanoid robot contains the methods necessary to perform the choreography.
There will be a choregraphy interface with subclasses that implement it. Each robot will register with the choreographer. Associated music will also check in (meaning we need the appropriate music classes). The choreographer will keep the movements in synch with the music.
My coworker also made the point that since the robots are performers, I can think of the class design as a theater. If I am missing a class, think of who would do that in the theater and add that class.
see class diagram
Posted by michelle at 09:14 PM
| Comments (0)
May 21, 2005
UML Software and Software Design
I am trying to design the robot control software. I have never designed anything this complex before so I am starting simple. I wrote some basic code in Eclipse and then imported it into Argo UML to see the class design better. Obviously, I still have a long way to go:
Posted by michelle at 03:41 PM
| Comments (0)
May 11, 2005
The Observer Pattern
Today's chapter in the Design Patterns book is about the observer pattern.
The Observer Pattern defines a one-to-many dependency between object so that when one object changes state, all of its dependents are notified and updated automatically.
This pattern seems a lot more straightforward than the strategy pattern. I think we are likely to use this pattern when we need to report back on the state of an actuator. It will only be helpful if it is a one-to-many relationship otherwise just simple callback functions will suffice. There may be other design patterns that make more sense here.
Posted by michelle at 09:26 PM
| Comments (0)
May 09, 2005
Design Patterns
I just read the first chapter of Head First Design Patterns. Since we are writing the program in Java, I might as well learn some Design Patterns to help development. Design Patterns are a set of solutions to problems that developers commonly encounter. They also provide a vocabulary for describing these solutions. The fist chapter explains the strategy pattern.
The Strategy Pattern defines a family of algorithms, encapsulates each one, and makes them interchangeable. Strategy lets the algorithm vary independently from clients that use it.
For the purpose of our software, I'm not sure if we can use this pattern. A contender for this pattern is motors. Let's suppose that motors have enough in common that they warrant having one motors superclass. We can extend the motor superclass with a servo class and a stepper class. Now if everything about these motors is basically the same except for how they return their position, we could make a Position interface. Then we could make two classes that implement Position with the appropriate behaviors.
I'll have to learn more about the components in the project to make these kinds of decision, but hopefully by describing it here I am absorbing the concept a little bit better.
Posted by michelle at 01:42 PM
| Comments (0)
April 25, 2005
Setting up a Java Environment (Lablog4-25-05 #2)
I am designing the software for InsideOut in Java. James usually uses C code with some C++ libraries for this kind of project. I feel more comfortable working in Java and I think the robots are suited to object-oriented design.
First I set up a Java environment on my computer. I installed the Java 1.4 SDK and the Eclipse SDK. I had not used Eclipse before, but it makes tasks like creating getters and setters and compiling easier. Eventually, I think I will need to install Apache and Tomcat to run the code on my machine.
I found some robot code on a CMU web site. It includes an example of implementing a serial port interface in Java via a C dll. This might make sense because we already have serial code in C. Here’s part of the Java code:
public synchronized class serialPort
extends java.lang.Object
{
// open serial port at specified baud with other
// appropriate parameters. returns:
// 0 on success
// -1 on failure to open serial port
// -2 on failure to read port state
// -3 on failure to set port state
// coms are: 1 = "COM1"; 2 = "COM2" et cetera
// baud rates are: 1 = 9600; 2=19200; 3=38400;
// 4=57600; 5=115200; 6=230400
public native int openSerial(int comNum, int baudSpec);
public native int closeSerial();
// returns 0 on success or -1 on failure to send byte
public native int sendByte(int theByte);
// initialTimeout is measured in milliseconds //
// returns -6 on failure to set timeout, 0 on success
public native int setReadTimeout(int initialTimeout);
// returns -1 in error or timeout, else returns int
// between 0 and 255
public native int readByte();
static {
System.loadLibrary("sserial");
}
}
sserial is the name of the dll.
Apparently, Java has come out with a javax.comm package for serial communication. That might be a little more efficient than loading a C dll.
Posted by michelle at 08:47 PM
| Comments (2)
|
