Virtually Free Rapsberry Pis

One of the nice things about the Raspberry Pi is that it runs Linux and you can do a lot of development right on the board. The converse of that is you can do a lot of development on a Linux desktop and then move things over to the Pi once you get the biggest bugs out. However, sometimes you really need to run code on the actual platform.

There is, however, an in-between solution that has the added benefit of upping your skills: emulate a Pi on your desktop. If you use Linux or Windows on your desktop, you can use QEMU to execute Raspberry Pi software virtually. This might be useful if you don’t have a Pi (or, at least, don’t have it with you). Or you just want to leverage your large computer to simplify development. Of course we would be delighted to see you build the Pi equivalent of the Tamagotchi Singularity but that’s a bit beyond the scope of this article.

Since I use Linux, I’m going to focus on that. If you insist on using Windows, you can find a ready-to-go project on Sourceforge. For the most part, you should find the process similar. The method I’ll talk about works on Kubuntu, but should also work on most other Debian-based systems, including Ubuntu.

Step 1. Tools

Your PC probably has some sort of Intel processor in it. The Pi has an ARM chip. QEMU is the emulator that lets you run–among other things–ARM executables on the PC. You need a static copy and the binfmt-support package. This combination will let Linux recognize alien executables and run them transparently. Here’s how you install what you need:

apt-get install qemu qemu-user-static binfmt-support

Step 2. Raspberry Pi Image

Make a working directory and download a Pi image in zip format. You can then unzip it, to create an IMG file. Here are the steps:

wget http://ift.tt/1IXxaVe

unzip 2015-11-21-raspbian-jessie.zip

Step 3. Get Data

We need a few numbers from the img file and yours may be different than mine, depending on what you downloaded. The command you want to run is:

fdisk -lu 2015-11-21-raspbian-jessie.img

Here’s the output, with the important parts in bold:

Disk 2015-11-21-raspbian-jessie.img: 3.7 GiB, 3934257152 bytes, 7684096 sectors 
Units: sectors of 1 * 512 = 512 bytes 
Sector size (logical/physical): 512 bytes / 512 bytes 
I/O size (minimum/optimal): 512 bytes / 512 bytes 
Disklabel type: dos 
Disk identifier: 0xea0e7380 
 
Device                          Boot  Start     End Sectors  Size Id Type 
2015-11-21-raspbian-jessie.img1        8192  131071  122880   60M  c W95 FAT32 (LBA) 
2015-11-21-raspbian-jessie.img2      131072 7684095 7553024  3.6G 83 Linux

The first partition is the boot partition and the second is the filesystem.

Step 4: Increase Hard Drive Size

The base filesystem isn’t very large, so let’s make it bigger:

dd if=/dev/zero bs=1M count=2048 >>2015-11-21-raspbian-jessie.img

This will add 2 GB to the image. However, the filesystem won’t know about it yet. First, we need to mount the image as though it were a set of disks:

losetup -f --show 2015-11-21-raspbian-jessie.img

losetup -f --show -o $((131072*512)) 2015-11-21-raspbian-jessie.img

The numbers (131072 and 512) must match the ones highlighted in step 3. The 512 probably won’t change, but the start of the filesystem can and does change.

Unless you already had loopback devices, this should give you a /dev/loop0 that corresponds to the whole “disk” and /dev/loop1 that is the filesystem (the part we want to expand). Recreate the partition table to know about the extra space (the mkpart command will need some numbers you can read from the output and those numbers are marked in bold):

$ sudo parted /dev/loop0
GNU Parted 3.2 
Using /dev/loop0
Welcome to GNU Parted! Type 'help' to view a list of commands. 
(parted) print                                                             
Model: Loopback device (loopback) 
Disk /dev/loop0: 6082MB 
Sector size (logical/physical): 512B/512B 
Partition Table: msdos 
Disk Flags:  
 
Number  Start   End     Size    Type     File system  Flags 
 1      4194kB  67.1MB  62.9MB  primary  fat16        lba 
 2      67.1MB  3934MB  3867MB  primary  ext4
 
(parted) print

(parted) rm 2

(parted) mkpart primary 67.1 6082

(parted) quit

$ e2fsk -f /dev/loop1
$ resize2fs /deve/loop1
$ losetup -d /dev/loop[01]

Step 5: Mount Filesystem

Make a directory to use as a mount point. I usually just make a directory called mnt in the current directory. You’ll need to be root to mount and use the offsets found in step 3 (8192 and 131072, in this case):

mkdir mnt
sudo mount 2015-11-21-raspian-jessie.img -o loop,offset=$((131072*512)),rw mnt
sudo mount 2015-11-21-raspbian-jessie.img -o loop,offset=$((8192*512)),rw mnt/boot
sudo mount --bind /dev mnt/dev
sudo mount --bind /sys mnt/sys
sudo mount --bind /proc mnt/proc
sudo mount --bind /dev/pts mnt/dev/pts

Step 6: Modify ld.so.preload and Copy Executable

As root, you need to edit mnt/etc/ld.so.preload with your favorite editor (which is, of course, emacs). You could, if you wanted to, use vi or some other editor of your choice. Just make sure you are root. Just put a hash mark (#) in front of the line you’ll find there. Failure to do this will cause illegal instruction errors to pop up later.

In addition, you need the qemu-arm-static executable available to the new fake Raspberry Pi:

sudo cp /usr/bin/qemu-arm-static mnt/usr/bin

Step 7: Chroot!

The chroot command will cause the Pi’s filesystem to look like the root directory (in one shell window). Then you can change user to pi (or any other user you want to configure):

cd mnt
sudo chroot . bin/bash
su pi

Using It

How do you know it is working? Try a uname -a command. You should see an armv7l processor type. You can run executables just like on the Pi. If you want to use X, set DISPLAY=:0 to use your main screen. For example:

DISPLAY=:0 dillo

Or you can set the display for all programs:

export DISPLAY=:0

Optional: Flash It

Now you are ready to go. After some development, you might want to save your work. All you need to do is to exit the chroot (type exit) and change /etc/ld.so/preload back (remove the # character you added). Then you should unmount everything that you mounted. The image file will remain and will contain all your changes. You can flash it, and you can reload it by repeating the chroot and mount instructions.

In Summary

There are lots of ways to do cross development on the PC for the Raspberry Pi. This is one of them. However, it also points out the power of using QEMU to run alien executables. That’s a trick you could use for lots of different development boards and platforms. There are QEMU emulators for several CPU types ranging from Microblaze to other ARM variants to PowerPC, to an S390. A quick glance at the /usr/bin directory for qemu-*-static will give you a list.

Sure, it is easy enough to get a Pi and use that. But this is yet another tool to do cross development when you need it.

Filed under: Hackaday Columns, Raspberry Pi, Skills

from raspberry pi – Hackaday http://ift.tt/1VdUjwl
via Hack a Day

Raspberry Pi Zero now with Camera Support, Still Only $5

Self-Driving Cars Get Tiny

There’s a car race going on right now, but it’s not on any sort of race track. There’s a number of companies vying to get their prototype on the road first. [Anurag] has already completed the task, however, except his car and road are functional models.

While his car isn’t quite as involved as the Google self driving car, and it doesn’t have to deal with pedestrians and other active obstacles, it does use a computer and various sensors to make decisions about how to drive. A Raspberry Pi 2 takes the wheel in this build, taking input from a Pi camera and an ultrasonic distance sensor. The Pi communicates to another computer over WiFi, where a neural network operates to make decisions about how to drive the car. It also makes decisions based on a database of pictures of the track, so it has a point of reference to go by.

The video of the car in action is worth a look. It’s not perfect, but it’s quite an accomplishment for this type of project. The possibility that self-driving car models could drive around model sets like model railroad hobbyists create is intriguing. Of course, this isn’t [Anurag]’s first lap around the block. He’s already been featured for building a car that can drive based on hand gestures. We’re looking forward to when he can collide with model busses.

Filed under: car hacks

from raspberry pi – Hackaday http://ift.tt/1TTW902
via Hack a Day

Hackaday Prize Entry: Powering A Pi From A Battery

Knocking a microcontroller into sleep mode and waking it up on demand or in intervals is common practice in many low power applications, enabling devices to stay in operation for years on a single coin cell battery. Since there are tons of applications where you might want to do similar things with a Raspberry Pi, [Patrick Van Oosterwijck] created the LiFePO4wered/Pi. The module that snaps on to eight GPIO pins of a Pi, extending it by a long life LiFePO4 battery, a charging regulator, and a proper power management. Obviously, it also makes a great UPS.

[Patrick] realized this project by expanding his already available and equally useful LiFePO4wered/USB charging regulator module by a low power MSP430G2131 microcontroller and a load switch. A daemon on the Raspberry Pi speaks to the module over I2C, allowing you to schedule a wake-up timer, let your Pi autoboot after a power outage or just read out the current battery voltage through a command line tool. Once the Pi is safely shut down, the microcontroller will also go to sleep, resulting in a standby current of 8 uA for the whole system. Together with the 500 mAh LiFePo4 cell, that’s theoretically low enough to send your Pi-ncess into a seven-year-long sleep.

LiFePO4wered/Pi is not only good for sleeping, though. [Patrick’s] runtime tests show, that the 500 mAh cell will power a Raspberry Pi Zero and a WiFi dongle for about two hours. Because the Raspberry Pi and many USB peripherals won’t complain when only 3.2 V are present on the VBUS, [Patrick] was able to squeeze out even more runtime by dismissing the boost converter from the design and driving the Pi directly from the battery voltage. If that worries you, you can either read a detailed explanation on why that works so well or just have a look at the more compliant 5 V version.

Eventually, [Patrick] used his module to create a Raspberry Pi time-lapse camera. A little script lets the Pi take a picture on boot up, set a wake-up timer and go back to sleep again. Safely enclosed in a waterproof electric box and deployed into the wild, the camera took 120 pictures on a single charge.

We’re sure the module will find it’s way into many cool projects and we’re counting the hours until we can get one in [Patrick’s] tindie store. Until then, enjoy the time-lapse video:

The HackadayPrize2016 is Sponsored by:

 

Filed under: Raspberry Pi, The Hackaday Prize

from raspberry pi – Hackaday http://ift.tt/24Qo6Bg
via Hack a Day

Minimal MQTT: Building a Broker

In this short series, we’re going to get you set up with a completely DIY home automation system using MQTT. Why? Because it’s just about the easiest thing under the sun, and it’s something that many of you out there will be able to do with material on-hand: a Raspberry Pi as a server and an ESP8266 node as a sensor client. Expanding out to something more complicated is left as an exercise to the motivated reader, or can be simply left to mission creep.

We’ll do this in four baby steps. Each one should take you only fifteen minutes and is completely self-contained. There’s a bunch more that you can learn and explore, but we’re going to get you a taste of the power with the absolute minimal hassle.

In this installment, we’re going to build a broker on a Raspberry Pi, which is the hub of your MQTT network. Next time, we’ll get an ESP8266 up and running and start logging some data. After that, we’ll do some back-end scripting in Python to make the data speak, and in the last installment, we’ll explore some of the useful frills and fancy bits. Let’s get started!

Overview

MQTT is a pub-sub, store-and-forward, IoT-enabled, machine-to-machine connectivity protocol juggernaut. As you can see, it’s fully buzzword-compliant. That doesn’t necessarily mean that it’s super complicated, though. You can read up on MQTT until you’re blue in the face. Here’s the bare minimum you need to know to be comfortable.

The network has clients (called “clients”) and servers (called “brokers”). Clients, whether it’s your temperature sensor node or the graphing application that’s going to use the data, use the broker as a central hub. Data are arranged in “topics”, which use a directory-like structure. So the temperature node in my bedroom is called “home/bedroom/temp”. When I add a light sensor to my bedroom node, I’ll set up a topic called “home/bedroom/light” and so on.

When a client gets some new data, it “publishes” it to the topic — sends the data to the server. The server then forwards the data along to all of the other clients that have “subscribed” to the topic. In my example, the bedroom node publishes to “home/bedroom/temp” and then a databasing program which is a subscriber to “home/bedroom/temp” automatically receives it. And so does any other client that’s subscribed to the topic.
Often a given physical device will subscribe to some topics and publish to others.  My heating controller will want to act on the temperature sensors, and display its status on an LED in the bedroom, for instance. There’s naturally more to say, but let’s get our broker up and running first and explore the details later.

Build a Broker

OK, “build” is a little bit overstated. We’re just going to download mosquitto, which is the most widely-used broker. If you’ve got a Raspberry Pi (or other spare computer) lying around, you’ve got an MQTT broker-in-waiting. Unfortunately, Raspbian comes with an old version of mosquitto by default, so we’ll have to do a tiny bit more typing to get the most recent version. Here’s how I set up a fully-featured MQTT broker on a brand-new Raspberry Pi (Jessie Lite):

curl -O http://ift.tt/1Jo2xYJ
sudo apt-key add mosquitto-repo.gpg.key
rm mosquitto-repo.gpg.key
cd /etc/apt/sources.list.d/
sudo curl -O http://ift.tt/20kE7aR
sudo apt-get update
sudo apt-get install mosquitto mosquitto-clients

Et voilà. Later, when we need to access the broker from the outside world, we’ll need to know the Raspberry Pi’s IP address, but that’s it. You’re up and running. If you’re using an older version of Raspbian, substitute “wheezy” for “jessie” in the fifth line. If you’re using anything other than a Raspberry Pi, you can probably find what you need, including Windows binaries, here. (I haven’t tested Windows or Mac.)

Playing Around

Now that our broker is set, let’s do some quick experiments to get a taste of how MQTT works in practice. The astute among you noticed that I also installed mosquitto-clients. Let’s try them out.

Open up a window and type mosquitto_sub -h localhost -t "test/topic". Congratulations, you’ve just subscribed a client to the “test/topic” topic. -h localhost connects you to an MQTT server on the local machine, rather than on the broader Internet. If we weren’t setting up our own server, I’d have you point to the MQTT test servers. As it is, I’ll just let you know that they’re out there when you need them.

OK, let’s publish our first data. Open up another window and type mosquitto_pub -h localhost -t "test/topic" -m "hello!" Same server, same topic, but now we’re sending a message. You should see the message pop up instantly in the subscribed window.

Try opening up multiple subscriber windows, subscribed to the same topic. You’ll see that they all get the message. Try sending messages to topics that don’t exist yet. What happens?

One last stupid MQTT trick before we get to the important stuff. MQTT can use two different types of wildcards in the topic names. So my network has “home/bedroom/temp” and “home/cellar/temp” topics. I can read all the temperatures by subscribing to “home/+/temp” and get all the values from my bedroom node from “home/bedroom/#”. (“+” matches one hierarchical level, while “#” stands for everything deeper in the tree.) Once you start using wildcards, you’ll want to know which topic is reporting, so try subscribing in verbose mode mosquitto_sub -h localhost -v -t "test/#" and send yourself some test messages to different topics.

Quality of Service

Here is MQTT’s killer feature for a low-power home automation sensor network: it’s a “store and forward” protocol with a couple levels of quality of service (QOS) guarantees. If your node has already registered with the broker and it’s offline when a new message comes in, the broker can take care of delivering that message to the node as soon as it reconnects. This means that your nodes can spend most of their lives in a deep sleep, conserving battery power, and when they do finally connect, they haven’t missed anything.

Three things are needed for the QOS feature: the subscribing clients need to be previously registered by ID with the server, and they need to disable the (default) clean-slate behavior otherwise all stored messages are erased when you log back in. Both the subscriber and the publisher need to be using quality-of-service level one or two so that the server knows it’s a stored message. (QOS level one usually suffices, but feel free to read up.)

Here’s an example:

subscriber:  
    mosquitto_sub -h localhost -v -t "test/#" -c -q 1 -i "james bond"
publisher:
    mosquitto_pub -h localhost -t "test/topic" -m "wowie" -q 1
    mosquitto_pub -h localhost -t "test/topic" -m "zowie"

To demonstrate what QOS does, run the subscriber’s command in one window and send the other two messages to it. You’ll get them both. Now stop the subscriber with ctrl-c and resend both messages. Now, when you subscribe again, you’ll only get “wowie” because it was the message sent with QOS enabled.

One gotcha with IDs is that you’ll only get whatever has happened between IDed logins. You have to be previously registered with the server so that it saves messages for you. You can’t just walk in, give it a new ID, and say “what have I missed?” because it doesn’t know you yet.

Also note that the subscriber must do three things to enable receiving messages with QOS. The ID and QOS levels are obvious. The one I always forget is to disable clean-slate logins with the -c flag. Don’t forget.

Retained Messages

If you don’t need to get the full history of messages since your node was last online, consider the “retain” flag. When messages are sent as retained, the last such message gets automatically transmitted to any client that subscribes to the topic. Retained messages are great for things like status reports. Any time that you want to log in and see just the last value without having to wait for an update, you’ll wish you had retain set. And note that retained messages and QOS aren’t exclusive — just be careful because you’ll get one message (the most recent one) delivered twice.

More??

This was just a taste of the power of having your own MQTT server running. Next, we’ll connect some small devices to the network, and then we’ll build up some back-end processing. If you’ve gotten this far and just can’t wait, try playing around with mosquitto_sub -h test.mosquitto.org -t "hackaday/new_articles" -c -q 1 -i "your_name_here". The stream is published with QOS=1 and retains the last message. Feel free to play around and show us what you build in the comments.

Filed under: Engineering, Hackaday Columns, Network Hacks, Original Art

from raspberry pi – Hackaday http://ift.tt/1XhnMWl
via Hack a Day

Raspberry Pi Balloon Goes Too High, Goes Boom, But Survives

Some people like to get high on a Wednesday afternoon. [Kevin Hubbard] of Black Mesa Labs likes to get really high. Even higher than intended: last month, he flew a helium balloon powered by a Raspberry Pi to 103,000 feet. It was only supposed to go to 90,000, but a fault in the code for the controller meant that it went higher, burst and plunged to the ground. All thanks to an extra hash mark in his code.

[Kevin] was part of a team called the Balloongineers who are competing in the Global Space Balloon Challenge, a project to simultaneously fly balloons from multiple locations. The Balloongineers entry was called HAB1, built around a Raspberry Pi, an FPGA watchdog system, a uBlox GPS and an Iridium satellite modem. The idea was that their balloon would zoom up to 90,000 feet, where it would release some helium gas, hover, and move eastwards with the prevailing winds. reporting back via satellite as it went. Unfortunately, something went wrong. The balloon didn’t report back properly, and kept on rising, eventually reaching over 100,000 feet, where it burst and fell to earth.

[Kevin] thought all was lost, including the expensive satellite modem that HAB1 used. But the next day, his balloon sent him an email, reporting that it was hale and hearty at an altitude of 300 feet. After recovery, he analyzed HAB1, and figured out what had happened: a single mistyped hash mark had caused the system to lock up when it tried to open the vent to release the gas.

What saved the rig was the foresight [Kevin] had in building it. Although the system didn’t work fully as planned, the FPGA watchdog (nicknamed the Lizard Brain) eventually noticed that the main computer was locked up, and rebooted it, enabling the system to report back to [Kevin]. An additional recovery mode woke the system once an hour sent a location and went back to sleep, which allowed the small battery to keep powering the system until it could get a signal out the morning after. That’s a smart piece of design in a system that allowed them to recover the hardware, even though the main objective of hovering at 90,000 feet wasn’t achieved.

[Kevin] ends his writeup of the flight with a few notes that any engineer would be wise to consider. Primary among these is his decision to have the system check very rarely for manual overrides over the satellite connection. He decided to do this to save money: checking for messages on Iridium costs a certain amount each time you do it. If he had checked more frequently, he might have been able to fix the problem earlier by venting the helium manually, leading to a more controlled descent and recovery. In any project, a failure can only be useful if you can figure out what the problem was, gathering as much information as possible to help you avoid it next time.

Filed under: Raspberry Pi

from raspberry pi – Hackaday http://ift.tt/273UZZM
via Hack a Day

Chess Computers Improve Since 90s

The AlphaGo computer has been in the news recently for beating the top Go player in the world in four out of five games. This evolution in computing is a giant leap from the 90s when computers were still struggling to beat humans at chess. The landscape has indeed changed, as [Folkert] shows us with his chess computer based on a Raspberry Pi 3 and (by his own admission) too many LEDs.

The entire build is housed inside a chess board with real pieces (presumably to aid the human player) and an LED on every square. When the human makes a move, he or she inputs it into the computer via a small touch screen display. After that, the computer makes a move, indicated by lighting up the LEDs on the board and printing the move on the display. The Raspberry Pi is running the embla chess program, which has an Elo strength of about 1600.

While the computer isn’t quite powerful enough to beat Magnus Carlsen, we can only imagine how much better computers will be in the future. After all, this credit-card sized computer is doing what supercomputers did only a few decades ago. With enough Raspberry Pis, you might even be able to beat a grandmaster with your chess computer. Computer power aside, think of the advancements in fabrication technology (and access to it) which would have made this mechanical build a wonder back in the 90s too.

 

Filed under: Raspberry Pi

from raspberry pi – Hackaday http://ift.tt/1WQ9WtH
via Hack a Day