Radiodan Part 1: Expanding the Overton window, but for Radios

Radiodan is an Open Source (software and hardware) internet radio platform based around a Raspberry Pi. It was made in BBC Research and Development in the “Device Futures” Team. Dan Nuttall, Andrew Nicolaou and I worked on Radiodan with help from other colleagues, particularly Joanne Moore, Andrew Wood, Chris Needham, and Tim Broom.

Andrew and Dan are leaving the BBC at the end of this week, so now seems like an excellent time to reflect on what it was for and how it was useful.

tl;dr

Our work on Radiodan over the last two years was a two-pronged approach to understanding possible futures for radio. One prong was structured conversations with people about what they wanted from radio. The other was a prototype-led investigation into how to make a radio: what the architecture would look like, how it might be controlled, whether it would work, and how much it would cost to make.

By talking to people about what they wanted, we expanded our own frame of reference about what a radio might be. By grounding the work in physical prototypes we gained a deep understanding of how new radio-like devices might be made. By showing other people those prototypes, we expanded their frame of reference too.

Overton window?

“Expanding the Overton window for Radios” is an analogy too far, probably, but here goes anyway.

At Bristol Hackspace we started getting people to draw what they wanted from a radio. I went around persuading people to tell me about the radio they wanted. Sometimes I drew it for them, and sometimes we got them to draw it themselves, with a few little props (outline of a radio, some stickers for buttons and dials, speakers and lights). Among the many lovely ideas, this is my favourite (by Paul Downey):

psd_radio

When you explain the Archers Avoider, ask people to think about physical radios, and give them this set of simple tools, they say “oh!”, and then they say “my radio would do this: ….” and tell you. We soon had dozens of them.

A couple of years ago, I talked[1] about a “Cambrian Explosion”[2] of radios based on these postcards, from which we could choose the “best” ones:

cambrian

This is a kind of shuffled, messy product-space, a bunch of different features and ideas with no structure and no systematic way of exploring it.

Richard Pope’s mind-expanding blog posts Product Land part 1 and part 2 (which you should read), suggest a more structured approach to exploring this space, by figuring out the dimensions of the product and then exploring different points in that space. I think we are taking different approaches to the same problem. Richard writes:

“My proposition is that digital products are also inherently complex and inherently multidimensional, that design is too often constrained by our methods of thinking about them and too often risk being either derivative or simple iterations of variants as a result; or worse, user needs are never met as well as they could be because we are looking for solutions in the wrong place.”

There is an argument that radios just do a job and do it well. The postcards people made say something else:

There are lots of potential features of radio that people would enjoy that don’t exist.

Many won’t be viable in the slightest, but some might be, and we can’t build them – whether as a physical device or in an app – if they aren’t part of what we consider to be part of the “radio” class of products. As Richard puts it:

“You can’t build what you can’t think of in the first place.”

There’s also a genuine, interesting, argument about accessibility here. If you don’t ask a wide range of people what they want from a device, you probably won’t be able to guess what it is they want or need. The postcards surprised us. We were getting slivers of light into bits of the product space for radio that we hadn’t considered.

Finally to the Overton Window

The Overton window is the current frame of reference in politics, the range of ideas that the public will accept, which determine the viability of policies electorally. Currently, Jeremy Corbyn is held to have shifted the Overton window in the UK to the left, from (a) to (b) like this[3]:

overton

Radiodan is a little like the Jeremy Corbyn[4] of radio devices.

We were using mechanisms to try and expand the acceptable range of what constituted a radio by peering into a messy product space and then translating what we saw into prototypes.

I’ll write about the prototypes we made in part 2.


[1] I made Dan and Andrew put it into their Solid presentation about Radiodan
[2] I’d been listening to this really excellent In Our Time about the Cambrian Explosion
[3] Not to scale
[4] #SorryNotSorry

Thanks to many people for reading drafts of these posts: Damian Steer, Dan Brickley, Richard Sewell, Dan Nuttall, Andrew Nicolaou, Tristan Ferne. All errors and poor analogies are mine.

AWS Janus Gateway strangeness

Can anyone think of a reason why this might happen? (janus gateway is a webRTC gateway – https://planb.nicecupoftea.org/2015/08/15/aws-janus-gateway-strangeness/)

  • Free tier t2.micro AWS, brand new account
  • select ami-886e3aff (via http://cloud-images.ubuntu.com/locator/ec2/), create instance, all defaults; new security group with all tcp and upd ports open; used default vpc, new key
  • chown 400 hsh7.pem
  • ssh -i hsh7.pem -v ubuntu@public-ip
  • installation steps below

result: go to http://public-ip/janus-gateway-streamtest.html in Firefox 40

In my house I can see a testcard.

On no other network can anyone see a testcard.

WHY?

Steps:

sudo apt-get update && sudo apt-get upgrade

sudo aptitude install libmicrohttpd-dev libjansson-dev libnice-dev libssl-dev libsrtp-dev libsofia-sip-ua-dev libglib2.0-dev libopus-dev libogg-dev libini-config-dev libcollection-dev pkg-config gengetopt libtool automake dh-autoreconf gupnp-igd-1.0

git clone https://github.com/meetecho/janus-gateway.git
cd janus-gateway
sh autogen.sh
./configure --disable-websockets --disable-data-channels --disable-rabbitmq --disable-docs --prefix=/opt/janus
make
sudo make install
sudo make configs

sudo pico /opt/janus/etc/janus/janus.plugin.streaming.cfg

[gst-rpwc]
type = rtp
id = 1
description = RPWC H264 test streaming
audio = yes
audioport = 8005
audiopt = 10
audiortpmap = opus/48000/2
video = yes
videoport = 8004
videopt = 96
videortpmap = H264/90000
videofmtp = profile-level-id=42e028\;packetization-mode=1

Installing gStreamer and Nginx

sudo apt-get install libgstreamer0.10-0 libgstreamer0.10-dev gstreamer0.10-tools gstreamer0.10-plugins-base libgstreamer-plugins-base0.10-dev gstreamer0.10-plugins-good gstreamer0.10-plugins-ugly gstreamer0.10-plugins-bad libgstreamer-plugins-base1.0-dev

sudo aptitude install nginx

cd /var/www/html

sudo cp -r /opt/janus/share/janus/demos/* .

sudo curl -O https://gist.githubusercontent.com/libbymiller/70ad942d070853167659/raw/acc38f4ccefb2c333a4cca460ec52a3151cbeebd/janus-gateway-streamtest.html

sudo service nginx start

test – 2 x windows

gst-launch-0.10 videotestsrc ! video/x-raw-rgb,width=640,height=480,framerate=30/1 ! videoscale ! videorate ! ffmpegcolorspace ! timeoverlay ! x264enc bitrate=256000 profile=1 tune=zerolatency ! rtph264pay ! udpsink host=127.0.0.1 port=8004

/opt/janus/bin/janus -F /opt/janus/etc/janus

HackspaceHat part 2: Streaming to a remote sever

We’ve made more progress on the HackspaceHat (HackspaceHat is a telepresence hat for exploring Hackspaces). Part 1 has a bit more background.

20159426111_57c71f2d62_k

  • We have a hat! At Barney’s suggestion it’s an Isambard Kingdom Brunel-style stovepipe hat (£6!), giving it a Bristol theme but also plenty of room for electronics / batteries etc. Other hackspaces would need to choose a hat appropriate to their locale.
  • We’ve decided on a means to ensure that people are aware that the camera and audio are being used. Our initial thought was an emergency services style flashing blue light, but Alaric had a better idea: an “On The Air” sign with a light built into the hat.
  • We did a local test of the components draped over the hat to work out the position of the camera.
  • We realised we should use it for reporting live from Bristol Mini Maker Faire!
  • We’ve managed to get it working on a remote server, after some bother with ec2.

Here’s some information about the remote part. It still doesn’t work on an ec2 instance and I’m quite baffled as to why not – any ideas appreciated. It’s very strange because it does work from within my house when run on an ec2. But not when accessed from anywhere else.

Here’s what I did:

  • Ran up a new instance of Ubuntu LTS 15.04 on ec2 under a VPC
  • Installed janus-gateway and gstreamer

I opened up all the ports required for Janus-gateway with my video stream (inbound ports):

HTTPS TCP 443 0.0.0.0/0
HTTP TCP 80 0.0.0.0/0
SSH TCP 22 0.0.0.0/0
Custom UDP Rule UDP 8004 0.0.0.0/0
Custom TCP Rule TCP 8088 0.0.0.0/0

I ran this test gstreamer pipeline, which just creates a testcard and streams it to port 8004 on localhost:

gst-launch-0.10 videotestsrc ! video/x-raw-rgb,width=640,height=480,framerate=30/1 ! videoscale ! videorate ! ffmpegcolorspace ! timeoverlay ! x264enc bitrate=256000 profile=1 tune=zerolatency ! rtph264pay ! udpsink host=127.0.0.1 port=8004

Downloaded my testpage into /usr/share/nginx/www/

cd /var/www/html
sudo curl -O https://gist.githubusercontent.com/libbymiller/70ad942d070853167659/raw/acc38f4ccefb2c333a4cca460ec52a3151cbeebd/janus-gateway-streamtest.html

Started Janus gateway with this config at /opt/janus/etc/janus/janus.plugin.streaming.cfg:

[h264-sample]
type = rtp
id = 1234
description = H.264 live stream coming from gstreamer
audio = no
video = yes
videoport = 8004
videopt = 126
videortpmap = H264/90000
videofmtp = profile-level-id=42e01f\;packetization-mode=1

/opt/janus/bin/janus -F /opt/janus/etc/janus

Went to http://<ec2_public_ip>/janus-gateway-streamtest.html on Firefox 39.

Expected behaviour: see a testcard, like this:

screenshot_testcard

…and inside my home network I do, but on any other network, I don’t see anything, and sometimes get an ICE error in the console:

Object { janus: "hangup", session_id: 10826300, sender: 1905332350, reason: "ICE failed" } janus.js:196:3

WTF?

Exactly the same set up on an identical Linode instance works perfectly, from everywhere.

The difference might be that ec2 instances have all incoming ports firewalled by default, but it’s very strange even so. Why would it only work in my house?

Anyway, it works! sort of! I set up a gstreamer pipeline on a pi 2 sending its streams to the linode instance and that was fine, though not very peer-to-peer (kudos to AndrewN for arguing that that was actually more efficient if there are multiple clients accessing it).

danbri and I tested it Bristol->Sarajevo with an irc command channel (“turn right!”).

It kind of works over 3G too, which raises interesting possibilities.

Next jobs:

  • Try and make it more p2p
  • Run up a stun / turn server instead of using the Janus defaults
  • Add in an audio command channel
  • Continue investigating the ec2 problems

HackspaceHat part 1: WebRTC, Janus and Gstreamer

Barney and I have been working on a “HackspaceHat” – a telepresence hat so you can show people around Hackspaces. The idea is this: someone in the hackspace puts on the hat. This turns it on, and triggers a message (to twitter?) that the hat is available. Then someone can join via a web browser, see and hear what’s happening as the wearer moves around the space, and send voice requests about what direction to go in.

We were thinking of using WebRTC for it, as there’s quite a lot of support in various browsers for it, and that makes the “user” end of the hat quite straightforward. However, we’ve not yet found a great solution for the “hat” end.

Here’s where we’ve got to, and rough instructions to get as far as we have. I’ll do a step by step guide when we’ve got further.

Where we are:

  • happily streaming audio and video from a Pi 2 to Firefox, with low latency, by accessing a web-server on the device, on a local network on a separate machine

Where we want to be:

  • sending audio the other way
  • hosting the application on a remote server and accessing it via a different network

Instructions

Install Janus gateway

I followed these instructions. There are a few slight alterations in the installation of gstreamer, and I’ve added in audio.

Install Janus gateway as in those instructions:

$ sudo aptitude install libmicrohttpd-dev libjansson-dev libnice-dev libssl-dev libsrtp-dev libsofia-sip-ua-dev libglib2.0-dev libopus-dev libogg-dev libini-config-dev libcollection-dev pkg-config gengetopt libtool automake dh-autoreconf
$ git clone https://github.com/meetecho/janus-gateway.git
$ cd janus-gateway
$ sh autogen.sh
$ ./configure --disable-websockets --disable-data-channels --disable-rabbitmq --disable-docs --prefix=/opt/janus
$ make
$ sudo make install
$ sudo make configs
$ sudo nano /opt/janus/etc/janus/janus.plugin.streaming.cfg

edit out the others and put this one in (slightly modified from the tutorial, to allow audio):

[gst-rpwc]
type = rtp
id = 1
description = RPWC H264 test streaming
audio = yes
audioport = 8005
audiopt = 10
audiortpmap = opus/48000/2
video = yes
videoport = 8004
videopt = 96
videortpmap = H264/90000
videofmtp = profile-level-id=42e028\;packetization-mode=1

Install gstreamer

The instructions are slightly out of date – you need to do his:

sudo apt-get install libgstreamer0.10-0 libgstreamer0.10-dev gstreamer0.10-tools gstreamer0.10-plugins-base libgstreamer-plugins-base0.10-dev gstreamer0.10-plugins-good gstreamer0.10-plugins-ugly gstreamer0.10-plugins-bad gstreamer0.10-ffmpeg

The gstreamer pipeline I used is this:

raspivid --verbose --nopreview -hf -vf --width 640 --height 480 --framerate 15 --bitrate 1000000 --profile baseline --timeout 0 -o - | gst-launch-0.10 -v fdsrc ! h264parse ! rtph264pay config-interval=1 pt=96 ! udpsink host=127.0.0.1 port=8004 alsasrc device=plughw:Set ! audioconvert ! audioresample ! opusenc ! rtpopuspay ! udpsink host=127.0.0.1 port=8005

– basically the raspi camera piped to two gstreamer pipelines, one for video, one audio. You seem to be able to just concatenate them together.

Note: I used a cheap little USB audio card for this – like this one. To find your device name (mine is “plughw:Set”) do:

cat /proc/asound/cards

and look for the USB one. You may need to do this too:

sudo nano /etc/modprobe.d/alsa-base.conf
Edit
options snd-usb-audio index=-2
to
options snd-usb-audio index=0

and reboot (see this post for more useful audio commands for the Pi).

It’ll need a microphone in the mic slot.

Install nginx

(Again following the instructions here)

$ sudo aptitude install nginx

Copy the Janus HTML content to the Nginx server root:

$ sudo cp -r /opt/janus/share/janus/demos/ /usr/share/nginx/www/

Start Nginx:

$ sudo service nginx start

Go to the Janus gateway demo page

(I’ve modified the streaming example a bit to understand it better – see this gist – so you could put that in /usr/share/nginx/www/ if you like.)

Then – assuming the Pi is on the same network – go to

http://<ip.of.pi>/demos/streamingtest.html

(or http://<ip.of.pi>/demos/janus-gateway-streamtest.html if you’re using my modified version) and you should see video and hear audio in the browser.

AWS new instance ssh timing out

In case this is any use to anyone else –

I’ve had AWS instances running for a few years. Today I went to create another one for something and infuriatingly, couldn’t connect to it over ssh at all: ssh just kept timing out.

I found a few links to do with groups, but the default group created for me in the (much improved) wizard seemed to be fine for incoming ssh connections. I then found a bunch of links about ip tables and the like, and after an extremely frustrating hour got it to work. Essentially (and without having done much research on this), AWS seems to have moved to a Virtual Private Cloud architecture, which existing users like me seem to have been moved into by AWS creating a default VPC for me, but one which somehow didn’t allow incoming connections.

I’m really not sure precisely why it worked, but it happened shortly after I created a new VPC and then created an instance using that. My VPC has DNS resolusion, DNS hostnames and “classic link”.

So: vague, but maybe it’ll help someone.

Some links:

Ubuntu EC2 AMIs

Types of AWS instances

Amazon Linux AMI Instance Type Matrix “This table shows which flavors of the Amazon Linux AMI are recommended on each Amazon EC2 instance type.”

Instance Storage

Adding an EBS (storage)

EC2 instance pricing

Connecting to your instance using ssh.