a b 
Thomas, I am looking forward to supervising your CS 194 honors project in the area of wireless sensing, and acoustic localization in particular.

Prof. Deborah Estrin
Jon Postel Chair in Computer Networks
Computer Science Department, UCLA
Director, Center for Embedded Networked Sensing (CENS)
3531H Boelter Hall
Los Angeles, CA 90095
http://cens.ucla.edu/Estrin
Fax: 3102063053Hi Professor,

This is a progress report for what I've been doing.  Since this is the
first one, a brief introduction for these are in order.  I'll be doing
this weekly, and there are two required parts, the "what I've been doing
the last week" and "one idea I thought of" parts.  I'll add more stuff on
top of those two if need be.

I should also mention my wiki page, if I haven't already.  It's got all
the pertinent info for the project, my To Do list, thoughts/ideas, etc. I
updated it yesterday and today, and I will definitely keep it as up to
date as possible.  So if you got a spare moment, take a look at it if you
can.
http://www.lecs.cs.ucla.edu/wiki/index.php/Tingyu_Thomas_Lin

So, on with the progress report.

"What I've been doing"
I've been reading several papers.  Two of them are the ones that Girod
sent me on acoustic localization and the ENSBox.  The other two are ones
Mike pointed me to, one dealing with Emstar and the other StateSync.  As
for stuff done besides reading, I installed linux and Emstar onto my
desktop so I can fiddle with Emstar later.  Other short term goals are:
figure out TinyOS and have the ENSBoxes locate a single mote.

"An Idea I though of"
The idea deals with the issue of how the motes fit into the ensbox
network.  The idea is to have the motes connect to any box that it can. 
If it's true that the only requirement is that the motes can talk to the
ensbox network (this might not be the case), then the only issue is to
have the motes be attached to anywhere in the network, and any box the
radio can reach will do.  I talk about it more on my wiki, under "2.3
Issues" at the "other thoughts" sub-section.

Well, that's about it for this progress report.  Any questions or
comments, feel free to throw at me.  Until later,

- Thomas
Week: 2/5-2/11

Amidst other school work, I didn't get much done this week.  What little
time was spent on the project was split between reading up on TinyOS and
boxing with ubuntu so I could play with Emstar and TinyOS.  Nothing
exactly involved with the mote localization problem, so I don't have any
new ideas nor made any headway.

Hopefully I'll have more to say for next week's progress update.

- Thomas

Project Wiki Page:
http://www.lecs.cs.ucla.edu/wiki/index.php/Tingyu_Thomas_Lin

Hi Professor,

This is my project's weekly update report for week 2/12-2/18.  This last
week I spent time reading old CS113 course material, mostly to learn how
to pogram motes w/ nesC.  At Mike's suggestion, I also got linux installed
on my laptop so I can work w/ the motes and ensboxes.

The current idea I'm working off of is having the ensboxes coordinate the
motes' ranging signal.  I'll only be working with a single  mote for now
(and assuming no obstructions), and I'll add more motes to the mix as I
progress.

- Thomas

Week 2/19-2/25, progress update

I went into the CENS building and got a chance to work with the Mica2
motes.  I'm currently working on having the ENSboxes tell the motes when
to emit the ranging signal and from that determine the position of the
motes.

- Thomas
Hi Professor,

This is the progress report for 2/26 to 3/4.

Over the last week I’ve been programming the Mica2 motes.  As with last
week, I’m working towards having a "master mote" that tells the motes when
to emit their ranging signals.  I did some of the tutorials for
TinyOS/NesC, so I’m pretty much set to implement the NesC stuff the next
time I work with them.

The next step (idea) is to make a program that runs on Emstar that will
act as the master mote.  The program will be the one that tells the
ENSBoxes to start recording sound and then tell the motes to emit the
ranging signal.

Well, that’s it for this progress report.  Until next time,

- Thomas

My wiki page:
http://lecs.cs.ucla.edu/wiki/index.php/Tingyu_Thomas_Lin

Hi Professor,

This is the progress update for week 3/5 to 3/11.

I grossly overestimated my abilities to make simple programs in nesC, and
got bogged down implementing basic mote radio communication.  What I
finally got at the end of this week was a decent understanding of how to
send messages, and a working base station and a mote communicating
properly.  This really is a rather trivial task, but a handful of bugs
took all my time this week, and also as a result I don't have any new
ideas to mention.

Truth be told, the level of progress I've made so far I should have had
done a month ago.

At any rate, this up coming week I'll finally be trying to get my laptop
w/ emstar on it to act as the base station.  I also got two days of down
time during finals week to make up on lost progress.

- Thomas

My project wiki page:
http://lecs.cs.ucla.edu/wiki/index.php/Tingyu_Thomas_Lin

Hi Professor,

I didn't get a reply for an email I sent to you a few days ago, and I
don't know if you received it.  But basically, I was asking if it is
possible for me to meet with you sometime soon, so that I can make sure
that the direction I'm heading with my project is okay.  It shouldn't take
up much of your time.

What I've been working on is trying to see if ensboxes and motes, with the
sensorboard's sounder and microphone, will improve the accuracy of
estimating the location of the ensboxes.  So the ensboxes have roughly an
average of 5cm 2D positional error and 1.5 degree orientation error.  The
idea is to add on top of that motes that can determine distances to other
motes/ensboxes using the (overly)simple method of time difference of
arrival between a radio packet and a audible chirp detection.

So what I am doing right now is simulating this in matlab.  I generate the
positions of ensboxes and motes (done both arranged randomly and in a grid
pattern), as well as the information that the system has: estimated enbox
positions/orientation, estimated distances between motes&ensboxes (for now
I assume the TDOA method that the motes use give the distances for all
pairs of nodes, and I will drop this assumption since the chirps motes
produce realistically will only reach motes that are relatively close),
and the realistic errors in these estimates (ensbox errors in measurements
are known, and for the motes I take numbers from the paper "acoustic
ranging in resource-constrained sensor networks").  And then from all
this, I'm trying to find a system of constraints that can (theoretically)
get more accurate positions for the ensboxes.

So is this a good direction for me to go in?  My progress has been very
lousy for the last quarter, so any feedback from you about how I'm
spending the time I have remaining is much appreciated.

Thanks,

- Thomas

Hi mike,

Sorry for the late notification.  I'm meeting with prof. estrin tomorrow
(thursday) at 4pm.  It'd be great if you could make it.

And here's what I've been doing.  Cut and paste job from the progress
update I just sent to the prof:

So basically, what I've been doing the past couple weeks was running
simulations in matlab, seeing if I could use motes and ensboxes together
to improve the ensbox's estimates on their own locations and orientations,
as well as the locations of motes.  This is done using simulated data and
errors that are taken from various papers that describe them.

And so what I have planned now is for motes to be scattered around the
ensboxes (the calculations involve having around an ensbox at least 3
motes such that the three motes form three points of a triangle that the
ensbox is enclosed by) and have the motes find the distances between
themselves and other motes using audible chirps (presumably this will be
accomplished via TDOA between radio packets and the chirp).  The audible
chirps also allows the ensboxes to find the angle that the motes are at.
I got a bit of math going that when performed on this data set, I get the
locations of motes and ensboxes as well as the orientation of the
ensboxes.  As for accuracy of results, I believe I can obtain a more
accurate estimate of the orientation of the ensboxes (perhaps ~.8 degrees
error average in 2D), but the location of motes and boxes are a lot worse
and get worse as distances between motes and boxes increases.

- Thomas
I'm actually currently working on the paper for my project.  The rough
draft (which will have crazy holes all over the place, especially in the
area of experiments, results and conclusion) should be done today or
tomorrow.

Besides that, I got doa simulation going.  What I have is a function that
takes a sound frequency and a direction of arrival, and what the function
spits out is the likelihood vector.  Inside it does the offsetting of
sound waves and what not at each of the 4 mics.  The geometry of the array
is adjustable, as well as some other parameters.

speaking of which, I couldn't remember what the size of the arrays that
the ensboxes. what I remember is that the actual boxes have 12cm arrays,
and the acoustic laptops with the wired mic arrays are 8cm arrays. Is this
correct?

Well, that's about all I have.  I'll send you a copy of my rough draft of
the paper when I finish it.

- Thomas
thanks for providing feedback; it's been really helpful.  I've revised the
paper based on them, as well as added in the conclusion.  A few things I
didn't do though:

> Need to be clearer in the introduction about self-calibration, why its
> important to acoustic source localization - maybe a diagram.

I don't talk about self-calibration much at all in the introduction.  Is
that problem?  Also, I'm not sure on what diagram would help illustrate
self-calibration.

>
> Maybe expand a little more on the 'in theory it can work in 3d'

I agree that I really should at least include a paragraph or so about
this, but due to lack of time (well, sleep at this point) I'm skipping
this.


- Thomas


> Hi Thomas, some comments are below, roughly in reading order. Send me the
> conclusion when you have it, and your other changes, etc.
>
> Hopefully the comments should make sense, but mail me if they don't
>
> MIke
>
> ----
>
> Is the title indicative of the work that you've done? I don't really see
> much information about design.
>
> Maybe 'investigating source localization
>
> Need to be clearer in the introduction about self-calibration, why its
> important to acoustic source localization - maybe a diagram.
>
> Maybe expand a little more on the 'in theory it can work in 3d'
>
> I can't see where you say why three nodes minimum are needed..
>
> Wireless communication is essential to a wireless distributed sensing
> network, but not a wired one.
>
> For the issue of reliable transport - if you make a claim like that (work
> in
> the field), back it up with a reference or two (you must have read some
> papers to know that there was work in the field).
>
> Actually software hasn't been implemented yet for the ensbox mote to
> communicate with a mica2 network, but it's effectively there (I have to do
> some modifications to the software).
>
> The thing about RBS being chatty 'quite a few message exchanges' - you
> should quantify, rather than say quite a few, or at least reference where
> that is said in the RBS paper.
>
> FTSP is not Elson et al.. :-)
>
> You don't really talk about how the scheduling might be done - would it be
> controlled by the root of the time sync? what happens over multiple hops?
> Is
> there some simple psuedo-code you could write to show a potential
> scheduling
> algorithm?
>
> did your lobe experimentation of the mote's narrow band signal indicate a
> 'sweet spot' of an ideal frequency that you would have the motes chirp at
> to
> be better localized?
>
> In the experimentation, it might be nice to see the estimated positions
> (or
> avg estimated postions overlayed on that map you have) - this might be
> more
> informative than tables?
>
> Comment on the placement of the motes and ensboxes more - you randomly,
> but
> _uniformly_ placed the motes - correct? YOu don't talk about why you
> placed
> the ensboxes in the position you did - was it random, or what constraints
> did you use, and WHY?
>
> You also don't talk about how you perform self calibration in simulation -
> is this just a case of choosing positions and orientations and then
> applyingn noise, based on empirical measures? If so, then say that!
>
> You don't really say anything about the geometry of the ENSBoxes - is this
> because you assume that a deployer will arrange them in a 'good' way? You
> will need to comment on the arrangement of the boxes to explain your
> results
> - your simulation work shows that given this particular configuration
> you've
> chosen, and the specific conditions you've chosen, the performance is
> good,
> but that's not necessarily the same in every configuration case.
>
> It's not a good idea to make a general statement like:
>
> 'This suggests that adding more ENSBoxes beyond 5 does not improve mote
> localization'
>
> For the exact reason that I gave above - in your simulation this is true.
> It's more accurate to say that within the area you defined, the number and
> positions of the motes and the positions of the ensboxes, adding more does
> not improve localization (not those exact words, however). You have a few
> of
> these kinds of statements, and the simulation work you've done does not
> put
> you in a position to make general statements - so be specific, and then
> talk
> about how much experimentation you'd have to do in your conclusion.
>
> Be consistent with the naming of arrays and sub-arrays. In acoustic source
> localization terms, the array is whole set of microphones (i.e. all of the
> nodes' mics) and a sub-array is the mics on a particular node.
>
> On 6/6/07, Tingyu Thomas Lin <tingyul@seas.ucla.edu> wrote:
>>
>> Hi,
>>
>> Here's my revised paper.  It's missing the conclusion, but the rest of
>> it
>> has been smoothed down a lot.  I'll add the conclusion tomorrow (well,
>> later today) and email you that.
>>
>> - Thomas
>>
>