Senior Design: The Bomb-Sniffing Robot

2013-01-06T17:24:00.000-06:00

I recently updated the blog to show a few videos of the working product as well as our initial design idea. These videos can be found in the "Youtube Demos" section.

Creating robot chassis

2011-03-01T07:02:00.001-06:00

Towards the end of last week, heat sincs and H-bridges came in.I also went to home depot to purchase more material for the robot chassis.

1/4" washers (12 in each package) x 10 = 112 pcs.

3 threadless rod USS/Coarse stainless steel, 1/4"-20 x36"

1/16", 3/4"x36" thick angeled aluminum rod (for mounting tracks to base platforms)

Hex Nut course thread zinc plated 1/4"-20 (100 pcs.)

3 packages of #8-32x3/4" zinc machine screws (8 pcs) x 3= 24 pcs

pencil compactor for measuring the cardboard out (if need be)

caliper for measuring components on the fly

krylon fusion for plastic, metal, wood, wiker, and more tan paint

storage organizer for parts

Picture of these materials and more can be found below.

The actual mock-up should be finished this week. I figured out how to print out the mock-ups in Google Sketch to scale, so all I need to do is print those out and mark my cardboard where I need to cut. Then if everything fits as planned, I use that to cut the plastic and etc.

Another change in the 3d mockup

2011-02-18T17:26:00.004-06:00

Increased length width of robot deck to 10". Overall the robot is 5" Height x 14" wide. Also added some dimensions that were not specified the last picture.

John and I bought some thick plastic sheets (Acrylic Sheets x2 for $13.50) at Home Depot today.

The motor controller's H-bridge power N-MOSFETS came in yesterday.

We also got in the mail today the crazy motors from DC Planetary Gear Brush Motor- PK32kd3b2100-027. The spec sheet is below the picture of the motors.

2nd mock of the Robot Chassis with Google Sketchup

2011-02-18T12:32:00.000-06:00

After talking with my Senior design group, I found out a few ideas to increase space on-board the robot's deck. All I need to do is add another deck. I plan on sticking the camera material there. The second deck will be for the sensors and batter. The bottom deck is for the router. Here is the picture so far. John also added the pan/tilt head for the camera.

Designing the Robot Chassis with Google Sketchup

2011-02-18T02:01:00.001-06:00

Today, I spent the majority of the day learning Google Sketchup and making the parts and models that belong on the robot. However, I am running into a few mechanical considerations.

1) the camera is LARGER than I expected. I need to consider taking the camera out of the bubble and/or extending it from the base.

2) the Router is also LARGE. Where should I stick this thing? We also need room for sensors and a battery. Crap... I only have so many links for the car, so it will be more difficult to increase the length of the robot.

Too bad I am not a mechanical engineer...

I hope my team members can give me some suggestions on how to fix this issue of space.

LCD for debugging- Graphic LCD 128x64 STN LED with Backlight

2011-02-10T21:00:00.001-06:00

For future debugging, I would like to talk to John about purchasing this graphic LCD found on SparkFun (http://www.sparkfun.com/products/710). This could come in handy when we are trying to debug features during runtime/testing functionality.

Description: This is a framed graphical LCD 64x128 with LED backlight. This unit is a very clear STN type LCD with a simple command interface. This new module includes the negative voltage circuitry on board!

Utilizes the extremely common KS0108B parallel interface chipset (datasheet). Interface code is freely available. Includes LED Backlight.

Dimensions:

Overall: 75x52.7mm
Viewable area: 55.01x27.49mm

Documents:

Finalized GPS Receiver and Antenna

2011-02-10T20:17:00.001-06:00

Today, I finally picked the GPA module and antenna to use for our BSF (Bomb Sniffing Robot). Here are our previous considerations, the highlighted (Venus GPS with SMA connector - http://www.sparkfun.com/products/9133) one is the final GPS module picked.

As for the antenna, we are going to use the Antenna GPS Embedded SMA - http://www.sparkfun.com/products/177.

The VTourch antenna has the following specifications/features:

Gain 26dB
VSWR <2.0
Voltage 3.3V +/- 0.5V
Current 12mA
Weight 18g

GPS research in progress (1/3/11)

2011-02-03T16:47:00.003-06:00

Today, I found out that to do fast debugging for the GPS module I will need a cheap LCD display. More than likely, I will use old code from 319k and use the same cheap module. NEED TO TELL JOHN THIS. NOT SURE IF IT IS ON THE BOM.

Valvano has his EE345J, graduate class, students design and evaluate a battery-powered GPS and IMU system (lab document link here: http://users.ece.utexas.edu/~valvano/EE385J/Lab5_GPS_IMU_PaineCao.pdf). This design integrates data form multiple sensors in order to enhance accuracy of measured data. I need to email him to get more info on this class project.

SOFTWARE

How the students designed it is as follows, the program is divided in to 5 major functions. An infinite loop in the main which uses a foreground task that controls the GPS, which continuously reads from the SCI and preprocessing TSIP report packets as they arrive. The report packet as a structer as follows:

The <DLE> byte is 0x10. Data bytes 0x10 are padded with an extra <DLE> byte. The foreground loop continuously reads in data from the GPS module. When a new report packet is detected, it saves the data

bytes, stripping any padding bytes, in a global byte array buffer. Once it detects the end of a report packet, procCmd() is called and is passed the <ID> of the report packet.

The procCmd() function processes the data bytes in the buffer according to what packet ID it received. The two main packets have IDs 0x46, health of receiver, and 0x84, LLA position in doubleprecision. The health of receiver packet reports if the GPS module is functioning correctly and how many satellites it has locked on to. This is stored in a global byte variable, gpsState, which can be output on the LCD for debug purposes. The 0x84 packets give latitude and longitude in radians in 8-byte double-precision floating point format. They get stored in a global latitude and longitude variable that tracks position, and converted into positions on the map and stored in global unsigned char variables.

Here is the software flow chart found below.

Of course, the GPS will be on the robot, so this flow chart will not be entirely accurate. I will modify this to incorporate reading control information from the controller (hooked up to the PC/host).

Embedded Sytem Design Software Starter Files (Valvano)

HARDWARE

------------------------------------------------------

GPS Overview (a summary of sparkfun's overview: http://www.sparkfun.com/tutorials/68)

Performance Concerns

Start Time-

How quickly the module can lock- when a lock is made the module can receive the GPS signal from satellites to calculate position. The amount of time required is referred to as, START TIME.

Positional Accuracy of the module-

How well it gets and holds the lock in the presence of obstacles (urban setting, canyon areas, etc)

Dependencies for performance:

Number of Satellite Channels- the module can simultaneously receive is an important specification. GPS modules today can receive up to 20 channels. More channels mean more places for the modules to look for a signal, corresponding to faster locking times and better locking in urban settings.
Onboard processing of the GPS signal- new chipsets such as the SiRF III provide faster and more robust locking than previous SiRF II based designs. Ne featers such as wide area augmentation system (WAAS), or differential GPS (DGPS) provide better positional accuracy by correcting GPS signals using other sources (such as ground stations).

Interface

Easy to use!

NMEA 0831 compatable
can oubout standard NMEA messages every second
reporting speed
3D position
number of stallites in view
GPS time
and more...
NMEA output- is the default, so all the user needs to do is apply power and the module begins spitting out NMEA data.
protocol differs from module to module

check data sheet to see what commands and protocols are available

Batteries and Antennas

Needs batter

IN PROGRESS!!!

Meeting Notes 2/1/11

2011-02-01T15:32:00.000-06:00

Have individual meetings for tasks getting done
Who is responsible for what:

Kirtan

Gas Sensors = kirtan

op amps, low pass filters, etc...
circuit design
pcb layout

Motors

motor controller
pcb layout

Charis

Mechanical
GPS

figure out exact power
unit: let them know what it interfaces with--- serial, spi, rs-232, ttl-serial
figure out the model
MAX232: TI has them

John

PCB design
Camera control
embedded wireless communications (ethernet controller)
Power

Hieu

LabVIEW

video
controller via usb
networking between robot and GUI

Lehar

LabVIEW

video
controller via usb
networking between robot and GUI
Create communication standard (excel spread sheet)

TO DO:
Charis - send lehar and hieu the communication standard paper in labVIEW
John- BOM link on front page
Everything ordered by next thursday (2/11/11)

finalize parts for power, units, and etc
design your circuit
prototype for the prototype
parts need to be here by 2/17-18/11

While things are coming in make sure to program chips/begin
Lehar- contact the physics and chemistry department + EUREKA

radiation
chemical

Organization:

g-groups = easy email
wiki = use to store research and final design
google docs = multiple editing
dropbox = final editions (personal documents other might want access to)

LabVIEW meeting tomorrow

6-9
make sure to RSVP (E-mail John sent)

Meeting Notes 1/28/11

2011-01-28T17:26:00.002-06:00

introduce Lehar Gupta- what is she working on ?
exchange contact info -- Charis will add Lehar to Wiki.
get her set up on g-docs, dropbox, group, and wiki --
get her up to speed on our project status
TI/NI competition = free money and design components
need to talk to someone ASAP about chemical and radiation testing!!!
reassign a writing task for paper due next wed?
work on paper together
discuss individual research progress (a quick "I have done/not done X,Y,Z this week..." and "I plan to do X,Y,Z next week")
John is going to add Ethernet to the BOM
Need to get a GPS of good accuracy -- Capernecos/GPS09159(20 channel)
new camera option
needing a remote wireless access point for video (wifi router/server module)

More written notes between Charis and Lahar are below. Lahar will be programming/creating the communication protocol between the robot and the host. Here we discussed what data is being passed and what the communication standard may look like. Furthermore, how to check that the data was not corrupted during transmission (parity bits, CRC, TCP protocol).

We also came to conclusion that the Women in Engineering program at UT might know of some useful resources for our design implementation.

Design Implementation Plan Meeting (January 25, 2011)

2011-01-25T19:30:00.002-06:00

Due: Febuary 3, 2011(Thursday @ 12:30 PM)

Needs to be 8-12 pages. Should not be a copy of System Design Paper from last semester. Make sure to discuss new content and design.

Introduction (do @ end together)

Problem Background (1/2-1 page) (Hieu)

like problem statement ( first paper) + key operation requirement (last paper)
introduce with table and explain subsection
Technical

specifications, constraint, requirements

lbs
wireless range
response time
battery life
speed
etc...

sensor array

why we choose the sensor

data transfer

wifi
sensor
controller host
video

Deliverables

user manual
code
schematic
prototype (look last paper for adding more detail)
bom
fabrication/ Electrical/mechanical schematic

Description of Design (Charis + Kirtan)

refer to last paper (System design)
Make sure to add hardware flow diagrams
flow like picture( User ->controller -->UI/Host <--> Robot)

preliminary design

camera
table

option 1: select reason (why we choose = specifications and etc answered here)
option 2: select reason (why we choose = specifications and etc answered here)

Implementation Plan (John)

Project activity, schedule, and collaboration
Project materials and costs
** John will email us for items he specifically needs our input on **
Charis has a ton of old reference material- contact her when you need specific documentation

some can be found on blog, dropbox, or g-docs
Others are on her personal computer

Conclusion (do @ end together)

Friday, January 21, 2011 - 1st meeting

2011-01-21T17:03:00.006-06:00

Wiki- John made: http://www.kungfubrew.com/home/wiki/

Use this for your research, design, etc

John's camera

POE (power by ethernet )
4 data, 4 power
-48 volts
convert 3.6, 7.2
we need a solution for the battery
transmits over ethernet to a webpage
active x capabilty
John will look into the camera stuff

and explaining it better to us
video capture controller?

Look into other material

70 lbs is our limit for the robot

Enter into the TI competition
Power

Allocate appropriately
camera could take a lot of power

Sleep mode??

Extra do not worry about now
Programming

Processor:

Begal board???
9s12
PIC
msp430 (TI)
more flash
less ram (to hold program)

Motor

Powerful motor for $$
H-bridge or motor controller

Motor controller might be better for our money

To do:

Labview programming
wireless communication
labview sensor/dada interfacing
mechanical design
motors and motor controller
sensors

adc
antenna
type (bomb)

co
lpg
methane

DETERMINES PINS FOR MCU

Who is doing what (this week):

John

Sensors
Video

Charis

LabVIEW

controller/usb
video display

Mechanical schematics of robot

Hiew

Wireless
XBEE

Kirtan

Sensors
Motor

*** MAKE SURE TO PUT ALL PARTS IN BOM **
BE READY TO TALK ABOUT YOUR DESIGN RESEARCH IN DETAIL
TA MEETING TUES @ 12:40

Tips for Senior Design Success + New Team Member (John)

2011-01-20T18:32:00.002-06:00

First of all welcome John Walthour, he is our newest member with embedded and power experience.
------
1) Work closely w/ your faculty mentor or TA mentor. Make sure that he or she fully understands you project, problems you encounter, and your status at any time. Your mentor has the biggest influence on your grade.

2) Do not limit your project to the basic lab hours. The general "rule of thum" for a couse is 3 hours of outside work per credit hour.

3) Put a lot of effort into your written reports and follow the guidelines to the letter. Get help form the writing TAs or the Undergraduate Writing Center if needed.

4) Do not turn in anything late.

5) Complete your project. (It is due at end of April NOT MAY).

Also, for those using the second floor labs, pleas be careful not to disrupt the other organized lab courses when in session (large labs). Please use the perimeter labs (204, 207-11, 224, 227) or 252C if possible, although we do realize that some students will need to use the power lab (212) and the logic analyzers.

Finally, New soldering stations and a surface mount soldering oven will be installed in the 2nd floor labs this semester.
----------------
Dr. Fagelson presentation

A set of coordinated human activities that begins with a definition of a problem or need and ends with a problem solution or product.

Why do project fail? Unforeseen circumstances. You do not anticipate problems and prepare properly.

Unforseen vs. unforseeable- a good project prepares for all but teh unforeseeable.

Unforseeable

unqualified team members (ignorant or poor engineers)

Foreseeable

task list - you know what needs to get done
team inventory - you see what you have and can access it. Who is responsible for what
design review meeting - you present to your TA and get on the same page with this person.
design implementation plan- you need to keep organization scheme. You need a clear sense of direction: change, problems, sense of where you are headed, etc...

Try to reduce the "learn-as-you-go"
Touch base with your mentor
Where the project is headed

plan
who does what- GANTT CHART (need to revise)
Can you afford to do this- BILL OF MATERIALS

know what your budget is
plan that you may wan to purchase new things
or purchase additional things (unexpected costs)

Lack of time

project flow diagram
gannt chart -

We are behind

we are not managing our time very well, you need to react to falling behind fast and etc.

design review meeting
design imp plan
weekly project status reports
progress report

Critical path- foreseeable

The sequence of act that must be completed on schedule for the entire project to be completed on schedule
You need to reduce the bottle neck
recognize them and figure out how to get past them

Poor team work - foreseeable

Project manager - someone who deals out stuff, are we on schedule, are we on budge, is someone aware that some ppl are not doing their job, address the problems. Do not just let the problem sit there. ADDRESS IT IMMEDIATELY!!!!!!!
Project Mentor
Team Peer Assessments
Collaboration Tools
Weekly status meetings

Disaster/accident--- Unforeseeable

Prepare for these
Try to get ahead not behind.

Expecting the unexpected

All of the ways in which you are prepared for the foreseeable depend on the sound planning and good project management.
Writing needs to get done. It helps communicate your project. Writing is just as important as design.

Communication: Planning

Design work in 364D
Design review meeting
design impl. plan
testing and eval plan
Do not "figure out as you go"
Have a "here is what we are going to do...."
If someone does all this work and does not tell someone about it, IT MEANS NOTHING!

-----
Writing TAs and what you can expect form them: Emily

Follow course notes:
Know where to turn things in ENS 330, successful papers are 25-30 pages, first couple are 8-12 pages
interpret guidelines to fit with your paper-- talk to the TAs

brainstorming
drafting
don't think you can do it fast and get a good grade (it will take time)

Overview of expectations

feedback on paper and grading rubric
come see them as often as possible

Writing considerations

Review guidelines multiple times
familiar w/ assessment form
spend time evaluation and analyzing the material
review commas, semi-colons, and colons if needed

----

Emily- presentations

Workshop will cover delivery, structure, content, and visuals
2 presentations will cover different material
5 workshops, offered @ different times over the course of the semester

only 2 members need to go at a time
choose a workshop that appeals to you
TIMES POSTED ON BB
don't wait until the last sec
don't sign up and not show up

email if you cannot show up

Office hrs are on BB.

Team Fantastic is mutating?

2011-01-18T19:19:00.002-06:00

Today, I had a lovely day packed full of senior design woes and joys.

Woes include:

Losing 3 of our old members
Learning about the new and confusing Senior Design system
Finding out we lost our awesome technical TA
Discovering we might get stuck with a technical TA, instead of a faculty mentor
Fully grasping what a crazy time commitment this project is going to be
Discussing testing difficulties with professor Valvano
Searching for 1-2 more members

Joys include:

Gaining a new member (Hieu Nguyen) with wireless and embedded programming experience
Discovering we might get a professor mentor for our project
Discussing technical design with professor Valvano
Talking with fellow electrical/computer engineering colleagues and professors

You gotta love college and all the fun it provides you with. Here is to the new year, the new team member, and to adventures we shall have together.

Peace,
Charis

Final System Design Paper for EE364D (Intro to Senior Design)

2010-12-01T17:13:00.003-06:00

This week has been extremely crazy with all my classes. The team got the paper done (a little late), but I think it turned out well. I don't care what the TAs say, unless it is regarding design flaws or recommendations. I think we are finally getting somewhere in the design. Thanks to everyone's help (Cassy, Kirtan, Mesele, and Lehar).

Link to System Design Paper here: http://www.mediafire.com/?m5mco89qp8jn8u7 .

The next step, is making sure everyone is prepared for design. Kirtan and I have discussed working a little on the design over the holidays. I would like both of us to brain storm how to get everyone up to speed on what they need to do (design-wise) next semester. Obviously, I would like to pull from each of the team member's strengths and teach them how to successfully attack a design problem.

Here is to the hope our design implementation phase is a successful and fun adventure.

Over and out,
Charis

USB Protocols- Beyond Logic Tutorial

2010-11-29T19:32:00.007-06:00

This information is for my reference when I start communicating the PlayStation controller to the LabVIEW host (processing for the user interface). Information was obtained from http://www.beyondlogic.org/usbnutshell/usb3.shtml .

USB Protocols

Unlike RS-232 and similar serial interfaces where the format of data being sent is not defined, USB is made up of several layers of protocols. While this sounds complicated, don’t give up now. Once you understand what is going on, you really only have to worry about the higher level layers. In fact most USB controller I.C.s will take care of the lower layer, thus making it almost invisible to the end designer.

Each USB transaction consists of a

Token Packet (Header defining what it expects to follow), an
Optional Data Packet, (Containing the payload) and a
Status Packet (Used to acknowledge transactions and to provide a means of error correction)

As we have already discussed, USB is a host centric bus. The host initiates all transactions. The first packet, also called a token is generated by the host to describe what is to follow and whether the data transaction will be a read or write and what the device’s address and designated endpoint is. The next packet is generally a data packet carrying the payload and is followed by an handshaking packet, reporting if the data or token was received successfully, or if the endpoint is stalled or not available to accept data.

Common USB Packet Fields

Data on the USBus is transmitted LSBit first. USB packets consist of the following fields,

Sync

All packets must start with a sync field. The sync field is 8 bits long at low and full speed or 32 bits long for high speed and is used to synchronise the clock of the receiver with that of the transmitter. The last two bits indicate where the PID fields starts.

PID

PID stands for Packet ID. This field is used to identify the type of packet that is being sent. The following table shows the possible values.

There are 4 bits to the PID, however to insure it is received correctly, the 4 bits are complemented and repeated, making an 8 bit PID in total. The resulting format is shown below.

ADDR

The address field specifies which device the packet is designated for. Being 7 bits in length allows for 127 devices to be supported. Address 0 is not valid, as any device which is not yet assigned an address must respond to packets sent to address zero.

ENDP

The endpoint field is made up of 4 bits, allowing 16 possible endpoints. Low speed devices, however can only have 2 additional endpoints on top of the default pipe. (4 endpoints max)

CRC

Cyclic Redundancy Checks are performed on the data within the packet payload. All token packets have a 5 bit CRC while data packets have a 16 bit CRC.

EOP

End of packet. Signalled by a Single Ended Zero (SE0) for approximately 2 bit times followed by a J for 1 bit time.

USB Packet Types

USB has four different packet types. Token packets indicate the type of transaction to follow, data packets contain the payload, handshake packets are used for acknowledging data or reporting errors and start of frame packets indicate the start of a new frame.

Token Packets

There are three types of token packets,

In - Informs the USB device that the host wishes to read information.
Out - Informs the USB device that the host wishes to send information.
Setup - Used to begin control transfers.

Token Packets must conform to the following format,

Data Packets

There are two types of data packets each capable of transmitting up to 1024 bytes of data.

Data0
Data1

High Speed mode defines another two data PIDs, DATA2 and MDATA.

Data packets have the following format,

Maximum data payload size for low-speed devices is 8 bytes.
Maximum data payload size for full-speed devices is 1023 bytes.
Maximum data payload size for high-speed devices is 1024 bytes.
Data must be sent in multiples of bytes.

Handshake Packets

There are three type of handshake packets which consist simply of the PID

ACK - Acknowledgment that the packet has been successfully received.
NAK - Reports that the device temporary cannot send or received data. Also used during interrupt transactions to inform the host there is no data to send.
STALL - The device finds its in a state that it requires intervention from the host.

Handshake Packets have the following format,

Start of Frame Packets

The SOF packet consisting of an 11-bit frame number is sent by the host every 1ms ± 500ns on a full speed bus or every 125 µs ± 0.0625 µs on a high speed bus.

USB Functions

When we think of a USB device, we think of a USB peripheral, but a USB device could mean a USB transceiver device used at the host or peripheral, a USB Hub or Host Controller IC device, or a USB peripheral device. The standard therefore makes references to USB functions which can be seen as USB devices which provide a capability or function such as a Printer, Zip Drive, Scanner, Modem or other peripheral.

So by now we should know the sort of things which make up a USB packet. No? You're forgotten how many bits make up a PID field already? Well don't be too alarmed. Fortunately most USB functions handle the low level USB protocols up to the transaction layer (which we will cover next chapter) in silicon. The reason why we cover this information is most USB function controllers will report errors such as PID Encoding Error. Without briefly covering this, one could ask what is a PID Encoding Error? If you suggested that the last four bits of the PID didn't match the inverse of the first four bits then you would be right.

Most functions will have a series of buffers, typically 8 bytes long. Each buffer will belong to an endpoint - EP0 IN, EP0 OUT etc. Say for example, the host sends a device descriptor request. The function hardware will read the setup packet and determine from the address field whether the packet is for itself, and if so will copy the payload of the following data packet to the appropriate endpoint buffer dictated by the value in the endpoint field of the setup token. It will then send a handshake packet to acknowledge the reception of the byte and generate an internal interrupt within the semiconductor/micro-controller for the appropriate endpoint signifying it has received a packet. This is typically all done in hardware.

The software now gets an interrupt, and should read the contents of the endpoint buffer and parse the device descriptor request.

Endpoints

Endpoints can be described as sources or sinks of data. As the bus is host centric, endpoints occur at the end of the communications channel at the USB function. At the software layer, your device driver may send a packet to your devices EP1 for example. As the data is flowing out from the host, it will end up in the EP1 OUT buffer. Your firmware will then at its leisure read this data. If it wants to return data, the function cannot simply write to the bus as the bus is controlled by the host. Therefore it writes data to EP1 IN which sits in the buffer until such time when the host sends a IN packet to that endpoint requesting the data. Endpoints can also be seen as the interface between the hardware of the function device and the firmware running on the function device.

All devices must support endpoint zero. This is the endpoint which receives all of the devices control and status requests during enumeration and throughout the duration while the device is operational on the bus.

Pipes

While the device sends and receives data on a series of endpoints, the client software transfers data through pipes. A pipe is a logical connection between the host and endpoint(s). Pipes will also have a set of parameters associated with them such as how much bandwidth is allocated to it, what transfer type (Control, Bulk, Iso or Interrupt) it uses, a direction of data flow and maximum packet/buffer sizes. For example the default pipe is a bi-directional pipe made up of endpoint zero in and endpoint zero out with a control transfer type.

USB defines two types of pipes

Stream Pipes have no defined USB format, that is you can send any type of data down a stream pipe and can retrieve the data out the other end. Data flows sequentially and has a pre-defined direction, either in or out. Stream pipes will support bulk, isochronous and interrupt transfer types. Stream pipes can either be controlled by the host or device.

Message Pipes have a defined USB format. They are host controlled, which are initiated by a request sent from the host. Data is then transferred in the desired direction, dictated by the request. Therefore message pipes allow data to flow in both directions but will only support control transfers.

UI Mock Version 1

2010-11-29T17:18:00.006-06:00

Today, I finally got around to making my first mock-up of the user interface (UI). Here are my results. I have very little experience with UI design. If anyone has any comments on anything involving our graphical design, features, or just UI design in general please comment.

If you are interested in the LabVIEW code please click this link (http://www.mediafire.com/?7zo9sf44oqp42ji) or see our open source downloads page (http://bombsniffingrobot.blogspot.com/p/open-source-design-downloads.html).

Figure 1 below shows the video display screen of the UI. Here the user can simultaneously view four graphs of the sensor (selected in the drop down menu below each graph), while observing the robot's on-board camera. Since this is the primary screen used during normal operation, on the right the user has access to both the robot's battery health and controller connectivity.

Figure 2 shows the sensor information in a graphical format. Here the user can export the information to Excel or a text file to do further computation in other programs.

Figure 3 is the screen that allows the user to view common configuration settings and system statuses. Currently, the user has control over the robot's network settings and where data collected from the robot is saved.


Figure 1: Video Display

Figure 2: Graph Display

Figure 3: ConfigurationDisplay

User Interface with LabVIEW and Paper Mock-Ups

2010-11-28T18:00:00.005-06:00

Discovered on Tomi Maila's blog on "Designing LabVIEW User Interfaces with Hand-Drawn Paper Mock-Ups" found http://expressionflow.com/2007/05/16/designing-labview-user-interfaces-with-hand-drawn-paper-mock-ups/ . In his blog he goes in depth on how to take into account user roles, views of your user interface, and how to implement design in LabVIEW with paper mock-ups.

User interface may be the one most important part of your LabVIEW application. It’s the only part of the application the end-user is directly in contact with. Still user interface is often the part of a LabVIEW application developers spend the least time with in the development process. Does LabVIEW make creating decent user interfaces too easy to be ignored in the design phase?

User roles

Let’s concentrate on graphical user interfaces. What should a user interface design process be like? The user interface design shoud start with determinig the different user roles of your application. For example you may need to have a different kind of user interface for the end-users as you do for the administrators.

Views of your user interface

After you have indetified different user roles you should list the main tasks a users in different user roles uses your application. It’s important not to go into too much detail, just concentrate on the most important tasks. The number of main tasks depends on your application. Determine what kind of views do you need in your application to allow users to do these main taks you have identified. You may need multiple different views such as monitoring view and configuration view and visualization view. Depending on your application, these views may be separate parts of a single window, different states of a window or separate windows.

Paper mock-ups

Once you have determined the main views you’ll need in your application you should not hurry to your computer and start coding. Instead you should sit down, take you pen and paper and start drawing mock-ups of your user interface. A mock-up is a model of you user interface. With pen and paper it’s easy and fast to try different variations of component locations. Also the drawing process helps you to concentrate on the important parts and not to go into too much detail too soon. You identified different main tasks the users need to do with your application. Go trough these tasks with your paper mock-ups. If there are major state changes in your views, don’t spare the paper. Try to cover all important views of you application and all important states of different views. Play around, all time consumed in the paper user interface design phase is well spend.

Usability testing

Next you should grap a small group of potential users and show them the user interface mock-ups you have made. Users tend to think differently from what you expect so it’s important to get into direct contact with the potential users. Show them your user interface paper models and ask them to proceed with the important tasks. Don’t help them too much, let them figure out by them-selves what to do, which button to press. Simulate the user interface functionality by showing them different pieces of paper. Use your imagination to find a nice way to simulate your user interface without a computer. Again, don’t go into too much detail, concentrate on the most important parts. If your test users don’t behave the way you would expect them to, ask them what would be the intuitive way for them to proceed with the tasks.

Hand drawn paper user interface models are an excellent tool for the user testing. In computer graphics based user interface models, the tested users tend to concentrate too much on the details and on the lack of polishing. With hand drawn paper models it’s evident that they are only models and users don’t expect them to be polished. Instead they concentrate on the usability and that is exactly what you want to test with them.

Don’t be afraid with the user test phase. You can really often find suitable test persons from your work or from your friends. Testing your user interface doesn’t take a lot of time but you get plenty of valuable feedback. With this feedback you need to go back to your desk and start considering how to make your user interface better, how would it serve your users better.

Conclusions

User interface design is an iterative process. Depending on the complexity of your user interface you may need to iterate the process several times. Only after you are happy with your paper models, you should start working on real front panel implementations. There are many ways of designing user interfaces and this particular process I learnd from useability experts when working on a consumer product project.

Take a look at Jim Kring’s related post on Human Interface Guidelines on his blog Thinking in G.

User Interface Design- Hallway Testing / Human Action Cycle / Evaluation

2010-11-28T17:52:00.003-06:00

As I dived into the world of user interface design, I found some interesting information. One in particular was found here: http://www.scribd.com/doc/2409206/User-Interface-Design

I have no clue who created this paper, but it hits some good points to take into consideration while designing the UI.

Hallway testing

Hallway testing(or hallway usability testing) is a specific methodology of software usability testing. Rather than using an in-house, trained group of testers, just five to six random people, indicative of a cross-section of end users, are brought in to test the software (be it an application, web site, etc.); the name of the technique refers to the fact that the testers should be random people who pass by in the hallway. The theory, as adopted from Jakob Nielsen's research, is that 95% of usability problems can be discovered using this technique.

In the early 1990s, Jakob Nielsen, at that time a researcher at Sun Microsystems,
popularized the concept of using numerous small usability tests -- typically with only five test subjects each -- at various stages of the development process. His argument is that, once it is found that two or three people are totally confused by the home page, little is gained by watching more people suffer through the same flawed design. "Elaborate usability tests are a waste of resources. The best results come from testing no more than 5 users and running as many small tests as you can afford." 2. Nielsen subsequently published his research and coined the term heuristic evaluation.

The claim of "Five users is enough" was later described by a mathematical model[2] which states for the proportion of uncovered problems U

U = 1 − (1 − p)ⁿ

where p is the probability of one subject identifying a specific problem and n the number of subjects (or test sessions). This model shows up as an asymptotic graph towards the number of real existing problems.

In later research Nielsen's claim has eagerly been questioned with both empirical evidence 3 and more advanced mathematical models (Caulton, D.A., Relaxing the homogeneity assumption in usability testing. Behaviour & Information Technology, 2001. 20(1): p. 1-7.). Two of the key challeges to this assertion are: (1) since usability is related to the specific set of users, such a small sample size is unlikely to be representative of the total population so the data from such a small sample is more likely to reflect the sample group than the population they may represent and (2) many usability problems encountered in testing are likely to prevent exposure of other usability problems, making it impossible to predict the percentage of problems that can be uncovered without knowing the relationship between existing problems. Most researchers today agree that, although 5 users can generate a significant amount of data at any given point in the development cycle, in many applications a sample size larger than five is required to detect a satisfying amount of usability problems.

Bruce Tognazzini advocates close-coupled testing: "Run a test subject through the product, figure out what's wrong, change it, and repeat until everything works. Using this technique, I've gone through seven design iterations in three-and-a-half days, testing in the morning, changing the prototype at noon, testing in the afternoon, and making more elaborate changes at night." 4 This testing can be useful in research situations.

Human action cycle

The human action cycle is a psychological model which describes the steps humans take when they interact with computer systems. The model was proposed by Donald A. Norman, a scholar in the discipline of human-computer interaction. The model can be used to help evaluate the efficiency of a user interface (UI). Understanding the cycle requires an understanding of the user interface design principles of affordance, feedback, visibility and tolerance.

The human action cycle describes how humans may form goals and then develop a seriesof steps required to achieve that goal, using the computer system. The user then executesthe steps, thus the model includes both cognitive activities and physical activities.

This article describes the main features of the human action cycle. See the following book by Donald A. Norman for deeper discussion:

The three stages of the human action cycle

The model is divided into three stages of seven steps in total, and is (approximately) as

follows:

1) Goal formation stage

· Goal formation.

2) Execution stage

· Translation of goals into a set of (unordered) tasks required to achieve the goal.

· Sequencing the tasks to create the action sequence.

· Executing the action sequence.

3) Evaluation stage

· Perceiving the results after having executed the action sequence.

· Interpreting the actual outcomes based on the expected outcomes.

· Comparing what happened with what the user wished to happen.

Use in evaluation of user interfaces

Typically, an evaluator of the user interface will pose a series of questions for each of the
cycle's steps, an evaluation of the answer provides useful information about where the
user interface may be inadequate or unsuitable. These questions might be:

· Step 1, Forming a goal:

o Do the users have sufficient domain and task knowledge and sufficient understanding of their work to form goals?

o Does the UI help the users form these goals?

· Step 2, Translating the goal into a task or a set of tasks:

o Do the users have sufficient domain and task knowledge and sufficient understanding of their work to formulate the tasks?

o Does the UI help the users formulate these tasks?

· Step 3, Planning an action sequence:

o Do the users have sufficient domain and task knowledge and sufficient understanding of their work to formulate the action sequence?

o Does the UI help the users formulate the action sequence?

· Step 4, Executing the action sequence:

o Can typical users easily learn and use the UI?

o Do the actions provided by the system match those required by the users?

o Are the affordance and visibility of the actions good?

o Do the users have an accurate mental model of the system?

o Does the system support the development of an accurate mental model?

· Step 5, Perceiving what happened

o Can the users perceive the system’s state?

o Does the UI provide the users with sufficient feedback about the effects of their actions?

· Step 6, Interpreting the outcome according to the users’ expectations:

o Are the users able to make sense of the feedback?

o Does the UI provide enough feedback for this interpretation?

· Step 7, Evaluating what happened against what was intended:

o Can the users compare what happened with what they were hoping to achieve?

A Quick Discussion on DC Motors- Society of Robotics

2010-11-17T02:05:00.002-06:00

Information obtained from the Society of Robots website. Link found here: http://www.societyofrobots.com/actuators_dcmotors.shtml.

I am placing this material in my blog order to refer to when finalizing motor selection.

ACTUATORS - DC MOTORS TUTORIAL

From the start, DC motors seem quite simple. Apply a voltage to both terminals, and weeeeeeee it spins. But what if you want to control which direction the motor spins? Correct, you reverse the wires. Now what if you want the motor to spin at half that speed? You would use less voltage. But how would you get a robot to do those things autonomously? How would you know what voltage a motor should get? Why not 50V instead of 12V? What about motor overheating? Operating motors can be much more complicated than you think.

Voltage
You probably know that DC motors are non-polarized - meaning that you can reverse voltage without any bad things happening. Typical DC motors are rated from about 6V-12V. The larger ones are often 24V or more. But for the purposes of a robot, you probably will stay in the 6V-12V range. So why do motors operate at different voltages? As we all know (or should), voltage is directly related to motor torque. More voltage, higher the torque. But don't go running your motor at 100V cause thats just not nice. A DC motor is rated at the voltage it is most efficient at running. If you apply too few volts, it just wont work. If you apply too much, it will overheat and the coils will melt. So the general rule is, try to apply as close to the rated voltage of the motor as you can. Also, although a 24V motor might be stronger, do you really want your robot to carry a 24V battery (which is heavier and bigger) around? My recommendation is do not surpass 12V motors unless you really really need the torque.

Current
As with all circuitry, you must pay attention to current. Too little, and it just won't work. Too much, and you have meltdown. When buying a motor, there are two current ratings you should pay attention to. The first is operating current. This is the average amount of current the motor is expected to draw under a typical torque. Multiply this number by the rated voltage and you will get the average power draw required to run the motor. The other current rating which you need to pay attention to is the stall current. This is when you power up the motor, but you put enough torque on it to force it to stop rotating. This is the maximum amount of current the motor will ever draw, and hence the maximum amount of power too. So you must design all control circuitry capable of handling this stall current. Also, if you plan to constantly run your motor, or run it higher than the rated voltage, it is wise to heat sink your motor to keep the coils from melting.

Power Rating
How high of a voltage can you over apply to a motor? Well, all motors are (or at least should be) rated at a certain wattage. Wattage is energy. Innefficieny of energy conversion directly relates to heat output. Too much heat, the motor coils melt. So the manufacturers of [higher quality] motors know how much wattage will cause motor failure, and post this on the motor spec sheets. Do experimental tests to see how much current your motor will draw at a desired voltage.
The equation is:

Power (watts) = Voltage * Current

Power Spikes
There is a special case for DC motors that change directions. To reverse the direction of the motor, you must also reverse the voltage. However the motor has a built up inductance and momentum which resists this voltage change. So for the short period of time it takes for the motor to reverse direction, there is a large power spike. The voltage will spike double the operating voltage. The current will go to around stall current. The moral of this is design your robot power regulation circuitry properly to handle any voltage spikes.

Torque
When buying a DC motor, there are two torque value ratings which you must pay attention to. The first is operating torque. This is the torque the motor was designed to give. Usually it is the listed torque value. The other rated value is stall torque. This is the torque required to stop the motor from rotating. You normally would want to design using only the operating torque value, but there are occasions when you want to know how far you can push your motor. If you are designing a wheeled robot, good torque means good acceleration. My personal rule is if you have 2 motors on your robot, make sure the stall torque on each is enough to lift the weight of your entire robot times your wheel radius. Always favor torque over velocity. Remember, as stated above, your torque ratings can change depending on the voltage applied. So if you need a little more torque to crush that cute kitten, going 20% above the rated motor voltage value is fairly safe (for you, not the kitten). Just remember that this is less efficient, and that you should heat sink your motor.

Velocity
Velocity is very complex when it comes to DC motors. The general rule is, motors run the most efficient when run at the highest possible speeds. Obviously however this is not possible. There are times we want our robot to run slowly. So first you want gearing - this way the motor can run fast, yet you can still get good torque out of it. Unfortunately gearing automatically reduces efficiency no higher than about 90%. So include a 90% speed and torque reduction for every gear meshing when you calculate gearing. For example, if you have 3 spur gears, therefore meshing together twice, you will get a 90% x 90% = 81% efficiency. The voltage and applied torque resistance obviously also affects speed.

Control Methods
The most important of DC motor control techniques is the H-Bridge. After you have your H-Bridge hooked up to your motor, to determine your wheel velocity/position you must use an encoder. And lastly, you should read up on good DC Motor Braking methods.

Other Information
Place small microfarad capacitors across motor leads to extend motor life. This works really well with noisy and other el-cheapo motors, almost doubling motor life. However there is much less improvement using this technique with the more expensive higher end motors. For a more advanced method on how to choose a motor for your specific robot, check out my tutorial on robot dynamics.

GPS, Servo Motors/Stepper Motors, and Pan/Tilt Head?

2010-11-17T01:03:00.003-06:00

Today, I was compiling my sections for the rough draft for the System Design Report (answers how we are creating the design of our project). Needless to say, I ran into some interesting potential hardware and questions along the way.

My three questions which I will answer in detail below are the following:

Should we really use a servo motor or a stepper motor?
How do you operate a servo motor?
What servos are you looking into?
What GPS module should we use?
How are we moving the camera on top of the robot?

Servo Motor vs. Stepper Motor

I am sure most of you are wondering what the difference between the two? Lucily, I found a great resource discussing the differences between the two (http://www.woodweb.com/knowledge_base/Servo_vs_stepper_motors.html). According to the WoodWeb forum, they stated the following:

A stepper motor is wound in such a way that the rotation has a certain number of discrete "steps". I only know of stepper motors being DC motors. These steps are where the magnetic fields cause the motor to want to settle in one of these positions. The number of steps per revolution is rather high, around two hundred or so, and varies by model and manufacturer. What this means is that the motor has effectively a resolution (smallest controlled movement) equal to the number of steps for that motor. Everything seems to have exceptions, and that applies to steppers also - there are some called micro step, with a higher resolution, but I don’t know much about them. Stepper motors may or may not have position feedback.

A servo motor can be either DC or AC, and is usually comprised of the drive section and the resolver/encoder. A servo motor is much smoother in motion than a comparable stepper, and will have a much higher resolution for position control. The servo family is further divided into AC and DC types. An AC servo had the advantage of being able to handle much higher current surges than a DC, as the DC has brushes, which are the limiting factor in this case. Therefore, for our practical considerations, you can get a lot stronger AC servo motor than you could in DC or stepper configuration. Steppers, on the other hand, have economy as an advantage, and can be incorporated into a design to produce very smooth motion also. The trend for manufacturers of “serious” CNC machinery is to use AC servos. “Entry level” machines may have DC servos, or even steppers.

A resolver/encoder is a glass disc with very fine lines on it and an optical encoder that counts those lines as it rotates with the motor. This information is couple to the controller which tracks the counts, the rate that they go by, and through a host of feedback loops, logic, and controlling the amplifiers, produces the desired motion.

Stepper systems are often “open loop” which means that the controller only tells the motors how many steps to move and how fast to move, but does not have any way of knowing where they actually are. This can lead to errors, should a situation arise where the motors are unable to comply with the commanded move. This can be very obvious, where the motion stops and it sounds like you stripped a gear, or subtle, where the motor only misses a “few” steps. The result is the same - the controller thinks you are at X25.5, Y15.5 and in reality you might be at X25.3, Y15.4 . This can lead to a cumulative error, which may in turn lead to crashes, not to mention out of spec parts.

With all of that said, I have come to the conclusion that since we are moving the robot with tracks. One of the left and right; hence, we can tell the servo motors long to move via the controller direction indicated and speed desired.

Operating a Servo Motor

For those interested in how servos work look at the following site -- http://www.servocity.com/html/how_do_servos_work_.html

The purpose of this information is to give an overview of how servos operate and how to communicate with them. Though we have taken steps to assure the quality of information here, ServoCity makes no guarantees about the information presented. ServoCity cannot be held liable or accountable for any use or misuse of the provided information.

	Servos are controlled by sending them a pulse of variable width. The control wire is used to send this pulse. The parameters for this pulse are that it has a minimum pulse, a maximum pulse, and a repetition rate. Given the rotation constraints of the servo, neutral is defined to be the position where the servo has exactly the same amount of potential rotation in the clockwise direction as it does in the counter clockwise direction. It is important to note that different servos will have different constraints on their rotation but they all have a neutral position, and that position is always around 1.5 milliseconds (ms).



	The angle is determined by the duration of a pulse that is applied to the control wire. This is called Pulse width Modulation. The servo expects to see a pulse every 20 ms. The length of the pulse will determine how far the motor turns. For example, a 1.5 ms pulse will make the motor turn to the 90 degree position (neutral position). When these servos are commanded to move they will move to the position and hold that position. If an external force pushes against the servo while the servo is holding a position, the servo will resist from moving out of that position. The maximum amount of force the servo can exert is the torque rating of the servo. Servos will not hold their position forever though; the position pulse must be repeated to instruct the servo to stay in position. When a pulse is sent to a servo that is less than 1.5 ms the servo rotates to a position and holds its output shaft some number of degrees counterclockwise from the neutral point. When the pulse is wider than 1.5 ms the opposite occurs. The minimal width and the maximum width of pulse that will command the servo to turn to a valid position are functions of each servo. Different brands, and even different servos of the same brand, will have different maximum and minimums. Generally the minimum pulse will be about 1 ms wide and the maximum pulse will be 2 ms wide.
	Another parameter that varies from servo to servo is the turn rate. This is the time it takes from the servo to change from one position to another. The worst case turning time is when the servo is holding at the minimum rotation and it is commanded to go to maximum rotation. This can take several seconds on very high torque servos.

Servo Motors

One of the servos I am looking at is a GWS Servo Motor from RobotShop.com (GWS SERVO). It is $50.00/motor, however I think this is a reasonable price for a stronger and faster motor.

The specifications I am particularly interested are the speed and torque. We need a motor that can move our (my best-guess estimate) 80 lbs / 36 kg car. This motor can easily move that weight per centemeter. Also, it takes 0.12 seconds per 60 degrees of rotation. Which seems like a decent speed for our robot.

• Speed (sec/60deg): 0.12
• Torque (Kg-cm/Oz-in): 42/582
• Size (mm): 65x32x70.4
• Weight (g/oz): 190/6.70

GPS

Well, first before I dive into GPS-- one may ask why we are using GPS? The main point to understand is that we are tracking hazards in an area from a remote distance. It is beneficial for the user to know where the location of the hazard detected. Plus, it adds many potential future applications in the design such as a Google Map tacking, analytics taken on the data retrieved from the sensors (via a graphical analysis), among many others.

Now that is out of the way, what GPS modules are we looking into? And what accuracy is acceptable? The current module we have been considering is the Copernicus DIP Module from SparkFun.com (Copernicus Dip Link Here). As one can see (pictures below), we need to attach an antenna to the module, but I'll hit that topic later.

The Specs are as follows:

Electrical Specifications:

Prime Power: +2.7VDC to 3.3 VDC
Power Consumption:

30.7 mA (82.9 mW) @ 2.7 V
31.3 mA (93.9 mW) @ 3.0 V

Performance:

L1 (1575.42 MHz) frequency, C/A code, 12-channel, continuous tracking receiver

Accuracy

Horizontal: <3 meter (50%), <8 meters (90%)
Velocity: 0.06 m/sec

Sensitivity

Tracking: -152 dBm
Acquisition: -142 dBm

Operational

Speed Limit: 515 m/s

Interface Characteristics:

Connectors:28 surface mount edge castellations
Serial Port: 2 Serial Ports (transmit/receive)
PPS: 3.0 V CMOS-compatable TTL-level puls
Protocols: Supports TSIP (Trimble Standard Interface Protocol), TAIP (Trimble ASCII Interface Protocol), and NMEA (National Marine Electronics Association) 0183 v3.0 Bi-directional NMEA Messages

Camera Movement

To move the camera we need have 3 degrees degrees of freedom. In other words, we need to be able to control the x, y, and z axis positions. A method of accomplishing this task is to add 2 motors that control gears that move a base under the camera. You may have seen this done when your family set up the video camera to record family moments. We are doing the same thing just on top of a robot with a device called a pan and tilt head.

Lynxmotion.com has a pan and tilt head that seems to fit our design goals. The link can be found here: http://www.lynxmotion.com/p-287-lynx-b-pan-and-tilt-kit-black-anodized.aspx .

The base is only $35.93 and I think it will look decent on top of our robot.

Updated Team Assignments for Design

2010-11-12T19:33:00.004-06:00

Our team found out that some people were not getting some things done that needed to get done. Why? Because we need more collaboration on design. Ie. We need overlap in design. It turns out, that some people do not have as much experience when it comes to actually designing things. These people are strong when it comes to theory, not implementation. Being good a theory is never a bad thing, but it is good to understand how to actually assemble and put together an actual electronic system.

So we decided to break the two main submodules: car and GUI into submodules for design. These submodules include: wireless, sensors, GUI, electronic hardware, and car mechanics. Below shows the breakout on who does what in the design. Since we have five people in our team, this was a relatively easy task.

Each sub-team (my "trade-mark" term), will be responsible for insuring design is completed. This includes software as well as hardware. As for the "making a baby" part at the bottom, that's a silly amongst our team.

Wireless – Kirtan & Lahar

Tx / Rx data

Sensors – Kirtan & Mesele

Geiger Counter
Others

Camera

GUI – Cassy & Charis

Rx data

From camera and sensors

Tx data

Controller data

Calculate hazards

Based on buffer analysis of sensor data

Gather control data from PS3 controller

Usb
Serial

Link to car
Displays

Live video
Sensor data – graphs
Look at Cassy’s graphical design

Electronic Hardware – Charis & Lahar

Sensors
Cameras
Wireless
Motors
Acquiring parts and chipsets

Car Mechanics – Cassy & Mesele

Motor

Camera
Wheels

Body

Actual body
Tracks
Cut metal – home depot

Electronic Hardware and Car Mechanics MAKE A BABY

PCB design of motors, etc.

Team Fantastic's First Presentation (11-5-10)

2010-11-05T19:06:00.002-05:00

Overall, I think the presentation went extraordinarily well for not running though the entire thing together (due to conflicting schedules). Unfortunately, I had to get a video camera from the second floor lab in ENS @ UT. Because of this, I was not aware that the quality of the video would be so poor. With that said, I do apologize for the quality. I will post our slides below if someone wants to look over them.

I am so proud of the team. Everyone pulled together. I felt that we not only looked like a team, but we started to act like one. And to add to that, in my personal opinion our presentation went way better than any other team that presented that day. I think I might cry. Hahah. Just kidding.

Government Network Security Research

2010-11-05T03:06:00.004-05:00

Since our project is targeted towards military personnel, I have done some research into this area. One great resource I found was from Tumbleweed Communications (paper link here), entitled "Identity Validation for Government Wireless Networks". Obviously, this white paper was a great choice because it focuses directly on the topic I was looking for.

First of all, I have limited knowledge in network security. The best knowledge I have is from some classes that taught me a little about encryption algorithms and my own personal research on routers. Also, my personal router uses WPA-2 with AES encryption. Super fancy words, right? Well, it turns out that the government prohibits use of WEP (a common network security protocol) and requires WPA-2 security(with AES encryption) , simply because it requires Layer 4 Encryption.

Layer 4 encryption means the following--there is a different structure to the packet encryption. So first it runs though layer 1 encryption, then it runs though layer 2 , then layer 3, and then though layer 4. All data is placed in an encrypted TCP/UDP packet. The coders add 4 headers to the front of the encrypted message packet: original layer 2 header, orginal IP header, original layer 4 header, then the CE-ESP header. The message looks like the figure below (CipherOptics: http://www.cipheroptics.com/securitysolutions/layer-4-encryption.html).

Layer 4 encryption benefits include (directly from CipherOptics):

ability to pass encrypted data though Network Address Translation (NAT)
support for policy-based routing/loading balancing
lower packet overhead
Netflow/Jflow support
Infrastructure independent
Network high availability and failover transparent

Now let us go over AES. AES or Advanced Encryption Standard is a symmetrical-key encryption standard adopted by the United States government. The standard comprises of three block ciphers: AES-128, AES-192, and AES-256. Where the numbers at the end of the type of cipher indicates the bit size of the key required for encryption.

According to Wikipedia this is the high-level description of the algorithm (http://en.wikipedia.org/wiki/Advanced_Encryption_Standard):

KeyExpansion—round keys are derived from the cipher key using Rijndael's key schedule
Initial Round

AddRoundKey—each byte of the state is combined with the round key using bitwise xor

Rounds

SubBytes—a non-linear substitution step where each byte is replaced with another according to a lookup table.
ShiftRows—a transposition step where each row of the state is shifted cyclically a certain number of steps.
MixColumns—a mixing operation which operates on the columns of the state, combining the four bytes in each column.
AddRoundKey

Final Round (no MixColumns)

SubBytes
ShiftRows
AddRoundKey

So, we are most defiantly (without a doubt) going to make our network run with WEP-2 security and AES encryption. Or else, the user cannot connect at all to the robot to gather, run, or collect data.

PS. If you are interesting in looking at some code for AES--- look here (it's in C).

Hardware Overview

2010-11-04T21:13:00.007-05:00

I have yet to explain exactly what our robot is attempting to accomplish. However, a quick synopsis is at the top of my blog. Let me divulge a more in-depth discussion of this information to my readers.

The robot is intended to be used as a military-operated vehicle that employs multiple sensors to detect potential bomb threats by collecting radiological and chemical data. Hundreds of men and women die every year in combat due to un-detected bombs and chemical exposure. The Bomb-Sniffing Robot is a proposed solution to this problem. This project’s goal is to save future men and women from dying preventable deaths in combat. As a result, the robot’s design targets military customers as well as civilian bomb squads.

As a side-note, look at this compelling data on the deaths from bombs within Bagdad, Iraq. The number of deaths just keeps rising (information found from http://news.bbc.co.uk/2/shared/spl/hi/in_depth/baghdad_navigator/).

Now that I hopefully have your attention, lets go over our hardware. The figure below shows the overall hardware diagram. This figure describes the system as it pulls in data and transmits important sensor data.

The basic operation goes as follows, a user wants to see if there is a bomb or other chemical hazards in an area, but this person does not want to get blown up--so use our Bomb-Sniffing Robot. The user can use the PlayStation controller (hooked up by USB) to control the on board camera's pan/tilt/zoom and robot's direction/speed. From that a GUI sends out the controller commands (via wi-fi) to the robot. Meanwhile, the robot is collecting all sensor data (camera, gps, LPG, propane, carbon monoxide, methane, and radiation). Then the robot transmits to the GUI the sensor information at a constant rate through the wi-fi connection. The GUI allows the user to see the data in a convenient graphical and numerical format (via graphs).

I will later post an in-depth discussion on our beginning software overview between our two main submodules-- robot and GUI. There you can learn about what is going on in the background and what special features each has to offer. Note that our design is very unique, because you don't need a large amount of on-board memory on the robot, due to the constant transmission of data. Just enough to hold the data for awhile until another transmission can be made.