As Pete posted earlier, my proposal, the traveling mascot, won the Raspberry Pi challenge.  I proposed a self-tracking traveling mascot based on the Raspberry Pi.  My hope with the proposal was to make the project a community project. This is my call for participation from other makers. I’m looking for artists, designers, developers, and makers of any kind to participate in the project.

The kit came with lots of extras, breadboards, case, power supply, cables, GPS module, etc. To work with the project in the space I needed some additional equipment. So far I’ve scrounged a monitor, keyboard, mouse, etc. at the space. Vishal has donated the use of a Motorola laptop converter for phones. Ed has donated a cable. Yet, the project could use a USB hub. I’ve found the need to attach more than two USB devices at one time. Does anybody have a spare?

My plan is to work out the functionality requirements, so we can figure out the size restraints before designing the appearance of the mascot. Yet, if you have any ideas for how it should look, please share them. My immediate goal for the project is to figure out the GPS unit. Soon I’ll work on the battery, camera, and home base server.

If you want to help, participate, or just check out the project talk to me when I’m at the space, or post a message on the mailing list.

  I have been meaning to make one of those “Dirty/Clean” signs for my dishwasher for a good while now and I was figuring I would end up printing something cool, slapping a magnet on the back, and calling it a day. But as I was sitting down to work on the design the other day I thought to myself “Why do something good enough that will take 20 minutes when I can spend 3 hours making something completely over the top?” and thus this was born.

You crank the gear to the far right on the one on the left turns to indicate the current state of your dishwasher. Necessary, no. But it was fun. If you want to make one the design is up on thingiverse.com: http://www.thingiverse.com/thing:63444

We sometimes experiment too much….

Apparently, this is what happens when the entire makerspace chants, “ph’nglui mglw’nafh Cthulhu R’lyeh wgah’nagl fhtagn” at once….

Remember our recent announcement about the Raspberry Pi Challenge we’re running? Well, we’ve found our challenger, and it’s Eric B!

Eric’ joined Milwaukee Makerspace last summer, and rumor has it he’s a pretty skilled software guy, so hopefully the challenge of writing code for the Raspberry Pi won’t be too difficult for him. He’s also done a bit of metalwork, woodworking, and a few electronics projects. But wait, we should explain what he plans to do!

Here’s the project that Eric proposed:

As an outgrowth of the Travelling Gnome Prank, many groups have adopted their own traveling mascot, where a statue, doll, gnome, or action figure voluntarily travels with various group members to far off places. The group documenting the travels of the mascot collects photos and travel reports

I propose that a Milwaukee Makerspace traveling mascot be equipped to report on its own travels. Built around a Raspberry Pi, with the addition of a battery, GPS unit, and a camera sensor, the traveling mascot could take its own photos and report its own location.

I believe that with this kit, a few additions, and the tools at the Milwaukee Makerspace, I could pull off making a working self-reporting traveling mascot. With the help and input of artists, designers, developers, and makers of any kind, we could make this thing great.

This project can help build the Milwaukee Makerspace community by keeping the space in our member’s minds as they travel, sharing with our community. Also, the traveling mascot will encourage frequent additions to our website.

Sounds cool! I don’t think anyone has used a Raspberry Pi to create a self-documenting mascot that can track itself. Eric’s made it clear that he wants this to be a community project, and is hoping for input (and assistance) from other Milwaukee Makerspace members. We’ll keep you up-to-date with blog posts as things progress.

(Thanks again to Adafruit Industries for helping make this project possible.)

I gotta say I’m pretty proud of my design for a custom programmer shield.  The images below show the Arduino, programmer shield, and a target board (ATTINY85).  I made the boards using the laser cutter method (which you can find videos of on this site somehow).  The target boards slip right into the header pins I bent up for the purpose.   Makes a really handy programming and testing jig!

Y’know, ’cause we’re all fancy like that.

Once we got our occupancy permit, we had to consider how to display it.  A simple plastic frame seemed a bit above us, so I was asked to design a laser cut frame instead.

The frame was designed in 4 layers (5, if you count the acrylic) in Illustrator CS5 and cut on our 60watt laser cutter out of one of our favorite materials, 3mm thick Baltic birch plywood. If you’re wondering why the permit doesn’t fit perfectly, some unnamed culprit gave me the wrong measurements, but I still think it looks great.

Since I firmly believe that makerspaces enhance and contribute greatly to the world we live in, I came up with the corny, soon to be lampooned phrase, “Official Permit for the Milwaukee Makerspace to Make the World a Better Place”.

And that is what we intend to do.

Here’s a book review for the MMS Book Club. A copy of this book is in the Milwaukee Makerspace’s library.

Chris Vander Mey was a Google product manager and an Amazon engineering manager. Shipping Greatness is a handbook on how to that job. It may have different titles, the book lists a bunch, but Mey is describing a specific job in a specific type of organization. The job is project manager. The project is a new website or website feature. The organization is a large enough company to have multiple teams working on different projects of this type. The team will report to management higher up the corporate ladder.

The book assumes the product team, as part of a larger organization, has plenty of available resources. For example teams will have multiple design contributors, user experience, user interface, visual designers, etc. Mey doesn’t assume these will all be distinct individuals, nor that these will be dedicated to the team for the duration of product development. Yet he does assume the team will have access to such contributors. Having a full time project manager on a team presupposes a sizeable team.

The products Mey shipped were mostly websites or website features. Mey gives specific advice on how to project manage the production of this specific product type. Mey fails to generalize his lessons, so that the reader can easily apply his advice to other situations. It’s an exercise for the reader to figure out how to apply this advice to contract programming projects or native mobile apps.

Unfortunately I do not have that job. I work on a much smaller team, where we don’t have a product manager per se. Most members of the team share the responsibilities and contributions Mey describes. Mey’s book is laser focused on the project manager’s contribution to shipping product, so it doesn’t translate to my team. I’m able to apply very little from this book to my situation.

If you have this job, or want this job, read this book. If you work on a team like this and want to understand your project manager, read this book. Those of us working in a different team structure can skip this book.