Akros Labs and ASG
THE FIXER’S MANIFESTO
From the inventors of Sugru
1. IF IT'S BROKEN, FIX IT! BECAUSE EVERYDAY PRACTICAL PROBLEM
SOLVING IS THE MOST BEAUTIFUL FORM OF CREATIVITY THERE IS.
2. IF IT'S NOT BROKEN, IMPROVE IT. A SMALL, CLEVER TWEAK CAN
IMPROVE HOW SOMETHING WORKS FOR YEARS TO COME.
3. GIVE YOUR PRODUCTS A LONGER LIFE. IF WE DOUBLE THE LIFE OF OUR STUFF, WE HALVE WHAT GOES TO LANDFILL.
4. FIXING MEANS FREEDOM AND INDEPENDENCE. AS A FIXER, YOU DON'T NEED TO WORRY ABOUT WEAR AND TEAR. NOTHING STAYS NEW, SO FORGET PERFECTION.
5. RESIST TRENDS AND NEEDLESS UPGRADES. THEY FUEL OUR THROWAWAY CULTURE.
6. DON’T LET COMPANIES TREAT YOU AS A PASSIVE CONSUMER. EVERY TIME WE SPEND MONEY, WE VOTE FOR THE KINDS OF PRODUCTS WE WANT TO SEE SUCCEED. BUY PRODUCTS THAT CAN BE REPAIRED.
7. A FIXED THING IS A BEAUTIFUL THING.EVERY FIX, WHETHER SKILLFUL OR IMPROVISED, HOLDS A STORY.
8. IF YOU HAVE AN IDEA, START SMALL AND MAKE IT GOOD. IF IT’S RIGHT, IT'LL GROW FROM THERE.
9. NURTURE YOUR CURIOSITY. KEEP TRYING THINGS YOU'VE NEVER TRIED BEFORE. IT'S GOOD FOR YOUR BRAIN AND YOUR SOUL. DON'T BE AFRAID TO FAIL
— IT MAKES SUCCESS ALL THE SWEETER.
10. PEOPLE ARE INFINITELY DIVERSE. PRODUCTS SHOULD BE TOO. EVERYTHING CAN BE IMPROVED OR CUSTOMIZED.
11. DISPOSABILITY IS A CHOICE, NOT A PHYSICAL CHARACTERISTIC. PLASTICS AREN'T EVIL, BUT WE'RE USING THEM WRONG. TREAT THEM WITH RESPECT.
12. SHARE YOUR IDEAS, YOUR ENTHUSIASM AND YOUR SKILLS. IF YOU'VE FOUND THE JOY OF FIXING, PASS IT ON. IT'S A GIFT FOR LIFE.
Selfstarter an alternative to Kickstarter
Rejected by Kickstarter? 'Roll your own' with Selfstarter instead
by Katherine Noyes via PC World
There's been no shortage of controversy surrounding Kickstarter this year as the crowdfunding platform has gained popularity, prompting the institution of new rules and belt-tightening measures in recent months.
Now, however, there's a brand-new alternative: Meet Selfstarter, an open source platform that lets anyone “roll their own” crowdfunding effort by simply forking its code.
“Hardware startups are less welcome on Kickstarter than they were six months ago,” explains the Selfstarter project. “We needed to roll our own Kickstarter, so we did. Other hardware startups probably will too, so we made it easier for them by open sourcing our way of doing it.”
$1 million and counting
As pointed out in a Friday story on The H, Selfstarter was actually launched by the creators of Lockitron, a keyless entry system that's operated via mobile app. Lockitron itself was rejected by Kickstarter recently, inspiring its creators to make their own crowdfunding site and hope for the best.
Though Lockitron's funding goal was just $150,000, it surpassed $1 million in preorders within just a few days. As of today, it is approaching $2 million in funding.
Now, the technology that made Lockitron's success possible is available to anyone with a product idea of their own.
Set up for Amazon Payments
Selfstarter's code is available for anyone's use on GitHub along with instructions for getting started. By downloading the code, users get a rudimentary site to which they can add their own authentication, administration, and product management code.
Based on Ruby on Rails, the software delivers a site just like what Lockitron used, and it comes set up to collect reservations using Amazon Payments--users need only create an Amazon Seller Central account. They can, however, choose a different provider instead. Selfstarter recommends Stripe or WePay as good alternatives.
Perhaps best of all, Selfstarter is free to use and can be customized to your heart's content.
Have a great product idea? Rather than jump immediately to Kickstarter--or even Crowdtilt, another alternative that launched earlier this year--it might be worth taking a moment to check Selfstarter out.
A soldiers new atomic clock
via Defensetech.org
Military.com is running an an item that reports that the U.S. Army has begun the final phase for manufacturing a microchip-sized prototype that will support efforts to provide highly accurate location and battlefield situational awareness for the dismounted soldier, even in the temporary absence of GPS capability.
The goal is to provide complete atomic clock capabilities for weapons, weapon systems and the dismounted Soldier, and to do this with low power and drastically reduced cost, noted John Del Colliano, chief for the Positioning, Navigation and Timing branch of CERDEC’s Command, Power & Integration directorate.
“An atomic clock, which is recognized for its accuracy, is used by the military in larger systems; however, the typical atomic clock is large, heavy and requires lots of power. Large systems/platforms like bombers have the advantage of having more power and space to accommodate a full-scale atomic clock, but that’s not true for a Soldier on the battlefield or for munitions being fired,” Del Colliano said.
The chip-scale atomic clock or “CSAC,” which is approximately 15 cubic centimeters, could be integrated into a platform, weapon or a device worn by a soldier and will be completely transparent to the user, said Paul M. Olson, acting associate director, Systems Engineering, for CERDEC CP&I.
“The CSAC is a critical tool for systems that require very accurate time synchronization, such as communication, navigation, radar and weapon systems. When used in conjunction with other sensors, the CSAC can help these systems provide highly accurate location and battlefield SA to units and commanders,” Olson said. “If GPS is disrupted or jammed, a CSAC could provide precise time to the GPS receiver to enable rapid recovery or to protect receivers from GPS spoofing, a condition where false GPS signals are broadcast to fool GPS receivers with erroneous information. The hope is that the Soldier wouldn’t even know that his GPS is being jammed.”
Raspberry Pi serial console
by Drew Fustini via Element 14 Community Blog
The serial console is a convenient way to interact with the Raspberry Pi when a display isn't handy. From the pinout on the eLinux wiki, I can see that the serial port (aka UART) on the Pi is on GPIO Pin 14 (TX) and GPIO Pin 15 (RX):
This serial port can be connected to your computer via a USB to serial adapter. However, these pins are designed for 3.3V (e.g. 3V3), so some USB to serial adapters may damage the Pi. The simplest option is to use a 3.3V adapter such as:
The serial console is a convenient way to interact with the Raspberry Pi when a display isn't handy. From the pinout on the eLinux wiki, I can see that the serial port (aka UART) on the Pi is on GPIO Pin 14 (TX) and GPIO Pin 15 (RX):
This serial port can be connected to your computer via a USB to serial adapter. However, these pins are designed for 3.3V (e.g. 3V3), so some USB to serial adapters may damage the Pi. The simplest option is to use a 3.3V adapter such as:
FTDI TTL-232R-3V3 cable
SparkFun 3.3V Basic FTDI Breakout board
Another option is to use a logic level converter (e.g. level shifter). This will prevent a higher voltage adapter from damaging the Pi's 3.3V pins. I already had a 5V FTDI cable (TTL-232R-5V) and a SparkFun converter board, so I went this route:
Here is the pinout for my TTL-232R-5V cable (datasheet):
Note: TXD (transmit) on the Pi needs to talk to RXD (receive) on FTDI cable, and TXD on the FTDI needs to talk to RXD on the Pi. Otherwise, it would just be a straight-through connection, and communication wouldn't be possible.
Once wired up, power on the Pi and plug the FTDI cable into the PC. Finally, a terminal emulator application will be needed to connect to the Pi. I run Ubuntu Linux and already had gtkterminstalled. The program screen is another option for Linux and Mac (OS X). On Windows, HyperTerm or TeraTerm should work. The eLinux wiki has additional information.In gtkterm, I selected Configuration->Port and set the Port to /dev/ttyUSB0 and Baud to 115200. The rest of the defaults are ok (8 bits, stopbits 1, flow control and parity: none). After clicking OK, I pressed the Enter key a few times and the Pi prompted for username. I was able to log in and then use the shell as I normally would. Here is the utility top running:
Finally, FTDI has created a cable specifically for the Raspberry Pi: TTL-232R-RPi. It is available from the UK-based FTDI web shop, but I've not seen it stocked yet by any distributors I'm familiar with.
Procastination an animated explanation
The Science of Procrastination and How to Manage It, Animated
by Maria Popova via BrainPickings
This is where you insert the meta-joke about what else you’re actually supposed to be doing this very moment.
From AsapSCIENCE — who have previously brought us the scientific cure for hangovers, the neurobiology of orgasms, and how music enchants the brain — comes this illustrated explication of the science of procrastination and how to manage it, a fine addition to these five perspectives on procrastination. Among the proposed solutions is the Pomodoro technique, a time-management method similar to timeboxing that uses timed intervals of work and reward.
OHS2012 Keynote comments
via Adafruit
The Open Hardware Summit opens with a keynote talk by Chris Anderson, editor of Wired magazine, who is himself the head of an Open Hardware company as well as a writer and thinker about the movement. He encourages those gathered to look to the next stage of evolving the Open Hardware movement, and avoid doctrinarian fighting over the notion of what Open Hardware might be. He explores what it means to have an Open Hardware business model, in practical terms.
Special shout-out to Adafruit for being involved in identifying, early on, the 2.6x BOM multiplier that has guided how the DIY world prices products.
Keep ahead of donors by innovating faster, supporting better. You can clone us but you can’t clone the community. Community beats cloning every time.
And an interesting rule of thumb for how DIY manufacturers might behave vs large industrial manufacturers.
“90-10″ Rule: 90% the performance of commercial options at 10% of the cost.
Particularly exciting to me was his Hierarchy of Reward pyramid, that points out the rewards his Open Hardware company is able to provide to give contributors something valuable to them without raising cost of products.
He also addresses the MakerBot question and cautions that we shouldn’t be dogmatic about Open Hardware but instead reward the mix of strategies that works, builds a sustainable business, and provides the community what it needs. He argues that Open Hardware business practices will be embraced because they work and make solid business sense.
His list of the seven limitations of OSH Limitations:
1. Cloning is Unstoppable.
2. Investors Aren’t Sure. (Want to see the barriers to commercial copying. His recommendation to consider: Open Software, Closed Hardware.)
3. It’s Hard to Keep Up.
4. It Doesn’t Extend Much Beyond Electronics and Lasercut Materials.
5. It Can Confuse the Marketplace.
6. It Tends to Drive Prices Down, Punishing Innovators Most.
7. Unlike Software, Mechanisms for “Giving Back” Are Not in Place. (Think GitHub for hardware.)
The Open Hardware Summit opens with a keynote talk by Chris Anderson, editor of Wired magazine, who is himself the head of an Open Hardware company as well as a writer and thinker about the movement. He encourages those gathered to look to the next stage of evolving the Open Hardware movement, and avoid doctrinarian fighting over the notion of what Open Hardware might be. He explores what it means to have an Open Hardware business model, in practical terms.
Special shout-out to Adafruit for being involved in identifying, early on, the 2.6x BOM multiplier that has guided how the DIY world prices products.
Keep ahead of donors by innovating faster, supporting better. You can clone us but you can’t clone the community. Community beats cloning every time.
And an interesting rule of thumb for how DIY manufacturers might behave vs large industrial manufacturers.
“90-10″ Rule: 90% the performance of commercial options at 10% of the cost.
Particularly exciting to me was his Hierarchy of Reward pyramid, that points out the rewards his Open Hardware company is able to provide to give contributors something valuable to them without raising cost of products.
He also addresses the MakerBot question and cautions that we shouldn’t be dogmatic about Open Hardware but instead reward the mix of strategies that works, builds a sustainable business, and provides the community what it needs. He argues that Open Hardware business practices will be embraced because they work and make solid business sense.
His list of the seven limitations of OSH Limitations:
1. Cloning is Unstoppable.
2. Investors Aren’t Sure. (Want to see the barriers to commercial copying. His recommendation to consider: Open Software, Closed Hardware.)
3. It’s Hard to Keep Up.
4. It Doesn’t Extend Much Beyond Electronics and Lasercut Materials.
5. It Can Confuse the Marketplace.
6. It Tends to Drive Prices Down, Punishing Innovators Most.
7. Unlike Software, Mechanisms for “Giving Back” Are Not in Place. (Think GitHub for hardware.)
‘Sell Out a Little to Sell a Lot’:Raspberry Pi’s Secret
by Pete Lomas via Wired Magazine, opinion column
“A raspberry ‘pie’?” “You want to build HOW few and sell them for WHAT price?” We had always wanted to build Raspberry Pi in the U.K., but early conversations suggested this was a vain hope. The Foundation had zero credibility in the manufacturing arena, our price point meant margins were way under acceptable levels for contract manufacturers, and volumes were simply too low.
The original plan was to build just 1000 units for new undergraduates at Cambridge University. We figured we could kickstart that ourselves: if we sold each at $35 and it cost $36 to make, well, we would lose $1000. That was worth it, we thought, to engage with keen early adopters who would help us with the debugging, documentation, and education.
We desperately needed a sustainable model. As a U.K.-registered charity, we could not fund demand by normal loan methods. Nor could we rely on our own money to subsidize production at a level over 200 times what we had initially expected. The Foundation was already running on donations by the trustees, some of whom had remortgaged their own houses to provide funds.But instead, our small, part-time only team was faced with a success disaster. Just three weeks before launch, initial demand was well beyond 200,000 units. And at one point on launch day we were even trendier than Lady Gaga.
What we learned is that you have to sell out (a little) to sell (a lot). I’d argue that many makers have to do this when they want to scale. Going from 0 to 1 million units projected in just our first year meant we had to make a number of tradeoffs – from where to manufacture and how to work with partners without alienating our core community, to what features we chose (or didn’t choose) for the Raspberry Pi in the first place.
Manufacturing: You Can’t Have Your Pie and Eat It Too
We had set the target prices at $25 and $35 for Raspberry Pi before we had finalized our design. Sure, we had a prototype, but we had to hone it because manufacturing has a range of tradeoffs that overlap with the design choices.
Ideally, you want to frame manufacturing volume at the outset so the most appropriate technology can be linked with the appropriate manufacturing processes. High volumes mean efficient processes and discounts on components, resulting in tantalisingly low manufacturing costs. Low volume processes recognize the difficulty of not being able to spread out costs – but they replace specialized capital equipment with higher labor costs instead.
Yet we always believed it was possible to manufacture the Pi in the U.K., where labor costs for electronics assembly at the printed circuit board (PCB) level are low enough as long as we sourced the components internationally and reached sufficiently large volumes.Raspberry Pi needed a modest volume and a minimal cost point. The charitable model helped us negotiate component pricing not normally available to a small business, but the only way we could realistically get both was by priming the pump in China, supported by personal loans. So we negotiated with a Shenzhen-based contract electronic manufacturer to build the initial 10,000 to 20,000 units.
Enter the partners. Premier Farnell and RS/Allied had the buying power to keep component prices low, the global presence to handle the logistics, and the financial muscle to make it all happen immediately. And when we wanted to come back to the U.K., Sony’s Technology Center in Wales could handle the technical package-on-package assembly.
So partnering would be the shortest route to getting Raspberry Pi into our community’s hands as quickly as possible. It also meant we could help create 30 new manufacturing jobs in the U.K.
But it meant we were faced with a dilemma. How could we enable hacking while preventing cloning?
Holding back the schematics altogether troubled us. Not being open would impede people’s ability to interface and hack the hardware – defeating the very goals we had set out to accomplish with Raspberry Pi in the first place. Because our remit is education in the broadest sense, we wanted – needed – to provide completely open access to the hardware. And we didn’t want to alienate the devoted hacking and open source community that had fueled early interest and would provide much of the future development.
Well, you don’t get owt for nowt as they say in North England – you don’t get something for nothing. So we decided to publish the schematics, but hold back the detailed Bill of Materials (BOM) and physical PCB design or “Gerbers“ for a limited amount of time. After all, hardware is just one part of our overall plans. The schematics alone don’t provide enough information to clone the Pi without expending considerable effort re-laying the PCB and figuring out the exact part used in each location.But if other manufacturers copied the design, our partners would lose their investment, which was approaching several million dollars. They were spending this time and money optimizing their processes for manufacturing and distributing our product, while exploring component alternatives to meet the aggressive cost targets. Those component choices weren’t arbitrary: we had to get the selection and underlying layout just right because earlier Pis had failed when the amount of supporting electronics overburdened the design and inevitably the cost.
But if you want to hook up other electronics, the schematics are a great help. Especially since hooking up other stuff to the Pi – whether you’re inside or outside the classroom – is the whole point. How else would a whole new generation grow up actively building with computers, instead of just passively playing on them?
Design: Yes, You Can Have Your Pie and Eat It Too
“Houston, we have a problem.” Well, we never said that (apparently the Apollo 13 astronauts never did, either), but the power-sequence scene in the Apollo 13 movie really captures the final design process for us. The guys on the ground are constrained by time, power, and only materials available in space; they’re frantically adding some essential function and then having to cut something else; they’re trying to keep it all under weight. The Raspberry Pi team wasn’t constrained by time, but as interest grew it certainly felt like it. And we had plenty of other constraints.
While we agreed on the vision of educating the next generation of programmers and engineers, we disagreed on the best way to get there. We all came from different backgrounds – hardware, software, ICT, electronics, hacking, academia, you name it – and with those different perspectives, we were holed up in a room for hours trying to decide what design tradeoffs to make.Price was critical. The financial risks of over-enthusiastically hacking and accidentally breaking the Pi had to be acceptable. But even though it was supposed to be a bare-bones computer, the Pi had to be fully functional and sufficiently powerful. In a world of iThis and X-that, an 800 x 480 display and 8-bit processor just weren’t going to cut it.
Here’s how we decided what to include and exclude. I think we would have gotten it very wrong if we had left some things off. And even after all that, we still encountered a really low point when we realized we might not be able to manufacture the design we ended up with….
Form factor. Someone threw out that the single-board computer should be “as big as a credit card”. Being an engineer, I took this literally. Turns out credit cards are perfect for multiple Lego bricks (which has led to some inventive case and stack designs). More importantly, this also saves on expensive laminate.
Processing. We had to have enough processing power to run Linux, supporting Python, Scratch, and other educational software. A 700MHz ARM CPU provided just enough power; any more would impact the BOM cost. For application processing, we went with the Broadcom BC2835 chip. This ended up hardening up a lot of the other specifications (specs) for us, because the chip defines the ultimate architecture.
Memory. The hardware guys in the room thought 128MB would be enough for bare metal programming. But the Linux software demanded more: 256MB. We figured this was enough to get people going, and thanks to Moore’s Law, the same budget would get us more RAM in a couple of years. For non-volatile memory, we had an SD card reader (the Pi has no memory otherwise), and of course, that would also allow for exchangeable environments.
Multimedia. A key consideration here, as with the other specs, was keeping the Pi geographically inclusive. Many regions of the world cannot access or afford HDMI, so we needed a less expensive way to get video and audio: composite and PWM. Meanwhile, digital cameras everywhere meant the Pi needed to support high-resolution graphics while remaining relatively low-power, and the VideoCore IV GPU gave us those capabilities.
Connectivity. Surprisingly, this was the biggest source of debate: How important was it to have internet connectivity? Turns out, it’s absolutely key: Without it, you can’t connect to the XBMC open source media player or get version updates via GitHub. So the $35 Pi had to include Ethernet, and USB ports would be used for all the basic peripherals.
I/O. But perhaps the most important feature of all was providing access to the General Purpose Input/Output (GPIO). The GPIO was key to unlocking the hardware so successfully developed in the Arduino ecosystem: The stuff people could add to and embed with the Raspberry Pi. The GPIO also meant features that ended up on the cutting room floor could be added back by our
ever-inventive community.
ever-inventive community.
Without all of these specs, a hardware community could not grow around the Raspberry Pi. The pieces of the Pi finally seemed to fit together just perfectly.
The problem? We couldn’t manufacture it anywhere near our target cost. It turned out that there was a looming problem routing the PCB to accommodate the design.
And while there are special high-density interconnect (HDI) techniques for densely layered PCBs, those would just reduce yield and increase processing steps not to mention the costs. We panicked when we realized we might have to increase prices to accommodate the HDI technology.This wasn’t just a minor technical detail: The solution to the problem meant our budget would be well and truly blown. The core of the design involves wiring up all the peripheral connectors, support chips, and five power supplies – most of which have to fit under the processor. But we had 253 connections to bring out (the BGA escape) in an area much smaller than the size of a dime.
But failure was not an option – we simply had to find a way.
After much fiddling with all the possible variables, and a few frantic calls to our PCB manufacturers, we had our Eureka moment. What if we could steal the idea of “blind micro vias” from high-density interconnects, but apply it cheaply enough for the Pi design?
Instead of going through all the PCB layers, we made human-hair sized holes (micro vias) that go through only the first couple of layers (blind) – saving just enough space on the other layers for wiring up the other PCB components. At high volumes, these holes could be made quickly and efficiently with a laser. And it only cost a few cents extra. Making these tradeoffs resulted in a relatively simple six-layer board that didn’t compromise power distribution. And it enabled manufacturing at scale.
Raspberry Pi has been a project seven years in the making. It’s often felt like the closer we got to our goals, the further away they seemed. But we’re having the time of our lives. We’ve only been selling for six months, and we’ve sold around half a million units already. Universities are giving Pis to their freshmen as a gift on arrival; 7-year-old kids are sending us videos of their adventures writing Scratch games.
So in the end, I guess you can have the hard and soft little bits of everything.
Concepts behind an IMU
via Hackaday
Anilm3 wrote in to Hackaday to share the IMU tutorial series he is working on. He previously used some all-in-one IMU devices in school which did most of the work for him. But he wanted to grind down and look at what each sensor spits out and how those measurements are used. The first installment deals with the accelerometer, using its data to calculate pitch and roll. For these demonstrations Anilm3 is using this ADXL345 sensor board, an Arduino, and some processing sketches for testing.
Whenever working with sensors you need to take noise into consideration. The post shows how to implement a low-pass filter in the code which will help smooth out the readings. The filtered data is then fed to a couple of mostly-painless formulas which calculate the movement of the accelerometer in degrees. The demonstration sketch is mapped to a 3D cube to give you an idea of how accurate the accelerometer is. There’s a little bit of lag which would let a self-balancing robot have a nasty fall. The solution to this issue will be discussed in upcoming parts of the series. The next installment tackles the gyroscope sensor.
Raspberry Pi Supercomputer how to
by Simon Cox via University of Southamton (UK),Computational Engineering and Design Research Group
First steps to get machine up
1. Get image from
I used: 2012-08-16-wheezy-raspbian.zip
2. Use win32 disk imager to put image onto an SD Card (or on a Mac e.g. Disk Utility/ dd)
You will use the “Write” option to put the image from the disk to your card
3. Boot on Pi
4. Expand image to fill card using the option on screen when you first boot. If you don’t do this on first boot, then you need to use
$ sudo raspi-config
5. Log in and change the password
$ passwd
6. Log out and check that you typed it all OK (!)
$ exit
7. Log back in again with your new password
Building MPI so we can run code on multiple nodes
8. Refresh your list of packages in your cache
$ sudo apt-get update
9. Just doing this out of habit, but note not doing any more than just getting the list (upgrade is via “sudo apt-get upgrade”).
10. Get Fortran… after all what is scientific programming without Fortran being a possibility?
$ sudo apt-get install gfortran
11. Read about MPI on the Pi. This is an excellent post to read just to show you are going to make it by the end, but don’t type or get anything just yet- we are going to build everything ourselves:
Note there are a few things to note here
a) Since we put Fortran in we are good to go without excluding anything
b) The packages here are for armel and we need armhf in this case… so we are going to build MPI ourselves
12. Read a bit more before you begin:
We are going to follow the steps from 2.2 in this guide.
13. Make a directory to put the sources in
$ mkdir /home/pi/mpich2
$ cd ~/mpich2
14. Get MPI sources from Argonne.
$ wget http://www.mcs.anl.gov/research/projects/mpich2/downloads/tarballs/1.4.1p1/mpich2-1.4.1p1.tar.gz
15. Unpack them.
$ tar xfz mpich2-1.4.1p1.tar.gz
16. Make yourself a place to put the compiled stuff – this will also make it easier to figure out what you have put in new on your system. Also you may end up building this a few times…
$ sudo mkdir /home/rpimpi/
$ sudo mkdir /home/rpimpi/mpich2-install
[I just chose the “rpimpi” to replace the “you” in the Argonne guide and I did the directory creation in two steps]
17. Make a build directory (so we keep the source directory clean of build things)
mkdir /home/pi/mpich_build
18. Change to the BUILD directory
$ cd /home/pi/mpich_build
19. Now we are going to configure the build
$ sudo /home/pi/mpich2/mpich2-1.4.1p1/configure -prefix=/home/rpimpi/mpich2-install
Make a cup of tea
20. Make the files
$ sudo make
Make another cup of tea
21. Install the files
$ sudo make install
Make another cup of tea – it will finish…
22. Add the place that you put the install to your path
$ export PATH=$PATH:/home/rpimpi/mpich2-install/bin
Note to permanently put this on the path you will need to edit .profile
$nano ~/.profile
… and add at the bottom these two lines:
# Add MPI to path
PATH="$PATH:/home/rpimpi/mpich2-install/bin"
23. Check whether things did install or not
$ which mpicc
$ which mpiexec
24. Change directory back to home and create somewhere to do your tests
$ cd ~
$ mkdir mpi_testing
$ cd mpi_testing
25. Now we can test whether MPI works for you on a single node
mpiexec -f machinefile -n <number> hostname
where machinefile contains a list of IP addresses (in this case just one) for the machines
a) Get your IP address
$ ifconfig
b) Put this into a single file called machinefile
26. $ nano machinefile
Add this line:
192.168.1.161
[or whatever your IP address was]
27. If you use
$ mpiexec -f machinefile –n 1 hostname
Output is:
raspberrypi
28. Now to run a little C code. In the examples subdirectory of where you built MPI is the famous CPI example. You will now use MPI on your Pi to calculate Pi:
$ cd /home/pi/mpi_testing
$ mpiexec -f machinefile -n 2 ~/mpich_build/examples/cpi
Output is
Process 0 of 2 is on raspberrypi
Process 1 of 2 is on raspberrypi
pi is approximately 3.1415926544231318, Error is 0.0000000008333387
Celebrate if you get this far.
Flash me… once
29. We now have a master copy of the main node of the machine with all of the installed files for MPI in a single place. We now want to clone this card.
30. Shutdown your Pi very carefully
$ sudo poweroff
Remove the SD Card and pop it back into your SD Card writer on your PC/ other device. Use Win32 disk imager (or on a Mac e.g. Disk Utility/ dd) to put the image FROM your SD Card back TO your PC:
You will use the “Read” option to put the image from the disk to your card
Let us call the image “2012-08-16-wheezy-raspbian_backup_mpi_master.img”
31. Eject the card and put a fresh card into your PC/other device. Use win32 disk imager to put image onto an SD Card (or on a Mac e.g. Disk Utility/ dd)
You will use the “Write” option to put the image from the disk to your card and choose the “2012-08-16-wheezy-raspbian_backup_mpi_master.img” image you just created.
[Note that there are probably more efficient ways of doing this – in particular maybe avoid expanding the filesystem in step 4 of the first section.]
32. Put the card into your second Pi and boot this. You should now have two Raspberry Pis on. Unless otherwise stated, all the commands below are typed from the Master Pi that you built first.
Using SSH instead of password login between the Pis
33. Sort out RSA to allow quick log in. This is the best thing to read:
In summary (working on the MASTER Pi node)
$ cd ~
$ ssh-keygen -t rsa –C “raspberrypi@raspberrypi”
This set a default location of /home/pi/.ssh/id_rsa to store the key
Enter a passphrase e.g. “myfirstpicluster”. If you leave this blank (not such good security) then no further typing of passphrases is needed.
$ cat ~/.ssh/id_rsa.pub | ssh pi@192.168.1.162 "cat >> .ssh/authorized_keys"
34. If you now log into your other Pi and do
$ ls –al ~/.ssh
You should see a file called “authorized_keys” – this is your ticket to ‘no login heaven’ on the nodes
35. Now let us add the new Pi to the machinefile. (Log into it and get its IP address, as above)
Working on the Master Raspberry Pi (the first one you built):
$ nano machinefile
Make it read
192.168.1.161
192.168.1.162
[or whatever the two IP addresses you have for the machines are]
$ cd /home/pi/mpi_testing
$ mpiexec -f machinefile -n 2 ~/mpich_build/examples/cpi
Output is
Process 0 of 2 is on raspberrypi
Process 1 of 2 is on raspberrypi
pi is approximately 3.1415926544231318, Error is 0.0000000008333387
If you repeat this a second time you won’t need to type any passwords in. Hurray.
Note that we have NOT changed the hostnames yet (so yes, the above IS running on the two machines, but they both have the same hostname at the moment).
37. If you change the hostname on your second machine (see Appendix 1 “Hostname Script”) and run:
$ mpiexec -f machinefile -n 2 ~/mpich_build/examples/cpi
Output:
Process 0 of 2 is on raspberrypi
Process 1 of 2 is on iridispi002
Now you can see each process running on the separate nodes.
CONGRATULATIONS - YOU HAVE NOW FINISHED BUILDING 2-NODE SUPERCOMPUTER
IF YOU FOLLOW THE STEPS BELOW, YOU CAN EXPAND THIS TO 64 (or more) nodes
Acknowledgements
Thanks to all of the authors of the posts linked to in this guide. Thanks to the team in the lab: Richard Boardman, Steven Johnston, Gereon Kaiping, Neil O’Brien, and Mark Scott. Also to Oz Parchment and Andy Everett (iSolutions). Thanks to Pavittar Bassi in Finance, who made all the orders for equipment happen so efficiently. And, of course, Professor Cox’s son James who provided specialist support on Lego and system testing.
Appendix 1 – Scripts and other things to do
Flash me… one more time (rinse and repeat for each additional node)
1. Power off the worker Pi and eject the card
$ sudo poweroff
We now have a copy of the WORKER nodes of the machine with all of the installed files for MPI in a single place. We now want to clone this card- as it has the ssh key on it in the right place. Shutdown your Pi very carefully
$ sudo poweroff
2. Remove the SD Card and pop it back into your SD Card writer on your PC/ other device. Use Win32 disk imager (or on a Mac e.g. Disk Utility/ dd) to put the image FROM your SD Card back to your PC:
You will use the “Read” option to put the image from the disk to your card
Let us call the image “2012-08-16-wheezy-raspbian_backup_mpi_worker.img”
3. Eject the card and put a fresh card into the machine. Use win32 disk imager to put image onto an SD Card (or on a Mac e.g. Disk Utility/ dd)
You will use the “Write” option to put the image from the disk to your card and choose the “2012-08-16-wheezy-raspbian_backup_mpi_master.img” image you just created.
[Note that there are probably more efficient ways of doing this – in particular maybe avoid expanding the filesystem in step 4 of the first section.]
Hostname Script
If you want to rename each machine, you can do it from the Master node using:
ssh pi@192.168.1.162 'sudo echo "iridispi002" | sudo tee /etc/hostname'
ssh pi@192.168.1.163 'sudo echo "iridispi003" | sudo tee /etc/hostname'
ssh pi@192.168.1.164 'sudo echo "iridispi004" | sudo tee /etc/hostname'
etc.
You should then reboot each worker node
If you re-run step (36) above again, you will get:
$ mpiexec -f machinefile -n 2 ~/mpich_build/examples/cpi
Output:
Process 0 of 2 is on raspberrypi
Process 1 of 2 is on iridispi002
pi is approximately 3.1415926544231318, Error is 0.0000000008333387
This shows the master node still called raspberrypi and the first worker called iridispi002
Using Python
There are various Python bindings for MPI. This guide just aims to show how to get ONE of them working.
$ sudo apt-get install python-mpi4py
$ cd ~
$ mkdir mpi4py
$ cd mpi4py
$ tar xfz mpi4py-1.3.tar.gz
$ cd mpi4py-1.3/demo
3. Repeat steps 1 and 2 on each of your other nodes (we did not bake this into the system image)
4. Run an example (on your master node)
$ mpirun.openmpi -np 2 -machinefile /home/pi/mpi_testing/machinefile python helloworld.py
Output is:
Hello, World! I am process 0 of 2 on raspberrypi.
Hello, World! I am process 1 of 2 on iridispi002.
5. $ mpiexec.openmpi -n 4 -machinefile /home/pi/mpi_testing/machinefile python helloworld.py
Output is:
Hello, World! I am process 2 of 4 on raspberrypi.
Hello, World! I am process 3 of 4 on iridispi002.
Hello, World! I am process 1 of 4 on iridispi002.
Hello, World! I am process 0 of 4 on raspberrypi.
6. These are handy to remove things if your attempts to get mpi4py don’t quite pan out
$ sudo apt-get install python-mpi4py
$ sudo apt-get autoremove
Keygen script commands
cat ~/.ssh/id_rsa.pub | ssh pi@192.168.1.161 "cat >> .ssh/authorized_keys"
cat ~/.ssh/id_rsa.pub | ssh pi@192.168.1.162 "cat >> .ssh/authorized_keys"
cat ~/.ssh/id_rsa.pub | ssh pi@192.168.1.163 "cat >> .ssh/authorized_keys"
etc. for sending out the key exchanges if you want to do this again having generated a new key
Getting Pip for Raspberry Pi
1. We can install Pip, which gives us a nice way to set up Python packages (and uninstall them too). More info is at
$ cd ~
$ mkdir pip_testing
$ cd pip_testing
2. A prerequisite for pip is “distribute” so let’s get that first and then install pip. The sudo is because the installation of these has to run as root.
$ curl http://python-distribute.org/distribute_setup.py | sudo python
$ curl https://raw.github.com/pypa/pip/master/contrib/get-pip.py | sudo python
Notes on making MPI Shared Libraries for Raspberry Pi
MPI libraries can also be built “shared” so that they can be dynamically loaded. This gives a library file that ends in “.so” etc. not “.a” and we can do that by building those MPI libraries again. This is a repeat of steps above, but written out again using the suffix “_shared” on the directory names.
1. Make a directory to put the sources in
$ mkdir /home/pi/mpich2_shared
$ cd ~/mpich2_shared
2. Get MPI sources from Argonne.
$ wget http://www.mcs.anl.gov/research/projects/mpich2/downloads/tarballs/1.4.1p1/mpich2-1.4.1p1.tar.gz
3. Unpack them.
$ tar xfz mpich2-1.4.1p1.tar.gz
4. Make yourself a place to put the compiled stuff – this will also make it easier to figure out what you have put in new on your system.
$ sudo mkdir /home/rpimpi_shared/
$ sudo mkdir /home/rpimpi_shared/mpich2-install_shared
[I just chose the “rpimpi_shared” to replace the “you” in the Argonne guide and I made the directory creation in two steps]
5. Make a build directory (so we keep the source directory clean of build things)
$ mkdir /home/pi/mpich_build_shared
6. Change to the BUILD directory
$ cd /home/pi/mpich_build_shared
7. Now we are going to configure the build
$ sudo /home/pi/mpich2_shared/mpich2-1.4.1p1/configure -prefix=/home/rpimpi_shared/mpich2-install_shared --enable-shared
8. Make the files
$ sudo make
9. Install the files
$ sudo make install
10. Finally add the place that you put the install to your path
$ export PATH=$PATH:/home/rpimpi_shared/mpich2-install_shared/bin
Note to permanently put this on the path you will need to edit .profile
$ nano ~/.profile
… and add at the bottom these two lines:
# Add MPI Shared to path
PATH="$PATH:/home/rpimpi_shared/mpich2-install_shared/bin"
A couple of pictures when it was finished
(Picture Credits below: Glenn Harris 2012)
Subscribe to:
Posts (Atom)