On March 11, 12, Maker Faire UK pitched its big, geeky tent once again in Newcastle. This BBC News “Tech Know” segment (link below) and article offer a fun little wrap-up of the event. It sounds like it was a roaring success, with some 10,000 attendees. Congrats to the whole Maker Faire UK team!
Inventor Paka showed off his 8m-long fire-breathing dragon made of scrap. Bo the Clown cycled around on his connected bike and there was also the biology-inspired Bulge sculpture made of stretch cotton by Bethan Maddocks for folks to see, squeeze and squish.
Parked in the square was Tom Ward’s Tech Truck, a panel van that had been converted into a mobile hacker space.
Those taking a turn inside could build a nippy little robot controlled via a TV remote.
Mr Ward plans to use the Tech Truck as he travels round the country running tech bootcamps at schools and other events.
“We’ll be teaching kids soldering and practical skills that they probably won’t learn at school,” he said.
The focus on curriculum and exams has left little time to tinker and create, said Mr Ward.
In makers-we-like-to-celebrate-news… The Internet Archive just hired the best person in world for something that calls itself the Internet Archive. Congrats Jason, and congrats to all of us – quite a bit of computing history will not be lost.
I don’t know about you, but I’m so used to the paradigm established by old-style incandescent bulbs that when one of my CFL’s “blows out,” it doesn’t even occur to me that I might be able to repair it in the garage. Or at least, it didn’t until I saw this page from Pavel Ruzicka, which does a good job of explaining the general principles of operation of CFL lamps and gives great details about their most common failure modes. Apparently, replacing a single capacitor will often do the trick. [via Hack a Day]
Here’s a neat way to visualize 3d data from your Kinect: turn it into a live autostereogram! Kyle McDonald and Golan Levin put together this ofxAutostereogram project using Open Frameworks. Source code to the project is available at the link.
Color filters allow you to alter an image by … well … filtering out colors from an image. While Processing has some filters built-in, it’s often handy to be able to create your own custom filters. For example, the site Anaglyph Methods Comparison details a number of different filters that are handy in creating 3D images.
As you’ll see from the site, filters are basically mathematical transformations that are applied to the red, green, and blue components of the pixels in an image. To create a filter like the ones on the stereo anaglyph site, we need to pull each pixel in the original image, apply a matrix operation to its color components, and then use this new value in the corresponding pixel in the new image. This Codebox shows you how to create your own filters like these.
First, though, a bit of review for the (potentially) hairy looking math. A matrix is a 2 dimensional array of numbers called elements. Matrices are used in many different applications, representing sets of equations, transformations to 3D objects, and color filters (as in this example).
A matrix is usually characterized by its dimensions: the number of elements in its rows (the numbers going across ) and columns (the numbers going up and down). By convention, the number of rows always comes first. The following figure shows 2 matrices. On the left is a 2 row by 3 matrix, which is generally just called a 2×3 matrix. On the right is a 3 row by 2 column matrix, also called a 3×2 matrix:
To multiply two matrices together (let’s call them matrix A and matrix B), the number of columns in matrix A must equal the number of rows in matrix B. This is critical — if this isn’t true, then the multiplication is not defined. (This is sort of like dividing by zero — it’s simply impossible.)
Assuming this criteria is met, the product of the two matrices (lets call it matrix C) will have the same number of rows as matrix A and the same number of columns as matrix B. The elements in matrix C are equal to the sum of the products of the corresponding column element in A times the row elements in B. This is a bit tricky, but the following figure should (hopefully!) make this a bit clearer:
The following sketch, matrix_mult.pde, illustrates how to do the operation in Processing:
When you run the sketch, you should see the following output:
So, with the basic math out of the way, we’re ready to write the filter code. The remaining wrinkle is that images in Processing are held in one dimensional arrays of colors, rather than 2 dimensional arrays of (x,y) coordinates, as explained in this great Images and Pixels tutorial by Daniel Shiffman. In the tutorial, he gives a nice formula that you can use to map an (x,y) coordinate to the position in the image array:
position in array = x + IMAGE_WIDTH * y
The following figure should help illustrate most of the concepts at work here:
Without further ado, here’s a sketch called filter.pde to implement the filter through matrix-multiplication:
Getting Started with Processing Learn computer programming the easy way with Processing, a simple language that lets you use code to create drawings, animation, and interactive graphics. Programming courses usually start with theory,but this book lets you jump right into creative and fun projects. It’s ideal for anyone who wants to learn basic programming, and serves as a simple introduction to graphics for people with some programming skills.
Magic Vision Lab‘s weather simulator is great, but I think it needs an air conditioner slash personal sprinkler to make it more realistic.
We examined a range of weather phenomenon and how they may be simulated in a mobile augmented reality system. ARWeather was developed and deployed on the Tinmith wearable computer system to enable autonomous and free movement for the user. The user can move freely inside the simulated weather without limitation. The result of this work, the ARWeather application, has been evaluated with a user study to determine the users acceptance and draw conclusions to the applicability of augmented reality simulated weather.
Idahoan Dean Williams used to make a living by repairing vintage mechanical cameras. If you’ve ever pulled your hair out trying to replace a small spring that hasn’t been manufactured since the factory was bombed by Göring’s Luftwaffe, you may be interested in his well-documented DIY method. Dean’s trick for annealing them inside a wad of steel wool in a toaster oven is worth a click all by itself. His entire site, in fact, will likely be of interest to those who appreciate close mechanical work.
A while ago MAKE did a post on A Beginning Engineer’s Checklist from the PIClist site. And while I love these kind of lists, it left me – as a mechanical engineering – feeling a little left out, with all the talk of chips and Ohm’s Law and power busses (oh my!). It also reminded me of a list we had posted on a bulletin board at my first job, called Akin’s Laws of Spacecraft Design, which definitely apply to more than just spacecraft. So here’s my attempt at rearranging and adding to these lists to give them more of a mechanical flavor and include some of my own lessons learned over the last few years.
2. Project planning follows the rule of pi. Take how much time you think you can complete something in, multiply it by pi, and that will be the actual length of time it takes.
3. Parkinson’s Law: Work expands so as to fill the time available for its completion. Don’t give yourself too much time for a project or it will never get done. Speaking of done, check out The Cult of Done Manifesto. If it weren’t for the last minute, nothing would ever get done.
4. Everything is a spring.
5. If it moves and it shouldn’t, use duct tape. If it doesn’t move and it should, use WD-40.
6. Document everything you do. Someone will ask you to justify your design at some point, and “it kind of sort of looked right” is never a good answer. This is especially true on collaborative projects. The group will forget who did what and it will make going back and changing things that much harder.
7. Design is an iterative process. The necessary number of iterations is one more than the number you have currently done. This is true at any point in time.
8. Ask questions. If you don’t know something, say so. Your credibility as an engineer lies not in being infinitely intelligent, but in knowing how to get at the right resources to figure it out. If you cheat, people will die.
9. Designing for disassemble is just as important as design for assembly. It will never work the first time you put it together. Oh, and make sure that everywhere there is a screw, there is a place for a screwdriver to install it. And for a hand to fit around said screwdriver.
10. Business will always be a part of engineering. Don’t work for free (unless you really want to) and don’t work without a contract. Don’t design a better mousetrap THEN expect someone to want it. The products that sell the best are not necessarily the ones that are technologically superior.
11. Design is based on requirements. There’s no justification for designing something one bit “better” than the requirements dictate. Better is the enemy of good enough. Get it done then go play outside.
12. Engineering is done with numbers. Analysis without numbers is only an opinion.
13. Be friendly and talk to your machinist and/or shop techs. You may have a fancier title or degree, but that does not make you better. A short conversation on how to make a part more easily machinable/moldable/etc. can save thousands of dollars and make you both look good. You may even learn something.
What would you add to this list? Tell us in the comments.
In this video we learn about the Zoomorphic Collection exhibition in London, co-curated by Emma Hawkins and her antique-biz father J. B. Hawkins, featuring over 200 “animal objects for human use” as seen throughout history.