PRESENTED BY TEAM
TRI MAXI ON
JON PRI CE, ERI C ENGER, JASON FARRELL
TOBI AS KNUTSSON, JOHN
AHLSTROM, OSCAR ALMGREN, ROBI N
Computer Science Capstone
The design of the system was initially drafted very early
We wanted to keep things simple but also allow for
complexity where needed
Components should be standalone and require only
knowledge of what they are receiving/sending
Limit redundant code
Division of components
Main Server (Image Processing, Path finding)
The robot should allow for manual control within given values
being sent from the GUI
A live video stream should be displayed in the GUI and be
When the video is clicked the destination should be
determined and the path automatically calculated and followed
avoiding obstacles when necessary
Upon completion the robot should be able to acquire a target
and fire a projectile at the target
Components should be standalone and be able to work alone
Test a completed component with a test application
Perform weekly tests to ensure frozen code works with new
Keep it Simple Stupid
Nothing Unnecessary, add
extra when product is complete
Maintain constant communication and provide continual
Areas of Technical Expertise
Robot being Completely autonomous when finding a path
Light based movement sensor with pin wheel
Projectile launching system
KEEP I T SI MPLE STUPI D
Development of Trimaxion
A wide variety of programming knowledge and experience was
exhibited by the members of our group
The Main Server took longer to complete then usual
Communication with Sweden was at times lost for unknown
Jon will talk more about this later on
Each Component was given its own folder under ‘trunk’
this was not the best idea as certain projects needed to
be able to reference certain classes in other project
Example: Command.java is used in both GUI and Main Server
Managed Milestones and Global ToDo list
Eclipse w/ SubEclipse
Java Media Framework
Java Advanced Imaging
PRESENTED BY JASON FARRELL
Real Time Transfer Protocol
UDP based to allow efficient data transfer with permissable
Stream a media location that can be read by a client via the
RTP protocol implementation in JMF
Java Media Framework (JMF)
Allow access to media capture device (microphone, webcam)
Use data source to display video or produce audio
Use RTP Session Manager to broadcast data to client
Use of Player and Processor objects to manage and display
First goal was to be able to display the output of the
data source in a GUI
Accomplished using the Data Source class in conjunction with
a player object designed to interpret that data source
Next be able to transfer the data source over the
To test this we used JMStudio which came with the framework
and was developed by Sun Microsystems.
To assist with the development of the transmitter we used the
VideoTransmit class from the Sun Developer network.
We specified the destination via RTP by specifying an RTP
address of the format: rpt://ip.address:port/track
The primary means of testing was the use of
JMStudio, which we knew to be a working program,
thus to make it easier to determine which component
First segment, testing the transmission by opening
an RTP Session from JMStudio
Second Segment, testing the reception by
transmitting from JMStudio
Final Segment, testing using both the GUI and
VideoServer for Reception and Transmission
PRESENTED BY ERI C ENGER AND JASON
Graphical Front End
What would the GUI look like?
Manual movement commands for rotation and straight line
Streaming web cam image, clickable to allow point selection
Communications protocol with Main Server
TCP with Java Sockets
What to send between?
Image, Point, Command
Object I/O Streams
Needed to support JButton and JTextField for manual robot
control parameter entry
Communicate with Main Server using Object I/O Streams
Leverage Java for all components
Limit number of mouse clicks to send info to server
Command class houses instances of ImageIcon, Point, and
Command is a char field that dictates what type of command is
Use of JMF to read the RTP Data Stream coming from Video
JMF also used to “capture” the current image in data stream
Supports a char field that is accessed by Main Server to
determine command type
Image is the captured image from the web cam stream. Stored
as an ImageIcon but accessed as an Image using encapsulation
ImageIcon is inherently serializable
Instance of point generated by mouseClick event
associated with VisualComponent of JMF Player
We used the finished GUI with a test server involving
stub code from Main Server.
Goal: send the image and point across the Grand Valley
Results: Transmitting Computer must be plugged into the wall
Have finished GUI attempt to connect and send
image to Test Server located in Sweden
Goal: Display the image from the webcam in Sweden
Result: All computers involved must be connected via a wall
connection with no firewall
PRESENTED BY TOBI AS KNUTSSON AND
Java Advanced Imaging (JAI)
Platform independent (Java Interface)
Fast (C Backbone)
Locate robot position and relative angle
Remove robot from the obstacle map
Determine map scale (using the robot as a reference)
Development approach: Find solutions that work in different
environments (lighting conditions, surfaces etc.)
The web is an invaluable resource for examples. We
do not want to reinvent the wheel
Unprocessed Image in the Visor
Processed Image from Visor
Challenge: Designing the algorithm using static
images and keeping it flexible
Solution: Try to create realistic scenario
change lighting, obstacles surfaces
Scaling images gives better performace, but also
gives you alot more factors to keep track of
PRESENTED BY ROBI N MALMROS, OSCAR
Discussion led to Guiding Star (A*)
What is Guiding Star?
Google revealed excellent sources
Coding in Java using Eclipse
Optimized the path with the removal of intermediary
Integrated the path finding into Astrolabe
Testing of arbitrary boolean map
Testing of map received from Command
Testing with full system integration
PRESENTED BY JON PRI CE
ASSI STED BY ERI C
Deciding on the Build
Robot must be able to turn without deviating from its
Decided to use a tank design.
Initial navigation would use the TiminingNavigator
class developed in Lejos.
Communication would be achieved using the
RCXPort provided by Lejos.
Robot Design Phase
Our initial robot design was a very
basic tank design that was found
using Google. The design was
modified slightly to place the IR
sensor in the back of the robot.
The final design was a modification
made by the team in Sweden. This
design placed the IR sensor towards
the ceiling and adding a well designed
bumper sensor to the front.
The TimingNavigator Class
The TimingNavigtor class was written by the
developers of Lejos.
It provides (somewhat) accurate movement based on
how long it takes for two functions to be completed
How long does it take to travel 1 meter.
How long does it take to rotate 360 degrees.
The measurements obtained depend on the surface
used and the voltage of the batteries. So, the
measurements would actually change over time.
It was determined a better solution was needed.
Tobias saves the day when he discovers the “poor
mans” rotation sensor.
The encoder wheel is
attached to a large
The light sensor is
used to read white and
black values on the
A count is kept during
Rotation Sensor, cont.
Provides accurate movement regardless of battery
voltage or motor speed.
Still requires measurements to be taken, but they
should hold true for that situation.
Count to travel 1 centimeter
Count to rotate 1 degree
Rotation Sensor, cont.
The rotation sensor did introduce some new
Find the largest number of sector’s on the wheel
and still be accurate.
Find the average value the light sensor “sees” for
black and white areas.
Use trial and error to calculate 1 centimeter and 1
What is the accuracy obtained
Smallest movement allowed
Smallest turn allowed
The LightNavigator class
Class developed to accurately move using the new
Once the class is instantiated, all you need to do is
tell it to travel ‘x’ centimeters or rotate ‘x’ degrees.
Drawback: Does not maintain current x and y
position of the robot.
Communication with RCXPort
Decided to use the RCXPort already developed for
Slow speeds, but provides reliable connection and
ensures all data is transferred.
Easy to work with because it uses Java’s Data IO
Develop RCXProtocol class to bridge the server <
> RCX communication.
Simple class that creates the RCXPort and retrieves
the input and output streams.
Provides methods for communicating with the robot:
Travel ‘x’ centimeters
Rotate ‘x’ degrees
Sends the commands and blocks until a response
from the RCX is received.
During the design phase there was continuous
testing of the robot’s “brain”.
Movement always seemed to be hit or miss when it
came to accuracy.
What was the cause of the inconsistency?
X and Y coordinates, along with robot’s rotation were
Once removed/not used we were able to provide more accurate
Inconsistent Communication with RCX
There are still inconsistencies with the way the RCX
communicates with the server.
Commands received, executed, no acknowledgement
Commands never received.
One solution was to add some minor delays after
commands are sent and executed.
Stops all movement and plays a series of tones.
No recovery at this point
Java IO Blocks, so it was hard to “timeout” the IO
streams on the RCX.
RCXPort provides reliable data transfer, so no packets
will be lost.
“Poor Mans” Rotation Sensor:
Lejos Download and API:
Initial Tankbot Design:
PRESENTED BY TEAM TRI MAXI ON
CAUSE YOU DON’ T WANT END UP LI VI NG I N
A VAN DOWN BY THE RI VER
Testing & Integration
Testing of VideoServer and GUI across the Atlantic
to determine connectivity requirements
Localized testing to determine components
Full testing involving connections between America
VideoServer to GUI Testing
After completion of localized testing we set out to
“meet the Swedes” and get them on cam
We acquired a firewall free connection from Carl
Strebal and proceeded to assist the Swedes with
getting the code working on their end
We discovered that for optimum results both sides
needed to be connected to the wall
Also during this testing process we decided on a
consistent port access protocol
Any connection from America to Sweden uses port 22224
Any connection from Sweden to America uses port 22222
Problems: Finding a computer was the hardest
We tried a number of machines before settling on Eric’s
machine to host Astrolabe (Main Server)
Over calculation of scaled values
robot moving too far
Required network testing to ensure proper communication.
Jason: Video Server /GUI
Eric: GUI / Main Server (Astrolabe)
Integration: Fusing atypical code
Environmental variable problem
.dll files and pathing
What we would do over?
Multicast Video Server
Redesign of movement calculation for robot
Projectile launching device
learned about communication and managing a
distributed application project
Gain new insight into other areas where Java can be used for
JMF for accessing web cams and audio devices
JAI for advanced Image processing
Learned to work with members of another culture and made new
The problem seemed easy at first but ended up being very challenging
The main problem came from the lack of time to properly design the
Also difficulty in communicating at times led to delays that forced us to
push back various milestones
CLOSE BUT MORE TI ME WOULD BE NI CE
The Current State of Trimaxion
ARE YOU THI NKI NG WHAT I ’ M THI NKI NG
I THI NK SO BRAI N, BUT BURLAP CHAFES ME
AND NOW…. A DEMONSTRATI ON
And to close