Download G.U.N.D.A.M.

G.U.N.D.A.M.
II. DESIGN
A. Motor Microcontroller
Didier Lessage, Gabriel Rodriguez, Blake
Simonini
School of Electrical Engineering and Computer
Science, University of Central Florida, Orlando,
Florida 32816-2450
Abstract — The GUNDAM is a maze solving robot using
primarily the wall following method of maze solving to find the
exit of a wooden maze. The robot uses a combination of IR and
ultrasonic sensors to detect walls and turns. The robot will also
transmit this information to a laptop to draw out the layout of
the maze and give a visual representation of the area for the
user.
I. INTRODUCTION
The GUNDAM’s main mode of transportation will be
two motors controlling the left and right side wheels of the
chassis. A voltage regulator will be built to control the
flow of power to the different physical components of the
robot. One ultrasonic sensor will be used to detect any
obstacles in of the robot. Two IR sensors will be used to
detect distance between the sides of the robot and the
walls to its left and right.
The motivation for this project was to provide a
method of exploration of areas unable to be safely
entered by humans safely such as caves and areas with
small paths and openings. The robot’s ability to detect
walls will have the dual purpose of object avoidance
and a basic understanding of the layout of the area. For
the purpose of this project, the goals have been scaled
down to simply be the successful navigation of a maze
and transmitting enough information for software to
translate it into a 2D layout for the user. The software
will also give the user the ability to give the robot parts
of a solved maze to travel to.
This project was also chosen to feed into the strengths
of each of the group members. With two electrical
engineers, a heavy focus on the actual hardware was
chosen to play to their strengths. A final computer
engineer led to the decision of a software side to the
design, the maze drawing and pathfinding portion of the
GUNDAM. This allowed for each member to give a
significant contribution to the project.
In order to control the 6VDC motors that we have on
our chassis, an H-bridge is needed. Instead of making an
H-bridge with individual parts, we decided to buy one that
was already made and well documented – the L298N. We
also opted to get a diode bridge to protect the H-bridge
from counter-EMF produced by the high inductance of the
motors. Then in order to control our H-bridge, we
conjoined that with the MSP430 (g2231) MCU. And since
the L298N uses transistors for switching and the motors
were designed to consume somewhere around 2 Amps
when running continuously, we needed to make sure that
our motor voltage and amperage was high enough to
account for the voltage drops (and energy waste) across
the transistors (VSS needed to be about 10.6 volts).
We also needed to supply voltage for the TTL logic that
controls the transistors (5 volts), as well as supply a high
enough voltage for the MSP430 in order to get the
maximum clock speed out of it (3.5 volts), while
remembering to put in decoupling capacitors for all of our
voltage supply inputs. The following represents the design
for
one
motor
on
the
H-bridge.
Fig 1. Half H-Bridge for one motor
Input 1
0v
5v
Input 2
5v
0v
Motor1Output1
5v
GND
Motor1Output2
GND
5v
Results
Clockwise Counterclockwise
Fig 2. Gate Input Table for Each Motor
5v
5v
0v
0v
Off
EnableA and EnableB need to be high to enable each
half H-bridge to make the full H-bridge that controls both
motors. And for protecting the motors from back-EMF,
the L6210 Schottky Diode bridge is used. It can handle up
to 4 amps across a diode and has a low turn on voltage.
The following is the design for connecting it to the H-
It’s also worth noting that the motor microcontroller will
handle positioning itself in the direction of new corridors
once it is commanded to go down a particular corridor.
This is done by placing the sensors towards the back of the
chassis, so that as soon as a new corridor is detected by
those sensors, the robot will already be accurately centered
in that corridor and will only have to rotate a certain angle
in order to position itself for navigating down that
corridor.
bridge.
Fig 3. Diode Bridge for both motors
The MSP430 MCU that we used runs at a clock speed
of 1Mhz; its function is to balance the motors, use routines
to turn the motors so that the robot moves forward,
backward, clockwise, and counterclockwise using Pulse
Width Modulation for the distance it is commanded, keep
the robot centered in a path as it moves down a corridor,
and know what possible decisions it can make based on
what data the sensors are giving to it. The actual decision
handling though will be partly done by an outside
controller and the MSP430 will mostly accept commands
in this regard. The decisions that will be implemented into
this controller are explained in the following.
Decision
Explanation
Decision 1
Corridor ends
with no openings
Corridor ends
with one opening
Decision 2
Decision 3
Decision 4
Corridor ends
with two openings
Corridor ends
with three
openings
Fig 4. Robot Decision Making
What Can Be
Done
Turn Around
Wait for
command:
Might be in a
loop
Wait for
Command:
Might be in a
loop and
doesn’t know
which path
should be
taken
Wait for
Command:
Might be in a
loop and
doesn’t know
which path
should be
taken
B. Chassis Layout
The chassis we used has the ability to mount PCBs on it
with the capability to stack them on top of each other. The
motors came fitted to the chassis, while the battery holder
for the three AA batteries does not supply enough voltage
and current to be of any use. We also needed a way to
mount the sensors, motor microcontroller, PSU, and RF
controller so that everything could hook up to each other
and there would be no interfering of parts.
C. Power Supply and Battery
The power supply consists of four different voltage
regulators for delivering our power needs.
Regulator
Switching – 10.6 volts – 5
amps
Linear – 5 volts – 1.5
amps
Linear – 3.5 volts – 1.5
amps
Linear – 2.5 volts – 1.5
amps
Function
Power to the motors
Power to the TTL logic of
the H-bridge, as well as
the IR and Ultrasonic
Sensors
Powers the MSP430 in a
high power mode
Powers the MSP430 in a
low power mode
Fig 5. Voltage Regulators
There are also lots of pins attached to each voltage
source for modularity. This allows us to add components
later as we need them and gives us a greater ability for
laying out our parts on the chassis as we require it.
For a battery we have two lithium ion batteries at 7 volts
that we have in series. This will give use 14 volts, which is
sufficient to account for the dropout voltage across the
10.6 volt switching regulator. Also, the switching
regulator is technically adjusted from 5 volts to 10.6 volts
and each voltage input in our circuits have decoupling
capacitors to keep any circuits from dropping out as the
power demands on the regulators drop and rise too
quickly.
For testing purposes, we didn’t use a battery, but used
a laptop power supply rated at 19 volts and 4 amps,
which has a built-in transformer and plugs easily into
the power connector on the Power Supply on our board.
For the battery we had to connect a power connector so
that we could plug it into the Power Supply on our
board.
III. COMMUNICATION SYSTEM
A. Communication Subsystem
The design of the G.U.N.D.A.M.’s communication
subsystem will be centered on a microcontroller that can
process the signals transmitted from the computer,
which requires demodulation and decryption.
In
addition, to transmit to the computer the microcontroller
will be required to encrypt the data, which will be the
path taken or other information about the maze, from
the main microcontroller and modulate for transmission.
The microcontroller in charge of taking the bits received
from the transceiver will be an MSP430G2xx. Since
the MSP430G2xx has the ability to convert analog-todigital signals a simple AM or FM transceiver can be
used for transmissions, but the microcontroller can also
accept digital input so using a digital RF transceiver via
an SPI interface, which will carry an advantage in
reducing the amount of processing the MSP430 has to
do.
The microcontroller will also be in charge of
implementing a simple wireless protocol including
AES-128 encryption to communicate with the computer
and visa versa. To accomplish this, the code written on
the microcontroller will be split into two main parts.
One for the purpose of taking data from the main
microcontroller in charge of controlling the robot itself
and transmitting that data to the computer. In the
process of transmitting that data the microcontroller will
encrypt it using AES-128 encryption algorithm. The
second for the purpose of establishing an initial
connection and manage this connection with the device
on the computer.
The MSP430G2553 microcontroller has the
capability of communicating with several devices
simultaneously through the use of two-channel serial
communication interface, namely USCI_A and USCI_B
blocks.
The MCU on the computer dongle has to be able to
communicate with the RF transceiver through an SPI
interface and simultaneously send that data to the
computer through an UART interface. Luckily, the
MSP430 MCU has the capability to meet both of these
application needs.
The device that will be on the computer has the same
functions as the one on the G.U.N.D.A.M., however; the
demodulated and decrypted data will be sent to the
computer through a USB interface. The MSP430 has a
serial interface to communicate with a computer but this
would not work with all computers since many don't
have serial ports and it would be ideal to be able to
communicate with any computer that has a USB port
and can run the software. To combat this problem a
CP2102 chip will be used to convert UART to USB,
which will allow the MSP430 to send and receive data
from the computer. The CP2102, manufactured by
Silicon Labs, is a single chip USB to UART Bridge.
The computer will recognize this device as a virtual
COM port, which in turn can be used by the GUI
running on the computer to draw out the map of the
maze. The bridge in turn will be connected through
TXD and RXD pins, to an MSP430’s UART interface,
which is the USCI_A channel.
The CP2102 has baud rates up to 921.6kbps so it can
handle the transmission speed on the RF transceiver and
MCU. It also has a 512 byte transmit and receive
buffer, which is over the 64-byte TX and RX FIFO of
the RF transceiver, although the MCU will be the
middleman between the RF transceiver and the CP2101.
B. Interfacing RF Transceivers with MCU
All the modulation and demodulation schemes
explored are able to accomplish the task of sending and
receiving data between the G.U.N.D.A.M. and a
computer, however; some schemes provide better
features for our application. Frequency and phase
modulation provide the ability to transmit a signal with
minimal noise and inference, which is ideal in our
environment.
Phase modulation, in contrast with
frequency modulation, in particular provides a way to
more easily detect if the signal is lost and give the
ability to retransmit any data that is lost. Phase shift
keying is a digital modulation scheme that is ideal for
the G.U.N.D.A.M.’s communication subsystem not only
for the reasons previously discussed, but because the
data transmitted will be binary data. However, even
with the increase spectral efficiency and data rate the
frequency modulation techniques over amplitude
modulation techniques have higher power consumption.
To implement this design an RF transceiver of low-cost
and low-power consumption will be used on the
G.U.N.D.A.M. and the computer communication
device. This transceiver will be the low power IC chip
from Hope Microelectronics, RFM12B that has the
ability to modulate and demodulate a binary signal
using multi-channel FSK. This RF transceiver is very
versatile and has many programmable features, such as
frequency, power output, channel filter bandwidth, and
Carrier Sense indictor among many others.
The
RFM12B RF transceiver module has very low power
consumption at 14mA in TX mode operating at
433MHz.
The RF transceiver module will transmit and receive
at different frequencies to increase efficiency and
decrease interference during communication between
the G.UN.D.A.M.’s module and the computer’s. In the
MCU will be connected to the RF transceiver through
the pins on Digital Interface.
The RFM12B is
configured with this SPI interface, which is also used to
transmit and receive data. Meaning the MCU will be in
charge of programming the different modes available on
the RFM12B and transmitting and receiving data
through the same interface. The RF module has two 8bit TX data registers and one 16-bit RX data FIFO.
Depending on how the R/W bit is set when interfacing
through the SPI, the FIFO can be accessed through a
single address. As stated before the MCU will use four
I/O pins for the SPI configuration interface, namely
SDI, SCK, nSEL, SDO, nIRQ. The MCU can be
programmed to generate interrupts based on the status
pins’ output. One of the most useful programmable
features on the RFM12B is the data rate, which can be
configured through the configuration registers
mentioned above.
Yet another important programmable feature is the
output power of the RF transceiver. The output power
chosen will determine the typical current consumption,
which will affect the range. During the testing phase an
output power can be chosen based on a reliable effective
range determined to be sufficient.
There is a possibility of a problem arising with using
a frequency range of 433MHz for transmitting and
receiving data, that is there can be other communication
systems operating at these frequencies in our testing
environment. Thus to reduce interference a lower
frequency band which is not as commonly used by most
modern wireless systems in our likely testing
environment was chosen. The length of the antenna
depends on the frequency the RF transceiver will
operate at. The frequency band chosen for the RF
transceiver is 433MHz, meaning that this RF transceiver
will require an antenna that is a quarter of the smallest
wavelength utilized to keep a reasonable size and
performance, which turns out to be approximately
23.8cm.
C. Wireless Protocol
The main features required from the protocol is the
ability to sense the presence of another transmitting
device and send acknowledgements so the device goes
into listening mode. A secondary but important feature
to the protocol will be an implementation of the AES128 encryption algorithm. This encryption algorithm
has gained popularity due to its susceptibility to bruteforce and other attacks. The implementation of AES128 encryption algorithm will require the sender to
encrypt the data using a public key and the receiver to
decrypt the data using a private key. Both the
G.U.N.D.A.M. and the computer device will share a
public key to send data to each other but each will have
their own private key to decrypt the data they receive.
The first requirement of the wireless protocol, which
will be implemented by the MCU, will be to handle
transmission between two nodes in a manner that they
don't talk over each other, in other words, neither of the
two nodes must transmit or receive data at the same
time. To accomplish this there will be a routine in the
MCU that will periodically check whether the device is
transmitting or receiving data. This will be important in
determining the next step because initially both the
G.U.N.D.A.M. and the computer module will be in
listening/receive mode that will wait for new
transmission. Data transmission will begin when the
G.U.N.D.A.M. has information it needs to transmit to
the computer. In this case, the G.U.N.D.A.M.’s MCU
will encode the data in AES-128 and pass it to the RF
transceiver to be sent to the computer.
The computer will initially be in listening mode to be
able to receive the encoded information, which it will
then decode and pass it on to the computer. In this
application, the G.U.N.D.A.M. will be the only device
sending data and the computer will only be receiving
data.
However, the design allows for two-way
communication between the G.U.N.D.A.M. and the
computer for scalability purposes.
Although the
G.U.N.D.A.M. and the computer dongle will only
implement one-way transmission they will each use
acknowledgements to ensure that data was received
without errors and no retransmission is needed. To
accomplish
this
error-checking
test,
the
G.U.N.D.A.M.’s RF transceiver will need to switch to
listening mode to receive a packet of acknowledgement
from the computer dongle. Similarly, the computer
dongle will switch to transmitting mode for a short
period of time to send the packet acknowledgement.
This coordination will be accomplished by routines in
the MCU and a timer to ensure that there is no collision
or loss of data.
The second requirement of the wireless protocol will
involve the MCU having the capability to also handle
the encryption of data before it is transmitted over-theair to either the G.U.N.D.A.M. or the computer. To
reduce latency and errors, the acknowledgement packets
will not be encrypted since they don’t contain any
relevant data to what the G.U.N.D.A.M. is
communicating to the computer. A separate routine on
the G.U.N.D.A.M. and computer’s MCU will handle
which packets will be encrypted and which won’t. For
the packets that are encrypted the MCUs will have an
encryption and decryption routine. The function will
take plain text data from the main microcontroller on
the G.U.N.D.A.M. or the computer on the receiving
dongle and encrypt it using the AES-128 encryption
technique. To encrypt the plain text the MCU on the
G.U.N.D.A.M. will use a pre-programmed key to
encrypt the data and the MCU on the computer dongle
will use the same pre-programmed key to decrypt the
data and send it to the computer so the GUI interface on
the computer can use the data to draw out the maze.
Although not needed, the G.U.N.D.A.M. and the
computer dongle will both have the capability of
encrypting and decrypting plaintext for scalability
reasons.
Fig 6. Function of Sharp GP2D120 infrared range finder.
This particular IR range finder has a minimum and
maximum detection range from 4cm to 30cm. It has an
operating voltage and current of 4.5V to 5.5V, 33 to
50mA. The response time is 30ms with an analog output.
The voltages can simply be converted to a useful distance
for the microcontroller using the chart below.
IV. Range Finder System
The G.U.N.D.A.M. will have two ultrasonic sensors
on the front and back of the robot to detect longer
distances in the narrow paths of the maze. It will also
have two infrared sensors on the sides to detect smaller
distances. Most ultrasonic sensors have a minimum
distance of 2cm and infrared sensors have a minimum
distance of 4cm. To combat inaccuracies in distance
measurements the robot’s main microcontroller will be
required to keep the robot centered within the minimum
distances that the sensors can measure. Infrared sensors
have simple circuits but accurate infrared sensors are
difficult to manufacture without the proper tools.
Below is a figure of the Sharp GP2D120 infrared range
finder functioning on a flat surface obstacle.
Fig 7. Voltage output vs. Distance of GP2D120 IR range finder.
Ultrasonic sensors on the other hand are less susceptible
to inaccurate measurements due to the wider emitting
beam. Building an ultrasonic sensor with individual parts
and a circuit schematic can prove to be more cost efficient
than purchasing a pre-built sensor. Since ultrasonic sensor
output will be an analog signal there will have to be
calculations done to determine the distance measurements
based on the frequency of the transmitted beam and the
time the beam takes to reflect back and be detected.
Below is circuit schematic of an ultrasonic distance
measurement circuit, however; the PIC12C508 will be
replaced with the main microcontroller.
The range finder sensors will be mounted on the robot
chassis itself and will interface with the main
microcontroller, which will take its values and store them
to calculate the distances and path traversed through the
maze. The two infrared sensors mounted on the sides of
the robot will be as close to the ground as possible and
they will be housed in a shield to prevent interference
from the indoor lighting at the receiving end of the sensor.
The ultrasonic sensors on the front and back of the
G.U.N.D.A.M. will be mounted further from the ground to
reduce the possibility of the sound absorption from the
carpet floor that could possibly be a part of the
G.U.N.D.A.M.’s testing environment. Both the ultrasonic
and infrared sensor will be at the midsection of the
horizontal axis in the robots dimensions to increase the
accuracy when calculating the position and location in the
maze.
V. LAPTOP SOFTWARE
A. Maze Solving Algorithm
The primary method of maze solving for our software
will be the classic solution of wall following. Wall
following works by choosing a side relative to the robot
(left or right), and choosing to stick with that direction
when coming to an intersection or turn. The robot will
choose to follow the left side at all times to find the exit
to the maze being built. For our particular project, the
robot will choose to follow the left side of the wall in
order to reach the exit.
Wall follower will fail in two cases. If the entrance to
the maze does not lie on the outer wall of the maze, then
wall follower is not guaranteed to find an exit. The
mazes constructed for our project will, fortunately, not
have interior entrances.
A second fail state is if a wall is not connected to the
outer wall in one straight line. If this case occurs, the
robot will turn in circles indefinitely. Our project will
also not feature mazes of this type to avoid these two
fail states for wall follower. While wall follower may
seem unintelligent when given an aerial view of the
maze, this method of maze solving always results in a
found exit. Also, because our mazes will be built to a 6’
x 6’ dimension, the amount of time to solve such a maze
will not be an issue.
B. Maze Drawing
The maze drawing software will be written using Java
in the Eclipse IDE. Several classes are necessary to
accomplish this including classes to store the location of
all the walls, a class to store the state and direction of
the robot, and a class to store the location of nodes.
Nodes will be placed at every intersection and turn of
our maze. These nodes will contain their location on the
maze, whether or not their four compass directions are
an opening or a wall, and any neighboring nodes that
may have been discovered by the robot. The existence
of nodes is important for the utilization of the
pathfinding algorithm, A*. The paths will be
represented by a known connection of two neighboring
nodes. If a node has a known opening but no discovered
node in that direction, then the direction will be labeled
automatically with a value of -1. The neighbors will be
stored as an integer that represents the array location of
the neighbor within an array created in a NodeManager
class. This class’ main task is to keep a reference to
every node within the map to allow for easy lookups
when finding a path within the maze as well as
whenever the maze needs to be redrawn.
Walls will be stored within a list similar to the nodes.
Each wall will contain the two corners that make up the
ends of the walls. Wall thickness will not be taken into
consideration for this particular project. A WallManager
class is also utilized to store an array keeping
information on every wall within our maze. This is to
allow for the redrawing of our maze without losing any
information once our canvas has been cleared.
The robot class will contain information on the
compass direction it is facing (north, south, east, west)
and its current location. This information will be used to
determine what direction any openings it finds are as
well as help in translating what exactly a left turn means
in relation to its direction. This also helps us determine
where exactly a new node should be placed within our
maze.
The maze itself will be drawn on a canvas with
simple lines to represent each of the walls and circles to
represent the nodes at each intersection. Our maze has a
uniform length of one foot for each section of wall. This
was done to help the maze drawing algorithm. Before
moving forward, the software will receive data on the
distance the GUNDAM measures between the wall
straight ahead and its current location. The software will
receive another distance value upon reaching a node.
There is the possibility that the sensor will return a
value that is not equal to foot sections. This is to be
expected. To account for this, some assumptions will be
made. For instance, if the sensors first send a distance of
50 inches and upon reaching a node they send a distance
of 28 inches, this results in a distance of 22 inches.
Because of our one foot sections, we know that this
cannot be the case for our maze drawing algorithm. To
correct this, the software will assume a distance of 24
inches, or 2 feet.
With all of this information, the software simply
feeds in the information on how far the GUNDAM has
traveled before reaching the next intersection or dead
end and draws out two lines one foot apart from each
other. This represents the path just traveled by our
robot.
The next block of information grabbed from the robot
will be the values of the three sensors. If the value is
below a foot, we can assume that a wall most likely lies
in that direction. If the value is greater than a foot, we
know that a path lies in that direction. With this
information, the software decides whether to draw a
wall or leave the space open with a one foot entry to
represent the path available to the GUNDAM.
Once the maze has been solved, the user will be
presented with a 2D representation of our maze along
with circles representing the nodes placed at each
intersection.
cursor and every node present in our maze allows us to
decide which node the user most likely wished to select.
With these classes, the pathfinding algorithm then
needs to be chosen. For this project, A* pathfinding
(pronounced A Star) will be used in order to find the
shortest path within the maze in the shortest amount of
time. A* pathfinding works by first grabbing the
location of the GUNDAM and determining the closest
neighboring node to its location. These neighbors were
determined during the maze drawing portion of our
software.
Whenever a node is reached by our GUNDAM, the
software does a search for the node that matches the
location of our previous node. The neighbors are then
applied accordingly. For instance, if we are traveling
west and come upon a node, then the node that was left
previously serves as the current node’s eastern
neighbor. The current node will also serve as the
previous node’s western neighbor. The distance from
the neighbor to the destination is then taken. This is
simply a rough calculation and does not take into
account walls and other potential obstacles. Because of
this, a neighboring node is never counted out of the
possibilities for a path.
Fig. 8. 2D Maze Example
C. Path Finding Algorithm
The robot’s secondary feature is the ability to select a
location for the robot to travel to once the maze has
been solved. In order to accomplish this, we must utilize
the nodes class as well as the robot class. The robot
class will provide information on the GUNDAM’s
current location within the maze. The Node class and as
the NodeManager class are necessary to determine
which nodes can be used for the path to the destination
chosen by the user.
The user must select a node to serve as the destination
of our GUNDAM. This node will change in color to
give the user some feedback on which node they have
selected. A simple distance formula applied to the
Fig 9. Completed A* Path
Once the source is reached, we are usually guaranteed
to have found the shortest and quickest way to the
destination. Unfortunately, this does not guarantee the
most natural looking path to a destination in most cases,
but because our environment is a maze, this is not an
issue for our design.
Once the path has been created, the software on the
laptop side will create a list of instructions that will
result in the GUNDAM finishing at the destination
chosen by the user. These instructions simply consist of
directions to take once the GUNDAM has reached each
node along the path. These directions will be kept in an
array to make for a natural transition between each
instruction and to properly keep them in order.
The user will be presented with a drawn out line
connecting each node within the A* path. This will
correlate to the path the GUNDAM takes within the
physical maze.
VI. PHYSICAL MAZE
The maze itself will simply be built from wooden 2 x
6 boards cut into one foot sections for the interior walls
and 6 foot sections for the exterior. Two of the 6 foot
sections contain a 1 foot entrance cut in the center of the
board. The 1 foot sections allow for a customizable
maze for our robot to traverse. This serves to benefit the
presentation by allowing for much more example cases.
The uniform 1 foot sections also helps to account for
any error within the sensors when measuring the length
of a path.
VII. CONCLUSION
This project helped each group member gain
experience within their respective fields of Electrical
and Computer Engineering. It also gave insight on the
inner workings of a project environment that will no
doubt translate well into the real work force.
The project itself provided hands-on experience with
circuitry, hardware, and communication between
subsystems that will no doubt apply to the real world in
both our careers and in any research we may delve into
in the future.
Our project as a whole has gone through many
changes throughout the semesters. Some accounted for
and others happened upon during the development
process. In the end, a robot with a basic maze solving
ability and wireless communication was successfully
completed meeting the goal of our initial proposal two
semesters ago.
ACKNOWLEDGEMENT
We would like to acknowledge and thank our review
committee for taking the time to judge and observe our
senior design project. We would also like to thank Dr.
Samuel Richie for his assistance throughout the two
semesters. We would like to thank the machine shop
staff for allowing us the use of their equipment when
creating our physical maze for both our presentation and
testing. We would like to thank our families for
providing morale support throughout these two
semesters. Finally, we would like to thank each other
for assistance on our parts and the work put into our
projects.
PROJECT ENGINEERS
Didier Lessage is a senior at
the University of Central
Florida. He is graduating with a
degree in Computer Engineering
on August 4, 2012. His fields of
interest
include
Artificial
Intelligence and Robot Vision.
He plans to enter the work force
for a few years before returning
to school for a Masters degree in
his field.
Gabriel Rodriguez is a
senior at the University of
Central Florida. His interests are
in embedded systems, analog
and digital circuit design, and
wireless communication. He is
graduating with a degree in
Electrical
Engineering
on
August 4, 2012.
Blake Simonini is a senior at
the University of Central
Florida. He is graduating with a
degree in Electrical Engineering
on August 4, 2012. He is
interested in robotics and power
systems and is looking to find a
job out of state.