Software Developer in San Francisco Bay Area

Menu

Category Archives: project

Triangulation offers a way to locate yourself in space. Cartographers in the 1600s originally used the technique to measure things like the height of the cliff, which would be too impractical to measure directly. Later, triangulation evolved into an early navigation system when Dutch mathematician Willebrord Snell discovered three points can be used to locate a point on a map.

While triangulation uses angles to locate points, trilateration uses lateral distances. If we know the positions of three points P1, P2, and P3, as well as our distance from each of the points, r1, r2, and r3; we can look at the overlapping circles formed to estimate where we are relative to the three points. We can even extend the technique to 3D, finding the intersecting region of spheres surrounding the points.

In this project, I’d like to show how we can use the Wifi signal strength, in dB, to approximate distance from a wireless access point (AP) or router. Once we have this distance, we can create a circle surrounding an AP to show possible locations we might occupy. In the next part of the project, I plan to show how we can use three APs to estimate our position in a plane using concepts of trilateration. (Note: I haven’t had time to implement this, but you can use this Wiki article to implement it yourself).

Trilateration using 3 access points providing a very precise position (a) and a rougher estimate (b)

Determining distance from decibel level

There’s a useful concept in physics that lets us mathematically relate the signal level in dB to a real-world distance. Free-space path loss (FSPL) characterizes how the wireless signal degrades over distance (following an inverse square law):

The constant there, 92.45, varies depending on the units you’re using for other measurements (right now it’s using GHz for frequency and km for distance). For my application I used the recommended constant -27.55, which treats frequency in MHz and distance in meters (m). We can re-arrange the equation to solve for d, in Java:

FSPL explicitly requires “free space” for calculation, while most Wifi signals are obstructed by walls and other materials.

Ideally, we will want to sample the signal strength many times (10+) to account for varying interference.

Problem (1) will be resolved in the future by using the signal-to-noise ratio to more accurately estimate (that sounds like an oxymoron) obstructions to the wifi signal. Problem (2) can be implemented in code by sampling many times and computing the average signal level.

Using the above code along with Android’s WifiManager and ScanResult classes, I can print out our final measurements:

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

WifiManager wifi=(WifiManager)getSystemService(Context.WIFI_SERVICE);

registerReceiver(newBroadcastReceiver()

{

@Override

publicvoidonReceive(Contextc,Intent intent)

{

results=wifi.getScanResults();

for(ScanResults:results){

DecimalFormat df=newDecimalFormat("#.##");

Log.d(TAG,s.BSSID+": "+s.level+", d: "+

df.format(calculateDistance((double)s.level,s.frequency))+"m");

}

}

},newIntentFilter(WifiManager.SCAN_RESULTS_AVAILABLE_ACTION));

wifi.startScan();

And we can get back data that appears to be correct when moving further away from my test router (MAC address: 84:1b:5e:2c:76:f2):

[Image lost during host transition, but basically just showed how the distance increased]

Everyone knows a compass always points north, and most people know it’s because of magnetic fields present on Earth’s surface. There’s another force here on Earth directed to a central point, and that’s gravity. Humans are quite adept at sensing gravity thanks to equilibrioception, where fluid contained in structures in our inner ear provide feedback to help us stay balanced.

But machines, too, can detect gravity thanks to the simple accelerometer. Already present in most smartphones today, accelerometers react to gravity with tiny springs, creating a voltage difference that we can measure and turn into meaningful units.

Using accelerometers to emulate human’s perception of gravity

I’d like to show how we can use an Android phone (even my dusty old Droid Eris) to visualize the force of gravity. To save time, we’re only going to use two dimensions, x and y, but the technique used here can easily be extended into 3D.

Let’s represent gravity the same way students in a high school physics class would — with an arrow pointing down. The goal would be the ability to rotate the phone (changing the x and y position), while still having that arrow point down, illustrating the direction of gravity.

The first thing we’ll need to do is convert the rectangular coordinates given to us (x and y) to a polar system (r, θ), where extracting an angle is much easier.

Thinking back to high school geometry, the inverse tangent will provide that angle directly. Java has a built-in method, atan2(), which even gracefully handles the divide-by-zero case when x = 0. Because the image rotation I’m using is based on degrees (more on that in a moment), we can convert the radian angle to a common degree (0-360°).

1

2

doubletheta=Math.atan2(y,x);

doubledegree=((theta *-180.0)/3.14159)+180;// +180 to keep 0 on the right

That gives us the degree rotation of the phone in 2D. We’re almost there. To determine the degree that we would like the gravity arrow to point, we need to offset that degree, modulo 360 to keep us within the range (0-360°):

1

floatrotateDegree=(float)((degree+270.0)%360.0);

Now it’s just a matter of re-drawing the arrow image on the screen. Android offers some fancy animation techniques, but for this quickie project, I chose to use a matrix rotation:

With that code in place, we can finally visualize the force of gravity, at least in two dimensions:

This project was a quick one (writing this blog entry actually took longer than the code itself), but I think it’s important to show how we can figuratively “teach” a device a human trait and give them a new skill. For instance, with a faster refresh rate and perhaps a little more accuracy, a robot can use this technique to keep itself balanced, much like humans use information from gravitational forces to stay balanced.

This is a collection of projects I created for CS 530: Introduction to Computer Visualization. Each project required an HTML writeup, so I figured it would be easiest to keep a collection of links here…

Project 1: First Steps with VTK

To get acquainted with the Visualization Toolkit (VTK), we used bathymetry (sea depth) and topography information from NASA to visualize the earth in a few different ways. We also implemented a Sea Rise simulation that shows how land masses on Earth change as the sea level rises.

Project 2: Color Mapping

This project focused on choosing the right color maps to visualize different types of data. The two types of data we looked at were MRI scans and a topographical map of the western U.S. With these data sets, we were tasked with creating appropriate color maps in both continuous and discrete styles.

Project 3: Isosurfaces

Isosurfacing allows the medical industry to convert 2-dimensional slices, such as the CT slices used in this project, to 3-dimensional surface in space. This project explored different techniques of building isosurfaces and mapping colors to them.

Project 4: Direct Volume Rendering

Although isosurfacing can generate a surface in 3D, the medical industry often uses raycast volume rendering instead because it better reflects the ambiguity and imprecision of the measurement. Rather than creating a geometry from data, volume rendering uses rays emitted from the object, adding opacity and color along the way. This project dealt with two data sets, the CT scan from the previous project, and vorticity surrounding a delta wing on an aircraft.

Project 4 Bonus: Multidimensional Transfer Function

Project 5: Vector Field/Flow Visualization

This final project explored vector field visualization of velocity data surrounding a delta wing dataset. I visualize the vector field in different ways: plane slices showing the velocity data with arrow glyphs, streamlines, stream tubes, and a stream surface. Finally, I present the streamlines with the isosurface that makes up the magnitude of the vortices for reference.

For our final project for CS 59000: Embedded Systems, a partner and I implemented several tests on a small-scale wind turbine using the Texas Instruments MSP430 board. We use the Analog to Digital Converter (ADC) to gather information on voltage generated by the turbine and rotations per minute calculated with the help of an optical tachometer. We then send these values to a Java-based user interface to report in real-time on an attached computer.

For the final part of our project, we designed a wind turbine stand on springs that we can use, along with the MSP430, to measure accelerometer data from the wind turbine under stress. We also send the real-time data to the user interface on an attached computer.

Tip-Speed Ratio

This part of the project required the use of the optical tachometer connected to the MSP430 board. The tachometer will output a high value when no blade blocks the beam, and a low value (close to zero) when a blade is in front. We read this information and convert the rate at which blades are passing in the beam to compute a rotations per minute (RPM) value.

The average RPM we measured at a given time was: 55 RPM

We measured the radius of a blade, and found R = 20.7 cm or 0.207 meters.

At LOW fan speed, the velocity of wind was recorded as V = 2.101 m/sec * 60 s= 126.06 m/min.

Using these values, we found the Tip-Speed Ratio to be:
λ = .567 rotations

Accelerometer Data

We constructed a special stand for the wind turbine that allows the turbine and MSP board to move in unison, while still being flexible to allow natural movement due to the wind.

For this part of the project, we modified the provided Java program to also display accelerometer data in the X- and Y-axes. We track and record this data in real-time, which gives some insight into how the wind turbine is moving as the speed and direction of wind changes.

Although we are not able to give a unit for these values, the magnitude of change can indicate what is happening in the physical system. For instance, when we see X values change from near-zero to negative, we know that stress is being placed in the wind turbine in the negative X direction (see diagram below — blue values represent negative readings).

Winter break means plenty of time to toy around with something new. I’m not sure what inspired this project, perhaps the ethernet driver we designed for our Operating Systems course, but I’ve decided to explore the field of embedded networking. And you can’t get much more embedded than a 16 MHz Arduino Uno with 32K of memory.

Goals

I want to create an Arduino-based web server, but with a few twists, because the idea already exists and has been implemented. The first link points to Lady Ada’s quick and dirty Arduino file server, which can serve up character-based files stored on micro SD. The second link offers a more functional server called Webduino, which claims to offer image support (ie. binary transfers). However, reading through the code, it looks like the developer took the easy way out by re-encoding a PNG as hex values, and then sending those values byte-by-byte over the network. That’s not image support! Also, both implementations seem to suffer from the limitation that only one client can connect at a time.

Because the Arduino has no formal notion of threads, it would make sense that multiple clients just won’t work. But I’ve been reading up on a project called Protothreads, which adds the most basic threading you can imagine. No separate stacks. No pre-emptive scheduling. Just a way to give the appearance that two computations are concurrent. I’m hoping that I can use protothreading to allow multiple clients to connect.

Additionally, it would be nice to find a way to do binary transfers. Glancing at the EthernetClient and EthernetServer API, it looks like they’re both set up for byte transfers. I wonder if there’s a way I can trick it into sending binary information. We’ll see.

Update – 26 January 2012:

I found an easy way (untested) to get the Arduino to send non-text content over the EthernetClient interface. When a client requests a file of a certain type, say, PNG, you can send a response indicating that you will be sending PNG binary data byte by byte as follows:

1

2

client.println("HTTP/1.1 200 OK");

client.println("Content-Type: image/png");

I hope to test this technique soon. Admittedly, I still have a long way to go on this project, but other projects (iPhone app, stay tuned) keep arising.