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

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

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?

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:

1. Should we really use a servo motor or a stepper motor?
2. How do you operate a servo motor?
3. What servos are you looking into? 
4. What GPS module should we use? 
5. 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

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
• LPG
• GPS
• 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

• PCB
• 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)

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

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):

1. KeyExpansion—round keys are derived from the cipher key using Rijndael's key schedule
2. Initial Round
1. AddRoundKey—each byte of the state is combined with the round key using bitwise xor
3. Rounds
1. SubBytes—a non-linear substitution step where each byte is replaced with another according to a lookup table.
2. ShiftRows—a transposition step where each row of the state is shifted cyclically a certain number of steps.
3. MixColumns—a mixing operation which operates on the columns of the state, combining the four bytes in each column.
4. AddRoundKey
4. Final Round (no MixColumns)
1. SubBytes
2. ShiftRows
3. 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

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.