The Temperature Differential

Release 10 had a really significant change to the way it handles devices - changes that mean rewriting code for every device that's been supported so far. It was a LOT of really tedious and intense work, but the change was necessary, and now we're going to do an experiment that uses the new feature that all that work went towards.

In the original implementation of Sniff it was clear that there needed to be a way to hook into external library code, so that Sniff wasn't just a sandbox, but a real tool. In Scratch that takes the form of additional "extension" blocks, but that approach is fundamentally problematic (and the Scratch Team are still struggling with this), as it creates an explosion of blocks. Each new device essentially extends the language. This wasn't really an option for Sniff. Instead we added the 'tell" command so you could tell a library to "doSomething", essentially providing a mechanism for Sniff to call an external C function. Libraries of external code are good solid programming practise.

However it turned out it worked a little too well. We LOVED devices, and writing new devices for all sorts of hardware was great fun. And as we wrote more we started to want to do more with them, and so for example the DS18 thermometer library and the DHT thermometer library started to become more like objects. We added the configuration parameter so you could bind a ds18 to a particular pin. Then we added aliasing so you could swap between different libraries with similar operations.

However one thing was missing: multiple instances. What if we wanted two thermometers? Sure we could use one ds18 and one dht, but that's clunky. We needed a way to connect two ds18's on different pins. With the new release that becomes possible, and it works exactly as you'd expect. Let's connect two ds18:

make airThermometer ds18 device A2
make pondThermometer ds18 device A3

and it simply works. Of course not all devices can have multiple instances - for most devices its simply not possible to physically connect multiple pieces of hardware, but for the types of devices where it makes sense, it should just work (by which we mean we spent many hours making it work, so it would "just work" for you).

So what can we do with this... Well in the gardens of Sniff Manor is the ornamental lake, and in winter the fish seem to get along fine, even when the surface freezes. If we had two thermometers we could measure the air temperature and the water temperature a few feet down and understand whats going on.

The DS18 family of thermometers, are cheap, use a single pin, and are available in a waterproof casing/cable configuration. Wiring up a DS18 is pretty easy: connect the black wire to earth, red to 5V, and yellow to a data pin. The only tricky bit is to connect a 4K7 resistor between  signal and 5V, and you're good to go.

As this is going to be outside, running on batteries an Arduino is a better choice than a Pi, but the DS18 plugs into a Pi fine, so for other applications the code would run fine on a Pi too.

make i2c device

make display lcdi2c device

make message string

make displayFlush boolean

when start

.forever

..tell pondThermometer to "start"

..tell airThermometer to "start"

..wait 2 secs

..tell airThermometer to "read"

..set message to join "Air  " [ temperature ]

..tell display to "show"

..tell pondThermometer to "read"

..set message to join "Pond " [ temperature ]

..tell display to "show"

As this wasn't going to be connected to the computer I added an i2c lcd text display. The wiring here is even easier, as they simply plug into the breakout shield with a 4pin dupont cable. With that done the code is about as trivial as it gets.

The next step was to add data logging, so I added an SD card reader. Using the sdcard and filesystem devices I added code to write the readings to a file once per minute. At this point I could have removed the LCD display, as its using battery, and isn't strictly needed to log the data, but it was still useful to be able to see that everything was working.

Now we just put it all in a plastic bag, and of down to the lake!

Here's everything set up at around 6PM at night. You can just about see that the air temperature is around 21 degrees C, and the water is 17.

Two hours later we're just around sunset. Air temp has dropped to just under 18, but the water has stayed rock solid at the same 17 degrees.

The data on the SD card is record as text with each line containing the time, and the two temperatures, with comma's between them. This is exactly what we need to load into any spreadsheet program as a CSV file. I bit of tweaking an we get a graph:

Wow! That's real data that is, and it shows something pretty amazing. This log runs for a little under six hours starting late morning. Nothing much happens for the first hour, but then the sun gets over the trees at around lunchtime, and the air starts to warm up from around 23 degrees to over 28. We also get lots of great peaks and troughs - presumably from cloud cover. By mid afternoon we see that the has got less intense, and temperature starts to fall away.

However sometimes the most exiting thing is what doesn't happen - look at the green line. It starts at about 16.5, and be mid afternoon its risen by only 1 degree. Towards the end of the day its still going up slightly (as the sun is still hitting it, and the air is still warmer than the water), but it's levelled off.

1 degree is pretty small... or is it? 1Joule of energy is required to raise the temperature of 1g of water by 0.24K (or 0.24C - its the same thing). We've raised it by 1 degree in about 4 hours, or 1 joule/gram/hour.

To find out how much energy that is in total we need to know water we have! That's easy its 5mx2m and 1m deep. Or 10 cubic metres. 1 cubic cm of water weights 1g, and there are 1million cubic cm in 1 cubic metre. In other words we've got 10million grams of water!!!!! That sort of changes things as our 1j/g/h is now 10,000,000 joules per hour! That's about 3000 joules per second, which are better known as Watts. 3kWatts is quite a lot of power - if you tried to get that much power out of an electric socket you'd blow the fuse! You could power pretty much all of the electrical stuff in your house with that... until it gets dark.

Theoretically we could get more than that: According to more accurate measurements we should be able to get 1.4kW per square meter which would make a very impressive 14kW of energy going into the pond, but no system is 100% efficient, and the energy going into the pond is also heading the ground at the bottom of the pond (aka the planet - its pretty big!), so if we're keeping 3kW (about 20%), then that's pretty good.

I get really excited when an experiment works like this - we got a great graph, analysed some data, and got some big numbers which actually match what the theory says we should get. That's a good days work!

the next step is to hook up some better batteries, and solar cells and see if we can get this thing running 247!

Wedo physics

I'm really excited about getting the Wedo working with Sniff - it seems to be a missing piece of the puzzle that makes it easier to get in on the fun of physical computing without having to wire stuff up, or worry about class 6B shorting out the GPIO on all your Pi's!

It's been ages since we've done any science here on the Sniff blog, so lets do some basic physics with the Wedo...

One of the really useful parts - perhaps one of the most culturally significant of its day is the discovery of the pendulum. A pendulums period depends on its length, and NOT its mass. That let people build clocks, and measure time accurately - without the pendulum there'd be not time keeping, which rules out accurate navigation (remember the original Longitude prize?), pretty much any kind of science (cause we're always measuring how long things take), no school time tables, and no iWatch. I'm sure you could integrate this into a wider cross curriculum activity about time and timekeeping, but for now lets get back to the experiment.

This is the easiest Lego build ever:At one end we've got the Wedo, and an axle. On the axle is a long brick, which is connected to other long bricks to make the arm. At the end of the arm are a couple of tires to make a weight. A little way down the arm I 've attached the wedo tilt sensor, so that its horizontal when the arm is vertical. Strictly for this to work the arm should be much lighter than the weight - we'll see how that works out...

make wedo device

make wedoConnector number

make wedoValue number

make startTime number

when start

.set wedoConnector to 1

.forever

..repeat until wedoValue=1

...tell wedo to "readTilt"

..

..repeat until not wedoValue=1

...tell wedo to "readTilt"

..

..say [timer - startTime]

..set startTime to timer

The code is equally trivial. If we ignore the timer code for now, we wait until the sensor is reading one indicating the sensor is tipped forwards, then wait until it leaves that region. At the moment the sensor stops reading 1 we print out the time since we started, then go back ground, and wait for it to happen again.

It turns out to be pretty accurate - our makeshift pendulum is accurate to within a few hundredths of a second. Using the internationally recognised standard of unit of measurement : the Lego Stud, out arm is 49studs long and has a period of 1.2 seconds (give or take about 2 hundredths of a second). 

Taking out 2 of the bars gives us a length of 27studs, and a pretty reliable period of 0.9s.

So what does the maths tell us to expect? Well assuming a "perfect" pendulum, swinging over a small angle, then:

[Cite Wikipedia]

Where T is the time period, l is the pendulum length, and g is the gravitational force which on earth is 1226studs per second squared (you may be more familiar with the metric version of 9.81 m/s/s).

Plugging 49 studs into this equation gives 1.25s, while 27studs give 0.93s

WOW!!!!! That's pretty much spot on...

But there's another way to spin this - I knew T and l, and I looked up g (then converted it to Lego). I used that to check my experiment. My experiment was how accurate is a lego Wedo pendulum at keeping time (pretty good!).

But there's something in that equation that we actually might not have known: g. It's been pretty well measured and documented, but when did you last check?

We can rearrange that equation, and using 49studs and 1.2 seconds we get g=1343studs/s/s  (or 10.7m/s/s). That's about a 10% error, which considering the pendulum equation is only an approximation, and we build it out of Lego, that's pretty amazing.

WE JUST MEASURED GRAVITY WITH LEGO!

We do WEDO!

Unless you're a primary school teacher you've probably never heard of the Lego Wedo. We hadn't either, which is a shame because they're actually really cool. Everyone loves Lego, but as you've  probably noted in the last few posts, Lego EV3 is expensive and quite hard work to get started with. I know of one local high school where the design and technology team went with regular Lego Technic's Power Functions motors, as the PF components are about half the price of the equivalent EV3 components. They can build machines, and power them much more cheaply than an EV3 setup.

The downside is of course there are no PF sensors, and you can't hook them up to a computer.

EXCEPT THAT LEGO 

DO MAKE  PF SENSORS 

AND A COMPUTER INTERACE!!!

Wow!! Every PF forum has people asking how do I make "smart" power functions, and the replies are all about hacking cables, when Lego sell a set to to exactly that

Lego 9580 WeDo Construction Set

There it is Lego 9580. Look at those bricks at the front... They're Power Functions, but not as we know them.  There's a PF "M" motor, but on the right is the WeDo USB hub... That's right - it plugs into any computer, and replaces the PF battery box, so you can drive motors from the computer. But look what else - that's a tilt sensor, and an IR range sensor!!! All PF compatable.

We why have't we heard of it? Well as the ad's used to say "remember, Lego Wedo isn't available in the shops!". It's Lego education, which means its expensive and hard to find, but its out there (and its on Amazon!). Expect to pay around £120 for the set. Alternativly if you shop around, you might find the components available separately - the HUB costs about £35, while the sensors are £15-£20. £70 for the "cool parts" isn't cheap, but its cheaper than the equivalent EV3 kit.

The Wedo is targeted at primary school children, with some simple to use software (not included and another £70!) that lets you build, and control mini-machines. While its expensive, a lot of work has gone into supporting lesson plans and kids will go crazy for it, so its probably good value (ironically my daughter came home from school the same day my Wedo arrived, raving about how they were doing a new exciting project at school - they were using the Wedo!).

But given how obviously useful, and in demand the functionality of Wedo is in secondary schools, and among "older" Lego users, why isn't it a standard PF brick that's in every toy store? I guess the answer is Software - Lego have got software for KS2 children, built and ready to go. To sell Wedo to a wider audience it requires development and support of more general tools, which simply don't exist yet...

The good news is that the Wedo works in Scratch, so you can introduce kids to the Wedo there, and get them building. When they move to Sniff, its probably a good idea to revisit some of their Wedo projects again, and rework them in Sniff.

To get started you'll need to hook your Wedo up to a Pi, or generic Linux machine [Update: It works great on Windows and Mac now too, though wedoScan is Linux only]. Then run the Sniff setup file, and you should be able to type "wedoScan" to find and interrogate your Wedo.

Found Wedo on HIDraw 2

plug 1: Motor

plug 2: Tilt

It should report something like the above. It also turns the motors off which can be handy! If it doesn't report the connections correctly, run it again after a couple of seconds - the hub can report incorrectly if the motors are/have been running, and a recscan usually fixes it.

Now we know its all hooked up we can program it:

make wedo device

make wedoConnector number

make wedoValue number

Start by making a wedo device. If you like you can use the HIDraw number that wedoScan found (usefull if you have several hubs!), or simply let the device find the hub for itself.

when start

.forever

..set wedoConnector to 2

..tell wedo to "readTilt"

..

..say [wedoValue]

To get things going we specify the connector we're interested in, and in this case (as it has a Tilt sensor attached, we call "readTilt". The values returned in wedoValue are:

#0 Flat

#1 Forward (away from wire!)

#2 Back

#3 Left

#4 Right

Having read the Tilt sensor, we can use that to control the motor speed:

..if wedoValue=1

...change speed by 0.1

..if wedoValue=2

...change speed by -0.1

..if speed >1

...set speed to 1

..if speed <-1

...set speed to -1

..

..set wedoConnector to 1

..set wedoValue to speed

..tell wedo to "setMotorSpeed"

We adjust the speed variable, and then select the connector, and value we want to send. For a motor wedoValue should be between -1 and +1, with 0 being stopped.

There's also a readDistance command, which tries to return a value in metres, though that might be a bit inaccurate. Try running:

when start

.forever

..set wedoConnector to 2

..tell wedo to "readDistance"

..

..say [wedoValue]

and pick values appropriately.

And that's it! Lego Wedo control. You could also hook up the PF lights, and Servo (just use the motor commands) and build something really cool. If you're luck enough to have more than one Wedo then you should be able to hook up as many as you like (up to about 90 or so!). Just make a device for each, and give it a name:

make leftHub wedo device 2

make rightHub wedo device 2

Now for the really exciting bit... This works on Linux...The Lego EV3 runs linux... In principle it should be possible to run this on the EV3, and connect the EV3 to Power Functions using official lego blocks!!!! This is something of a holy grail in the EV3 forums. However there's a catch - the standard EV3 linux distro is quite old, so you'll need to update it to something that supports "HIDraw" (a way of accessing USB devices). Lego may provide this in a future update, but if you're prepared to go a little "of grid", you could try installing the ev3dev, or LeJos firmware, and try it!

The code in this post is in the Sniff/examples/Hosted/wedo folder. You can also find the source for wedoScan (and ev3dude) in Sniff/utils.

Release 10

We've been working crazy hard the last few weeks to get a lot of new features into Sniff.

The new build now supports EV3 over bluetooth. We'd still recommend having a wifi adapter as that lets you telnet into the Brick, and run programs directly but using the ev3dude program we developed you can now transfer programs to the Brick using only bluetooth, and once you've installed the sniffMenu program you can run Sniff programs straight from the Brick's onscreen menu.

We also discovered one of Lego's best kept secret products - the Wedo! This lets you connect Lego power functions bricks to a computer via USB. We've figured out how it works and added support for a Wedo Sniff device - it works great on Raspberry Pi, and we'll post a longer post about it asap.

However the big change is under the hood. Previously devices worked like code libraries - you imported them once and used them. However now they're more or less real objects - each time you creates a new instance, for example you can hook up as many dht11's as you have pins. You can even hook up multiple Wedos!

You can download Release 10 now!

(We've also given up calling them Beta releases - Sniff works. We'll still be evolving it, but its now a stable and fully operations system).

ev3dude: programming the Lego EV3 without WIFI

To get access to the Unix shell on the EV3 you need a WiFi adapter. That's sort of OK, but only 1 adapter is supported, and its quite large. If you don't have one, you don't have access to a WiFi network or perhaps you've simply put the EV3 somewhere a the adapter isn't going to fit, then you can't get a shell, you can't use SSH and you can't transfer files.

However the EV3 has USB and Bluetooth built in. The problem is that they only supports the proprietary protocol used by the Lego Software. A couple of people have built tools to work with it, buts what's needed is a generic, and simple command line tool that lets you transfer files to the EV3. Well here it is and its called ev3dude!

Firstly you need to pair your computer to the EV3 over Bluetooth. As my only bluetooth machine is a Mac, I've built and tested on that, and when you pair it creates a file called /dev/cu.EV3-SerialPort. The name will change if you've renamed your brick to something other than EV3, but it'll be something like that.

Now get the source to ev3dude, and compile it by typing:
make ev3dude

now test it by running
ev3dude /dev/cu.EV3-SerialPort

(or whatever your device is called).

Now you can get a directory listing of your SD card by typing:
ev3dude /dev/cu.EV3-SerialPort -l /media/card

The formatting is a bit funny, as the EV3 sends md5 hashes of the files, along with their size and name, but the info is pretty clear.

To write a file
ev3dude /dev/cu.EV3-SerialPort -w myLocalFile /media/card/filenameOnBrick

and if you change your mind you can delete it again:
ev3dude /dev/cu.EV3-SerialPort -d /media/card/filenameOnBrick

That's it! Simple and clean EV3 file transfer. It should compile without any serious issues on any Unix (let me know if it doesn't!). You're free to use and modify the code as you see fit, but please send back any changes/improvements/bug fixes so we can make this a better tool.

Combined with the Sniff menu system described in the last post we've got a mechanism for installing and running Sniff code on the Brick without WiFi. It'll be fully integrated into Sniff in the next release, but for now you can use ev3-sniff to generate the binary, and transfer it manually with ev3dude.

You can download ev3dude.c here.

Running Sniff on the Lego EV3

In a previous post we discussed how to get a C program running on the Lego EV3, as a working C toolchain is prerequisite for running Sniff. It's quite a hassle to set up, and to get the EV3 running nicely is a bit more of a hassle, but once its set up it's a pretty nice platform for running Sniff on.

The new release (Beta 9) supports the EV3, though so far it only supports the buttons, LED's and the screen. Support for motors and sensors will be forthcoming in the next releases, as and when I can get my hands on the relevant devices.

Once you've installed the C compiler, and the new Sniff release on your host machine, there's a couple of things you need to do to make everything work.

The first thing to do is make sure the bricks WiFi is enabled, and connected. Then on your host machine, initialise Sniff, and run "ev3finder". This prints out the ip address of your Brick. In the shell type:

export EV3HOST=192.168.0.123

or whatever the IP address reported is, to tell the system how to find the Brick.

Then connect to the brick and enable ssh:

telnet $EV3HOST

login as root (no password!)

and type

dropbear

First time setup:

If this is the first time you've used Sniff on the Brick you'll need to make  a folder for it:

mkdir /media/card/Sniff

Now go back to your Mac or Linux machine and you should be able to compile programs using ev3-sniff, just as you would for any other platform. When you compile a program it will be placed in the Sniff folder on the memory card, and you can run it from the telnet session.

However if you want to use the keypad or the screen your program will "fight" the LMS/EV3 user interface, and it'll be a bit of a mess. It also means you have to have another machine, and a WiFi connection which might not always be possible.

The solution to this is based on a trick by RobotNav. In the Sniff/Examples/EV3/SniffMenu folder is a Lego VM program: the source is Sniff.lms, but you just need the compiled version Sniff.rbf. Place this in the Sniff folder with

scp Sniff.rbf root@$EV3HOST:/media/card/Sniff

You can run this from the Bricks on-screen menus. When you do it will try and run a Sniff program called sniffMenu. You'll find this in the same folder. If you simply compile that it will install on the Brick. sniffMenu lists all of the installed programs in the Sniff folder, and lets you choose one to run, so now you can compile the program in your desktop machine, and run it easily on the Brick. SniffMenu is pretty primitive at the moment, but its written in Sniff, so you can make a better version!

EV3 Devices

Currently there are two EV3 specific devices: ev3lcd and ev3Keypad. There are examples of using them both in the Sniff/examples/EV3 folder. Basically ev3lcd behaves in the same way as all the other display devices. ev3Keypad mimics the Gambuino keypad. However the setBacklight uses values 0-9 to represent different patterns and colours, rather than adjusting brightness. Fortunatly 0 is off and 1 is sold green so the results work fairly consistently cross platform.

To test these there's a version of Bounce Out - our favourite game written in Sniff, running on the EV3. The only changes from the Arduino version is to comment out the Sound player, replace Arduino devices with their EV3 equivalent, and add a scale factor so that the game is sized to fill the EV3's larger screen. Things are a little hard to see on the small screen (and the "standard" 5x7 font is a bit small!), but it generally works great.

The one thing to remember if you're running from the EV3 menu (rather than telnet'ing in from your computer) is that your program needs to end, otherwise it will run forever and hang the EV3 (you can still connect by telnet, use ps to find the offending program and kill it)! There's an example in the EV3 examples folder which shows how you can make your program quit when you hold the back button for 1 second. Also remember that "say" and "ask" will only work from the telnet session.

Release Beta 9

Release B9 is a bit of a special one as it is the first version of Sniff to run on the Lego EV3. We've even changed the banner text at the top of this page to celebrate!

You can compile Sniff programs on a Mac or Linux machine, and run them on the EV3. There's also a little menu program which is written for the Lego VM(lms2012) which allows you to run installed Sniff programs directly from the EV3's onscreen controls. It's especially sweet that a big part of that is written in Sniff, so you can improve it!

There'll be a full blog post later today with a step by step explanation of working with Sniff on the EV3, including installing the onscreen menus.

The EV3 device support in this release only includes the screen and keypad/led's, but we'll be adding support for motors and sensors as soon as possible.

This release also includes the Studuino support we've previously posted about.

You can download then release here.