Carl's Blog

The current model

Current research trends are in favour of large public displays, hidden projectors, and table top displays – Microsoft’s Surface being a prominent example along with the many research projects involving public displays.

A lot of these projects have options for multiple users operating the systems, in fact some are made only for collaboration in the workplace (Highwire’s CoffeeTable, and Intel’s What Do You Bring To the Table?). However, when systems are in a public setting, the use becomes more of a public service than a means for collaboration and when the users are acting independently great efforts are made to determine identity and facilitate independent interaction and data presentation.

The classic example of this is where you walk up to a public display in a university and the display shows your time-table.

In the above scenario, what happens when a display is surrounded by more than one person – say 5 people. Does it show 5 individual timetables? If 50 people approach the display does it show 50 timetables? That is impractical, so what is a fair way to display a crowds worth of information to a waiting crowd? It could be shown one at a time, but then who gets to see theirs first, and more importantly how does one recognise your own timetable if you can’t remember it in the first place? Does your name have to appear with the time-table? Will public users be comfortable with this scenario? What authentication methods are used for systems such as these, do users need to opt in, will these questions have the same answers for different displays?

If we ignore other issues except authentication, how does the display know who you are to display the relevant information? Read a unique ID from your phone, a smart card, or some other wireless unique device? How does this deal with phones being sold, or smart cards being lost? What happens if someone of a criminal nature got hold of young student’s ID card and started stalking the student? Is there a line of how public information must be before it appears on a public display? Even if the display is not in a completely public setting, say it is behind the security check point in a company, who decides the amount of information which is displayed on a screen? The user, or the programmer in charge of the presentation software? If authentication is required before information is shown on a display, does this not ruin the workflow of the display – and would this not also stop frantic late users from approaching the system?

With privacy being a current issue within society, do not public displays get relegated to becoming glorified billboards with the only personal information they will be allowed to show will be that which could be found on the public page of a person? Will the only use of these systems be for when one has lost their phone, and the display is currently free?

Currently I believe the only use of these systems will be gained from location-based advertising – where content is changed based on the demographic of people around it and the time of day.

A different model

If we are looking into the future (a trait which many scientists are likely to do) there is another model which is what I believe public interacting displays should be tending towards.

By dissecting the mission of a public display it can be seen that it encompasses two functions.

1. Being a dedicated geographical point for a certain type of information or request,
2. Having a method to display feedback to the user.

If we look to the future and imagine a hypothetical piece of hardware exists, we can remove point 2 from the list of needed functions – and remove a lot of privacy issues.

We have this technology – albeit in a crude way – at the moment. A personal screen. Currently, this tend to be a smart phone/device of some sort. These tend to have authentication when they are switched on, via a pass code. They even support banking systems which – one would hope – worry about the security of the device in question.

The limitations of these devices are their size and resolution. A personal screen of 4 inches isn’t brilliant, so let us create a hypothetical product to facilitate this model. Imagine a pair of glasses which could project upon its lenses virtual displays at any arbitrary projection and geometry to simulate real life displays. They could even be simulated on static points in the real world, needing a user to be close to it for it to be used – as in real life. The simulated displays would be displaying what ever the public display wanted to – by virtue of its number 1 function: being a dedicated geographical point for a certain type of information or request.

Let’s go back to the 50 people in front of a timetable billboard. With their own personal screen they would be seeing just their timetable, in an almost completely private setting – while still being surrounded by 49 other people. In fact, if wireless communication density is sufficiently high, it could replace conventional screens on desks, on phones, all together. With regards to public billboards though, advertisers would be able to get what they have always wanted – a message directly to who they want it to go to.

This is of course all conjecture, but I think it should be where the domain should be heading.

CSLU did code golf today. I did 1 and a half tasks, which were:

1. Output the first 100 prime numbers
2. Output e to 100 decimal places

Prime numbers

I’m quite proud of this, I managed to do this in 55 characters initially but then after some collaboration with the rest of the club shrunk it down to 49 characters

2.upto(541){|a|i=2;i+=1 while a%i>0;p a if i==a}

e

I never got his fully working as I ended up getting caught up in list comprehensions. Ended up with:

1 + sum [1 / (product [m | m <- [1..n] ]) | n <- [1..300] ]

Which is the same as and shows how pretty Haskell is.

Previously

So I left the last article with the following:

Well apart from the hardware I need, so issues need to be addressed which may or may not require extra hardware – as I’ve just thought of them.

• DateTime equivalent object for when I register a pulse
• Work out how long these will last on battery
• Can I set an interrupt to go off when a digital value hits a threshold? Or does this require analogue input? If I can it would massively save on battery as no polling! But, it may require fiddly per-house calibration, which the brute force method ignores
• Laser/3d Printed box and some form of mounting which will let me attach to anything. Probably going to be velcro

So I’ll go through what has been done since then via this criterea.

Hardware Changes

The DateTime object style thing was achieved through an RTC module (http://www.sparkfun.com/products/99) which communicated to the ‘duino using the I2C bus and takes 5V. A microSD card shield was also added to the hardware for saving events into a simple text file (http://www.sparkfun.com/products/9802).

Rather than use my hastily build photosensor, I used a load of RFXcom sensors as they are well built and have a housing designed for sticking to the meter (Which is by far the biggest engineering challenge of this project). A board layout for interfacing with the sensor units was created and the gEDA/gSchem schematic file can be found on the git hub project page.

Software Changes

Well, apart from the stuff which interfaces with the RTC module and the microSD card, not much has changed code wise. The way the RFXcom modules work was backwards to my prototype, so I measured the time it takes to discharge a capacitor rather than charge. An LED on a meter normally flashes for .1s, so the timout is set to 0.05s.

Battery Life

Using a multimeter showed the whole sensor drew 92mA. It isn’t ideal, but with a 6 AA battery pack which packs ~3000mAH which lasts a bout a day ( ) However,  that was with a ridiculously high powered infrared LED on the RFXcom board. Using just the photosensor (rather than the reflective) the power output was 42mA and that was with the SD card always powered. There is a lot of scope for battery life improvement on this project.

Source

The source can be found on my github page at https://github.com/carl-ellis/Arduino-Gas-Sensor .

For the second term of the 2011/2012 academic year I’ve made a small challenge for members of CSLU.

Details are found on the PDF.

Good luck.

P.S a bit of background reading can be found here.

PDF: CSLU Lent Challenge

Motivation

My newly ordered Arduino Uno came in the post today so I got to start building with it!

An upcoming sensing deployment needs a way of sensing gas usage, so I’m building a basic sensor to measure it. Luckily, most gas meters have an LED pulse which goes off every so often and we can measure that. The one in my house informs me the light will pulse every 10 dm^3 of gas, so every time the second number from the right on the meter ticks the light will pulse. Failing this, the 0 on the right most dial is very reflective, and an LED can be used to reflect light from it.

As the extra bits I need to finish the sensor hasn’t come yet, namely the SD card shield and a battery pack, I can’t lock the sensor in my gas cupboard and give it a test, so for the time being I’m turning off my computer screens and lights, then flashing a red head torch at it to simulate a pulse.

Code

After a bit of internet trawling, I found an ace site laying down how to do the wiring for a digital light sensor (http://www.ladyada.net/learn/sensors/cds.html#bonus_reading_photocells_without_analog_pins). From that, I added in a method which took a rolling average of the last 5 measurements and outputted if the measured light was brighter than 110% of the average (not exactly statistical, but I intend for these to be locked in a dark box…).

Here’s what I have so far:

/* Based on: Photocell simple testing sketch. 
Connect one end of photocell to power, the other end to pin 2.
Then connect one end of a 0.1uF capacitor from pin 2 to ground 
For more information see www.ladyada.net/learn/sensors/cds.html */

// Number of measurements for averaging
const int AVERAGE_LENGTH = 5;

int photocellPin = 2;     // the LDR and cap are connected to pin2
int photocellReading;     // the digital reading
int ledPin = 13;    // you can just use the 'built in' LED

// for the circular buffer
int lastReadings[AVERAGE_LENGTH];
int average = 0;
int counter = 0;

void setup(void) {
  // We'll send debugging information via the Serial monitor
  Serial.begin(9600);

  // Initialise the array 
  for(int i=0;i<AVERAGE_LENGTH;i++) {
    lastReadings[i] = 0;
  }   
}

void loop(void) {
  // read the resistor using the RCtime technique
  photocellReading = RCtime(photocellPin);

  // Calculate rolling average
  ++counter %= AVERAGE_LENGTH;
  lastReadings[counter] = photocellReading;
  calcStats();
  int bound = average - (average/10);

  // Glorious debug
  Serial.print("Av = ");
  Serial.print(average);
  Serial.print(" = [");
  for(int i=0; i<AVERAGE_LENGTH;i++) {
    Serial.print(lastReadings[i]);
    Serial.print(",");
  }
  Serial.print("] ");
  if (photocellReading < bound) {
    Serial.print(" . RCtime reading = ");
    Serial.println(photocellReading);     // the raw analog reading
  } else {
    Serial.println();
  }

  delay(100);
}

// Calculates the new mean based on the last 20 measurements 
int calcStats() {

  // average
  average = 0;
  for(int i=0;i<AVERAGE_LENGTH;i++) {
    average += lastReadings[i];
  }
  average /= AVERAGE_LENGTH;
}

// Uses a digital pin to measure a resistor (like an FSR or photocell!)
// We do this by having the resistor feed current into a capacitor and
// counting how long it takes to get to Vcc/2 (for most arduinos, thats 2.5V)
int RCtime(int RCpin) {
  int reading = 0;  // start with 0

  // set the pin to an output and pull to LOW (ground)
  pinMode(RCpin, OUTPUT);
  digitalWrite(RCpin, LOW);

  // Now set the pin to an input and...
  pinMode(RCpin, INPUT);
  while (digitalRead(RCpin) == LOW) { // count how long it takes to rise up to HIGH
    reading++;      // increment to keep track of time 

    if (reading == 30000) {
      // if we got this far, the resistance is so high
      // its likely that nothing is connected! 
      break;           // leave the loop
    }
  }
  // OK either we maxed out at 30000 or hopefully got a reading, return the count

  return reading;
}

Next Steps

Well apart from the hardware I need, so issues need to be addressed which may or may not require extra hardware – as I’ve just thought of them.

• DateTime equivalent object for when I register a pulse
• Work out how long these will last on battery
• Can I set an interrupt to go off when a digital value hits a threshold? Or does this require analogue input? If I can it would massively save on battery as no polling! But, it may require fiddly per-house calibration, which the brute force method ignores
• Laser/3d Printed box and some form of mounting which will let me attach to anything. Probably going to be velcro.

Here’s a video of it working:

So I ran a talk on learning programming languages last week. It was the second time I had done that particular talk, and in this case the hardware setup went smoothly – as it was done by Stephen Wattam the CSLU VP.

We had a pretty good turn out, mostly of year year undergraduate students who so far had only played with a little C. I took pictures of everyone hard at work doing their task … well, ok. They were mostly on tryruby.org which was even better.

It showed that they had an interest in a new language which is fairly good at prototyping and will allow them to try out their ideas fast. I may have semi pushed them on to it in my talk, so I’m glad they were listening. No one tried learning Haskell though, but then I’ll drop in on everyone next term and see how they are doing. The slides and some info for my talk can be found  at the CSLU site.

On a side note … My Instagram tshirt came! I’m not sure if I’ll ever wear it outside as it’s a bit long, but still!

So I’ve spent the last 4 weeks in Cambridge working as an intern at Microsoft Research and I thought I’d share my observations on the differences between academia and corporate research.

Academia, I find, is far from the ivory tower that it once was. Forgetting the worrying need to find economic benefit for projects, most research is now being spun as a product.

Surely the last thing you want for a product is a buggy bloated research prototype, and surely the last thing you want for a research project is a polished product. I mean you want it for one thing, to prove a hypothesis for your thesis.

This of course, is a massive generalisation, and more applied to the recent batch of Ph.Ds coming through, especially as they come through doctoral training schemes which mesh (mostly unsuccessfully) different fields together. Still, scoring a blue-skies research project without lying through your teeth in the impact section of a proposal is like finding real ale in Essex.

Of course, there is the positive side of academia too. The freedom to tackle your problem via any means. Flexible working hours (unless you are an RA), flexible supervision, flexible scope. You can produce a highly polished massively overworked Ph.D, or the bare minimum which gets the job done. It is a very personal thing. Research projects are a bit more managed, you have a more rigid supervisory system, project meetings, but your section of stuff is pretty much yours to do as you will.

This environment breeds two types of people: the successful ones who generally ask for and give help to their peers, accept criticism with grace, and who thrive in a space where they make the rules; and the other ones who, having seen the gaping ravine of work in front of them, bottle it and fail. Maybe not straight away nor suddenly, as it could creep up after a year or two, but Ph.Ds have been known to just disappear into industry after 4 years, with not a word to anyone. It is very easy to lose sight of where you are aiming to get to, reaching a false summit of your thesis and calling it done.

Academia is very much a dog eat dog world. The UK has a much nicer tenure-free environment, but even the tenant of the American “publish or perish” culture still exists. Academics live off their reputation, and their reputation is written in the black ink of a bibliography.

Corporate research is exactly the same landscape but with a few key differences.

For a start, the “build a prototype” message is very clear, especially for systems which may one day be products. You are building and evaluating a proof of concept, as it should be.

Secondly, the atmosphere is completely different. Whereas in the academic environment it is almost taboo to ask on a struggling Ph.D how their work is going, in corporate research struggling researchers are actively propped up and discussions at lunch and the pub are refreshingly problem orientated.

Thirdly, your supervisor is your manager. Which from a managerial point of view is awesome, you have someone who is your boss and *knows* what they are talking about, whilst still being your supervisor and knowing all the issues that come from research and how best to stimulate ideas out of dead ends. From an intern perspective this is also good, as seeing your supervisor as your boss makes you want to impress them more, and meet deadlines days earlier.

Finally, the pay is miles better.

Those are the good bits, and of course, there are some bad bits too.

Corporate research labs tend to have a “eat your own dog food” policy, which means that if the company creates a tool that can do you job, you use it, unless you can find a valid research reason not to. Working at Microsoft and being a Linux user, you can see how this has led to initial slow productivity as I’ve readjusted to an alien tool-chain.

There are also some scary law type things which get attached to the job, such as losing a kidney if I speak of what I see on whiteboards and such. However, this style of development is slowly losing ground as projects like Gadgeteer are being released under an Apache licence.

As a final point, having worked in some small companies where you have the “family” feel, I still find that you get this here. It may be due to the organisation of the research lab, but everyone is very friendly and you associate with your research group quite strongly. But not in a “compete against other group” way, as everyone in the building is amazingly friendly.

So far I’m enjoying it, we’ll see if I still do in 8 weeks time

C

Well, this is getting rather fun, but quite time consuming.

My alarm clock is ticking away and my sleep time dwindling as I type, but I just don;t feel the urge to sleep yet. I’ve got a talk/demo I’m preparing for Wednesday for CSLU and it is getting bigger and bigger workload wise.

I’m hoping this translates to geeky hacky fun though.

The talk is on languages and paradigms, so I’m introducing a load of languages (8 I think, off the top of my head), describing the basic constructs, and then getting the room to build a “99 bottles” program using 3 of the given languages.

The fun, but time consuming, part of this is that I’m building cheat sheets for each language. Done the first one tonight, and it was for C, so quite detailed. Hoping I can cut/paste a lot of stuff for similar languages, and hoping I don’t have to fall back to a stock one. It is nice to make a custom one for the group, and also cements my own knowledge, especially of the languages I am unfamiliar with.

After the 99 bottles task, I am going to set some slightly longer challenges which can be made easier using certain paradigms. I have an OO one, which can be done procedurally. It’s based around a game scenario. For procedural I will probably do a processing batch type thing. For functional I need to do a little more research.

With the department allowing me to set up a load of VMs for everyone to use too, this should be pretty fun on Wednesday … so long as I get it all finished in time!

September time is conference time it seems and I am currently at UbiComp2010. The UCSE2010 workshop convened yesterday which was very successful and discussion driven.

One of the main technical company sponsor was in the workshop, Autodesk, and gave an interesting talk on how they are opening their whole building’s Building Information Model(BIM) to the internet. I would point you to Digital 210 King for more information.

2 weeks ago I was at IPIN, which was hosted for the first time at ETH Zurick. Very successful conference, with lots of content (200+ talks!).

For all those interested, I am putting my slides on slideshare, those being my IPIN talk (30 min ish) and my UCSE talk (5 min). The UCSE presentation has had a slide removed for confidentiality reasons, so the short presentation is even shorter.

Please navigate to http://www.slideshare.net/CarlEllis to view.

C

So I wanted to make a basic makefile for my tex documents, so I took the Makefile from http://www.acoustics.hut.fi/u/mairas/UltimateLatexMakefile/ and modified it to be amazingly simple.

Heres the Make file:

CC=
FLAGS=

LATEX= latex
BIBTEX= bibtex
DVIPS= dvips
PS2PDF= ps2pdf

SRC := $(shell egrep -l '^[^%]*\\begin\{document\}' *.tex | sed -e 's/.tex//')TRG = $(SRC).dviPSF = $(SRC).ps

all : pdf

dvi :  $(LATEX) $(SRC) && $(BIBTEX) $(SRC) && $(LATEX) $(SRC) && $(LATEX) $(SRC)

ps : dvi  $(DVIPS) $(TRG)

pdf : ps  $(PS2PDF) $(PSF)

clean :  rm *.bbl *.aux *.blg *.dvi *.log *pdf *.ps

Fairly simple and lets you choose your toolchain.

C