Moving off Blogger..

This is my last post on this blog. Blogger and Google have been a bit of a disappointment, so this seems like a good time to wrap up and find an alternative.

What I want in a blog service:

• bug-free editor - I don't actually need WYSIWYG if it's that hard to do; HTML would be fine
• reliable server to save mid-edit to, and which doesn't push down the whole page - that I'm in the middle of editing - with a message telling me that once again it failed to auto-save
• a preview with links that work, so I can test them there

What I want from Google's search services:

• if they run a service like Blogger, they should put the pages from it in their index, preferably when they're published
• for "site:object-network.blogspot.co.uk" to work

I'm also looking for alternatives to Feedly, the feed reader that pulls in new pages in less than a second, but then stubbornly refuses to acknowledge updates from then on.

You don't know what you do want, until you know what you don't want. I now know more about what I want. So thanks, Google, for that!

And for giving me a free blog, which wasn't so bad, really.

Concluding my 60 Days of Things

I'm now nearly at the end of my 60 Days of Things. As I said when I was half-way: "I started this blog on the 14th of December last year, without intending to blog every day. But I happened to have something to say every day, and once I'd established that regularity, I decided to keep it up. I do have rather a lot to say about the Object Net, and my other blog is full of me saying it in long posts. This way I get to write shorter posts, yet more often."

It's been a lot of fun, doing the coding and hardware stuff and writing these posts. I almost never knew what I was going to write as I sat down every evening, but never once failed to find inspiration.

So here's another summary in two parts. First, what I achieved for NetMash:

• showed screenshots of my basic jumping-around AR view
• added "azimuth" - or panning - to the AR view
• thought about the more gentle AR positioning algorithm
• made a video of my smooth AR IoT demo
• discussed some improvements and enhancements I need to do next
• had some thoughts about the ways I'd use the Pi camera
• met a bunch of fellow geeks to talk about Pies

Rather more articles in the "general" category this time:

• gave my thoughts on the Nest and Google situation
• showed how I used Google Trends
• listed interesting conferences and meetups
• had some thoughts on the economics of LED bulbs
• listed the interesting IoT protocols
• pondered the ever-present security issues of the IoT, and some solutions
• gave my vision of a seamless 3D world built like Minecraft
• compared massive grids of Things to massively parallel computers
• projected forwards into the 3D IoT with 3D sensors, printers and screens
• enjoyed the magic of an AR fairy book with my family
• considered how to dim lights to warm in the Object Net
• thought about Monsanto and open and local farming
• got lost at work, and considered the IoT office
• imagined how moving beacons would help people and cars publish 
• compared the Object Net's domain-level FOREST approach to AtomPub
• decided that ThoughtWorks Retail could use all of this stuff
• finally got around to summarising the Object Network for you
• got excited about bidirectional CoAP
• reported on my involvement with basic UK Government Web Standards
• imagined a future where you could easily copy between adjacent machines

I also went on a short trip to Venice. and linked to some snaps.

I'm not sure if I'll continue the pleasant discipline of daily blogging, now that my 60 days are up, but I do hope to.

I'll certainly keep blogging on the Augmented Reality Internet of Things manifested by the Object Network.

I've only just started...

Amazing Innovation at Raspberry Pi and Arduino Meetup

Tonight I attended the Surrey Geeks Meetup in the lovely offices of the generous Kyan in Guildford. The topic was essentially anything to do with Raspberry Pi and Arduino.  There was some pretty innovative stuff being talked about.

The organiser, Jon Nethercott, kicked off talking about the Arduino boards and the projects he had constructed, including an amazing capacitance meter that required no additional hardware. You could push a capacitor into two A-D pins and the display shield would quickly tell you what value it had, from 1pF up to hundreds of uF.

It has two ways of calculating the value: from 1pF to 1nF it measures the ratio of the capacitance of the test capacitor against the residual 25pF capacitance of the internal circuitry! I've done a lot of electronics in my early life (really early life - I built my first computer in 1977 using the 1802 CMOS microprocessor), but I've never, as far as I recall, had to work out the voltage distribution of two capacitors in series!

Jon explained it to me, and it actually works out quite intuitively - the bigger capacitor develops the smaller voltage, as from an electron point of view, it is similar to a lower resistance, as it has more "space" for electrons to flow into it.

Above 1nF, which is very large relative to the 25pF residual capacitance, Jon switches to an alternative technique using an internal pull-up resistance to charge the test capacitor, then measure the developed voltage and time taken to reach it. Once again, not a scrap of extra external circuitry since it relies this time on an internal resistance. Cool.

Related to the work I've been doing, Richard Jelbert showed us his Pi for cars with a BLE beacon attached. This could be used to drive an app on the driver's phone to pick up a small number of events broadcast from the Pi, including from sensors. For example: when the driver enters the car, starts it, stops it .. or crashes it! This could be used to reward clean drivers with lower insurance, without any inconvenience to the driver, who otherwise has to keep messing with the app controls at the start and end of the journey.

Richard also showed us his prototype for a Bitcoin vending machine. Seriously: a Bitcoin vending machine. You put in some cash and get a printed slip with two QR codes on it: the public and the private key for your entry on the blockchain.

My colleague in government and another meetup organiser, David Carboni, told us of his plans to enhance local neighbourhood safety with an automatic number plate recognition system. Every participant in a street would have Pies tracking cars via its camera. They could share the information to track stranger cars. The approach would involve quite a bit of image processing to normalise the image then extract the characters. There is this software which may be interesting to look at.

Next up, a Research Assistant from Guildford University, James Mithen, told us of his plans to get into ARM code and write another operating system for the Pi, as a fun exercise...

Finally, I stood up and told everyone about the Augmented Reality Internet of Things idea, with a mention of Minecraft house-modelling to get them all thinking I'm a nutter. It worked. They did.

We all talked more than we hacked or wired, which was great - and there's always next time to play with kit.

Really exciting stuff. And great pizza and great beer. Thanks to the organisers and hosts.

Seamlessly copying data between adjacent machines

This morning on the train I wanted to work on a document that was in a draft email that I could access from Google by 3G on my Android phone. But I wanted to work on the document on my laptop, which doesn't have 3G.

After my 25 minutes journey was done, I still hadn't solved the problem - how do I easily and reliably move data from the device in my hand to the one six inches below it?

Even the fact that I had to think about all the ways means it's just not something you do in any instinctive way.

I'm not asking for answers, by the way, I know about all the options (Bluetooth, hotspot, tethering). It's their reliability and ease of use that's part of the problem.

On the way back, there was a massive video advert in Waterloo station for the Audi car company. It said (I think; I was rushing past) "Number of Audi drivers in the station: 4567", and it was slowly incrementing. I presumed that they made that up - it seemed high - or used Twitter or something.

Then I thought, well, it'd be fun to offer iPhone-using Audi drivers an app which could be a beacon saying: "I'm an Audi driver!". Then if they were told to walk past the advert, well, you get the idea.

These two incidents got me thinking about commodity technologies for easy and reliable proximal data exchange.

And it's really still too hard to seamlessly move data between machines and devices that are right next to each other!

In our workplace, faced with the need to get a file from one PC to the one next to it, even techies have been known to send the data across the Atlantic via the US, because it's easier to email it thousands of miles than figure out a direct route of three feet.


Non-Solutions

I've listed some commodity wireless technologies already: Bluetooth, Wifi and Mobile data. You could add QR codes, NFC and RFID to those, of course, but they are still less common.

Now I've got a low tolerance for poor usability, but surely everyone hesitates before considering the buggy and unreliable, and cognitively complex Bluetooth approach. I can't even think how I'd do it, to be honest. I know it involves some kind of "pairing", and lots of failed transfers.

Wifi requires you to be logged in to a network with complex passcodes, and even then you'll probably need to play with IP numbers to do local file transfer.

Mobile data is not always available, is slow and unreliable when it is, and requires some or other proprietary intermediary.


Solutions

So, back to the Audi example: what if it was as easy as (a) being near and (b) setting the intent to share something, anything?

I should be able to pull up the draft email I had on my phone, hit "Copy to adjacent device .." and enter a 3-digit number (to prevent others being able to see it casually; say only one transfer is possible and it times out after a minute, to make it even more secure).

Now if I hit "Look for local data" or something on the other machine (laptop), I just need to enter the 3-digit number and it's there in seconds.

Similarly: PC #1: right click on file "Copy to adjacent device .. ". 3-digit number. PC #2 "Look for local data". 3-digit number. It's there.

The 3-digit number would be all you needed to confirm the particular transfer, perhaps when others were active around you, you wouldn't need to see or choose the filename being offered or anything.

I should be able to pull up a photo of myself that I use in public, or enter details into a profile document - including the car I drive - the hit "Publish to adjacent devices ..". No 3-digit number this time, of course. The peer device will "Look for local data" and suck it all in, then filter out the interesting stuff to stick up onto that 12-foot screen.

That should be built into every single smart device we use.

We could implement it in BT 4, WiFi Direct, whatever. It just needs to always be there, always work, and be that simple.

Seven uses of the Raspberry Pi Camera

My Christmas Pi came with a 5Mp (2592x1944) f/2.9 camera module, which I intend to use as my light level sensor. I also want to use it to detect the colour of the ambient light, so that my light Things can match it.

Further along, I expect I can use it for motion detection and to recognise QR codes, car number plates and faces. And to take pictures; almost forgot. But, baby steps..

For light level and ambient colour temperature, I'd need to point the camera at a sheet of white paper.

The challenge I face is to arrange one of the following:

(a) get the exposure - which I presume corresponds to shutter speed in some way, as it's a fixed aperture - and AWB colour value, set in the EXIF

(b) disable auto-exposure and auto-AWB, and do my own sampling of the exposure to find out how much light there is, then take the average colour of the image.

(c) get the exposure and disable AWB or vice-versa, depending on the EXIF

I've been looking at the documentation and sources for information today, but it's quite hard to find what I want. For option (b), I think --shutter and --awb should allow me to set the series of shutter speeds and to turn AWB off, respectively.

It's possible that I need to do (c) - there's something in the EXIF called Light Value but I can't see a colour temperature parameter.

On Wednesday, a group of us are getting together to hack some stuff, so perhaps I'll experiment then.

PS The title today is a dig at those awful traffic-hunting titles you see these days..

Augmented Reality position from beacon strength

Well hopefully you all enjoyed my 51 seconds of fame yesterday.

Although in that video, I skilfully managed to make it look as if my position, relative to all those BLE beacons, was being accurately tracked, the fact is that my algorithm is pretty dumb:

It puts you in the middle of the room or "place" unless you get close to a beacon, in which case, it gently moves you in towards the 3D virtual representation of the corresponding Thing object to that beacon, as advertised by its URL. When you go out of range, it glides you back to the middle again.

It's pretty effective for a simple algorithm, I hope you'll agree, but of course it does have limitations.

The main issue is that the RSSI signal strength is very jumpy, which means you can sometimes oscillate around when at the borderline. Both for the simple algorithm and for a future trilateration one, I'd need to filter or smooth the distance calculation better.

What I'll try is a smoothing algorithm that works asymmetrically. When the signal strength goes up, it's pretty much guaranteed to be because you've moved closer, due to the laws of physics. The same laws of physics also dictate that when the signal strength goes down, it's because of some random interaction with a plane going overhead and the phase of the moon.

So I'd have it work like this: moving in immediately sets a closer distance, but moving out is treated with greater suspicion - maybe smoothing it out over three samples.


Other Jobs

I had to set up the positions of the light objects manually for the video, and that will always be the case to some extent. I imagine the new Thing would have a guess where it is when installed, then the user could nudge it into its proper place in the 3D view. The initial position could be roughly worked out at the same time as fetching the URL of the nearest place from nearby beacons, which also has to be hand-configured currently.

Another thing is that I should demo more than one place, and move between two linked rooms. Most of the code is already there for that, I think.

I also don't track up-down orientation yet, just compass rotation. Again, it's not as big a loss as you might think, but I should add that sooner or later.

Very short video demo of AR+IoT in the Object Net

I spent all day today, thanks to my understanding family, preparing this 51-second video for you, about the work I've been doing for the ThoughtWorks 100 Days of Hardware:

It's my first ever YouTube video, and I'm quite pleased with it. I'm also pretty happy with the overall results I've achieved in the snippets of coding time I've had.


Mashability

Soon into my first practice take, I realised I couldn't actually touch the screen to change the light colour for the video, since I was holding my wife's iPhone in the other hand.

So I got the URL of the light up in my browser and typed in this thought-free code to make the light blink automatically, between red and green:

{ is: cuboid rule
  Timer: 0 => 2000
  light: (1 => 0) (0 => 1) 0
}

{ is: cuboid rule
  Timer: 0 => 2000
  light: (0 => 1) (1 => 0) 0
}

The point was not that I should have only written one rule not two, but that I could tap this in quickly while between video takes, in a browser editing page, and immediately see the light flash - both on my phone on the table and on the Pi next to it.

Which is one of the points of the Object Network. Instant gratification!

Which Contact and Event Formats for the UK Government?

Today, Paul Downey and I submitted two "challenge suggestions" to the UK Government's Standards Hub.

Now, we both work at the Cabinet Office, so I guess we have a head start in knowing about all this, as insiders .. but no-one will find the standards we're proposing to be in any way controversial.

We suggested that the UK Government should pick a standard for contact information exchange and calendar event information exchange. I won't bias the process by naming the obvious *ahem*vcard*cough* standards to *ahhh*icalendar*choo* at least give due consideration to, for these needs.

In true UK Government style (or the style of any Government I imagine), this process is done politely and at a slowww pace. Several packets of tea are consumed from the start to the end of the process.

To evidence this, there are already two accepted standards: paraphrasable as "Use UTF-8!" and "Use URLs!".

Baby steps, baby steps.

It's a long way to go from this to the Object Network contact and event formats, but once we've got something in the Standards Hub for contact and event, the next one to try for is: "A textual structured data encoding format with maps and lists, that is useful for moving data into and out of APIs".

That way we can then go on to suggest such an encoding of all the data available from our Government, which could include those contact and event types.

Not sure if we'd have to get HTTP - sorry, a hypermedia/data transfer protocol - in first, though.

Anyway, I've got plenty of time...

Bidirectional CoAP

I mentioned before that CoAP would seem to be a good protocol to implement FOREST over, as most implementations implement the observe spec.

CoAP is based on HTTP, thus inherits its asymmetric client-server model. However, it is also built over UDP, which is another loosening up of HTTP in CoAP that can help implement FOREST. FOREST's basic mode of interaction is peer-to-peer, with clients able to be servers and vice-versa.

So if I use CoAP, I'll have UDP packets for requests going in both directions between peers, and UDP packets for responses also going back in each direction. Even though CoAP isn't specified to be bidirectional, I could easily implement a bidirectional version of it once I have a unidirectional implementation.

If the code is all in NetMash, which is used on both clients and servers, then the bottom of the CoAP stack will be simply sending and receiving UDP packets: there's no separate TCP connection in each direction. You could have a single UDP port number at each end.

If you need to keep receiving updates to your cache of a response to an earlier request (which it seems is a feature being added to HTTP/2), then you're already getting towards a bidirectional protocol, since a spontaneous packet can now come back at the client instead of it always being the initiator.

I played with such a bidirectional protocol of my own for an earlier version of the Object Net, back in 2005, but then switched to using just dual HTTP channels and long-polling to cover asymmetric infrastructure. It's nice to be able to re-visit the concept with the IoT and CoAP.

What is The Object Network again?

I've been working on this project without really stopping to give an overview of all the elements of the Object Network. You can work it out from the articles and links, but here's everything summarised in one place.


Functional Observer

This is the basic programming and interaction model underlying everything. In a nutshell:

An object’s state is set as a Function of its current state plus the state of other objects it Observes through links. 

So imagine an object representing a light that is shining yellow. It links to another object representing the values of a dimmer. The brightness of the light depends on the value of the dimmer, so as the dimmer value observed by the light reduces, the light calculates a new RGB setting based on whatever colour it's set to, modulated by the dimmer value it can see through the link.

In the style of a spreadsheet, whenever the current light colour on the light, or the current value on the remote dimmer changes, it has work to do to set its current output in the RGB values.

I mentioned Functional Observer here and here.


FOREST

Functional Observer REST simply allows our objects to reside on different host machines. They talk RESTfully over HTTP in JSON. They have URLs and exchange state using GET and POST.

I mentioned FOREST here and here.


Cyrus

In order to know what state to set itself - what dependencies it has on peer objects and its current state - an object needs to be programmed or "animated". It could be programmed in Java - and that's exactly what I do for some functionality in NetMash.

But we can create a language that is a direct mapping onto the Functional Observer model above. The "Function" part can be pure: you don't need I/O or side-effects when all of that is taken care of in the objects you're rewriting.

Cyrus is a pure Functional Observer language. Being homoiconic, it is based on the JSON of the objects it is animating, but with much noisy syntax removed. Cyrus rules have their own URLs, of course.

I mentioned Cyrus here, here and here.


Object Network Types

These distributed, interacting objects can form a global Object Network or graph. But only if they all look pretty much the same.

So the Object Network defines a number of simple and stable formats within JSON for common needs, such as contacts, events, feeds, articles, media, GUI layouts, users, 3D objects, IoT Things, Cyrus rules, etc.

These types can also be represented in the cleaner Cyrus syntax.

I mentioned Object Network Types here and here.


NetMash

All of this is implemented in the NetMash Java code. NetMash is an Android app and a Java server. They share the same Object Network core code, including the implementation of the Cyrus language.

This whole blog is full of screenshots of NetMash in action.

Internet of Things and Augmented Reality in Retail

Today I received my latest copy of the Thoughtworks Perspectives mailing. This month's issue was a special on Retail. Our European Head of Retail, Mark Collin, has been interviewed on the "Essential Retail" site about the latest trends.

That's where I discovered a new term: "Phygital", which of course means the merging of physical and digital. Cute. "Internet of Things" seems quite a mouthful in comparison.

.. it will become a necessary reality that retailers have to find ways to subtly and seamlessly incorporate digital into a store experience and not just for technology sake or as a gimmick but to tackle core retailing issues like real time inventory, faster checkout, everything in my pocket (mobile – payment, loyalty, receipts, rewards, etc). The behind the scenes analytics opportunities are the significant side benefit to a customer experience premised on digital. 

- Mark Collin

Here's another, related article on the Thoughtworks website: Will iBeacon Further Enable the Passion of Shopping? And another from a Thoughtworker's own blog: Introduction to iBeacons by Andrew McWilliams.

Retail: The Thoughtworks Application of IoT/AR

So this got me thinking, that soon enough I'm going to want to explain how my 60 Days of Things, that I'm coming to the end of pretty soon, will benefit Thoughtworks.

And the obvious applications are all in retail, in interacting with customers within some environment, such as shops, malls, airports, stations, libraries, museums, theme parks, cinemas, sports centres, swimming pools, holiday camps, and so-on.


IoT/AR in Retail

Now currently, all the demos we have been doing inside TW and the typical example ideas that people have been coming up with in general in this area are about "IoT plus 2D smartphone app" interactions.

I can't see anyone else that has spotted the potential of combining "IoT plus Augmented Reality".

Tomi Ahonen, a mobile industry analyst who's predictions are extremely reliable, believes that Augmented Reality is the next big wave after mobile.

Just sayin'...

FOREST: a higher-level RESTful interaction model

I was having a good chat with my buddy Jim Barritt today, and the subject came up of how one could describe the difference between my FOREST approach to REST and the widely-used, traditional AtomPub style.


AtomPub

Quick summary of the AtomPub style: you have a client and a server where the server is a lot like a database of articles and HTTP is used by the client to edit those articles.

So the editor client says "POST" and a new article is created. It says "PUT" and the article is updated. "DELETE" is pretty obvious. The client, and indeed the world, can "GET" to read an article.

The client basically runs things and the server more-or-less does what it's told, modulo whatever it needs to do to ensure security and integrity. There are other bits like Media Types and Link Relations, but that's basically the model.


Almost Database Integration

When people want to "do REST", if they think they want to do it "properly", chances are they'll use this approach as their paradigm. I was slightly involved in the creation of the AtomPub spec, so I'm not knocking it, at least for this use case - editing articles.

Trouble is, it only makes sense if your application is a lot like a database, where you have some data that you want to create, update, delete or read. So, in order to do what they believe to be "proper REST", people end up forcing their inter-server interaction protocols into this simple, low-level, data read-write model.

And that feels uncomfortably close to a database integration style!


FOREST

In contrast, in the FOREST style, two application servers talk to each other at a higher level, as peers - they can be both client and server to one another.  A peer can GET the data of another - pull or poll - and can POST its own data to another - push.

It's a simple, symmetric model of interaction where the application protocol is like a two-way conversation. Being RESTful, all such data can be found at their URLs - this isn't just a substitute for messaging. PUT and DELETE aren't used at all, because the interaction model isn't about just low-level editing of data.

I'll be illustrating FOREST with an example on this blog, to show how such a conversation between peers can proceed. You'll see how it enables interactions that are at a higher, domain level.

Beacons that Move

Up to now, I've been talking about BLE beacons attached at fixed points around the house, office, shop, park, etc. The moving bit is you; or rather your Android device, that picks up the URLs and the signal strengths and drives a 3D AR app that maps out your surroundings.

Beyond that mode, I did mention that a fixed beacon could also scan around it - when first installed - to find out what place it was in and whereabouts it sat.

So the other two combinations left involve the Android device itself broadcasting, either to the fixed beacons or to other Android phones. Unfortunately, Android can't yet broadcast as a beacon through BLE - see this issue here and vote on it by starring. Android needs "Peripheral Mode" support, which iPhones do already have.

Once your phone can also act as a beacon, it can broadcast the URL of your person or avatar object.

The first benefit of this would be more accurate location - the surrounding Things would know how far you are from them and could collaborate on trilaterating your position, which you could combine with your own trilateration of their positions for more accurate results.


Publishing You

If your device were broadcasting, it could be used to notify surrounding people and machines of your presence, identity and other parameters and links you want to make public, through a packet of JSON fetched through the advertised URL.

This would allow various applications such as: automatically paying for a service by walking through a gate, exchanging behavioural tracking for store discounts and a conference birds-of-a-feather locator. You could even advertise that it's your birthday, or that you like rock climbing, your blog URL or your relationship interests. A more private view could show your health to your doctor.

You don't actually need BLE to do something like this: when you have WiFi switched on, your device gives away its unique MAC address while scanning for networks. Now you just need to map from that to your personal URL, which could be done through a MAC-to-URL lookup service a bit like DNS.


Beacons that Move

While waiting for Android to get peripheral mode and enable this huge range of applications, there are other examples of physical objects that can move and can be tagged with a beacon.

The TI SensorTag, the Ninja tag, the Chipolo, the Light Blue Cortado - all allow BLE tracking of the location of things they're attached to, or of values of their sensors, such as accelerometers.

Like you, your car can have its own URL, allowing similar applications such as automatic payment of tolls, fuel and parking fees, detection of presence for tracking in the home or the street, perhaps again in exchange for information or discounts. A more private view could show you the health of the car and allow you to set certain parameters and rules of operation.

Android better fix that peripheral mode if its Open Auto Alliance is to beat iOS, though..

Finally, robots can have "beacons that move", allowing all the above functionality plus a whole lot more, around collaboration and coordination of their joint activities.

Venice Holiday Snaps.. Not Today

I was hoping to show you some holiday snaps from Venice today, but I can't upload from my phone into the Blogger editor.

So here's my Twitter link, anyway, which has some photos: https://twitter.com/duncan__cragg