I’ve really struggled with the Raspberry Pi Project. As I posted earlier, the Raspberry Pi kept killing the file system on the SD card. Pete traded me for a different Pi, which behaved much better, making the card last at least long enough to get the operating system and other software installed. Yet the Raspberry Pi continued to corrupt the file system if left running for longer periods. The latest time it totally killed the SD card; I couldn’t even reformat it on my computer.
If I include the Pi in the traveling mascot, I’m convinced it will not survive the inevitable rough treatment. The only other use I can think of for a Raspberry Pi in a travelling mascot is as a home base server for the mascot, publishing the travelogues. Yet it’s too unstable for even that task.
I still like the idea of a traveling mascot that can track it’s own travels, but I’m convinced that building it around a Raspberry Pi is not the proper foundation. I really like the little GPS unit that came in this kit, and will try to build a scaled down version of the traveling mascot with a USB interface to hook up with any computer for collecting data.
Thanks again Adafruit Industries, we really appreciate the kit, and we’ll continue to work with the parts on other projects. Like vultures, some other members have already picked off some pieces of the kit for their projects.
I’ve made some progress on the Raspberry Pi based traveling mascot for the makerspace. I’ve figured out how to connect the GPS unit, and configure the software on the Pi to read the data. The makerspace’s metal roof well insulates the inside of the building from the GPS frequencies, so the device doesn’t receive location data in the electronics lab. The wooden roof of my home is much more transparent to these frequencies, so I’ve tested the GPS at home. I’ve got the C libraries loaded, and started a program to check and record the current location of the mascot.
Unfortunately I’ve run into a few setbacks. For some reason it keeps corrupting its file system, and failing to boot. A few times it’s happened has been when I made a configuration change and then rebooted. So I blamed myself. But today the Pi wouldn’t boot. The last time I used it I properly shut it down before tucking it in its box and putting it away. I had the Pi configured to register itself on the network so I could work with it remotely. It wouldn’t come online. So I grabbed the monitor and keyboard to figure out what’s going on. The monitor showed the Pi would start booting, but pause with a “PANIC: No init found.” message. A bit of web searching found that other people have had similar problems and fixed it by using different keyboards and different SD cards. Trying a boot without the keyboard and mouse plugged in gave the same panic message. So I think I need to try another SD card.
My son has a Raspberry Pi of his own, and a few SD cards he’s had success with. He has agreed to let the mascot project borrow one of his cards to figure out if this card is the problem. I’ll post about my results after I try with the different card.
Once I figure out the file system corruption problems, I can continue writing the C code. After that I’ll work on the other parts of the project. These parts include the website, battery pack, camera, and body. I think those denim monsters some members will be making in an upcoming sewing class could make a great form for the mascot. Would any of those members be interested in making a custom one for the mascot? Would any members be interested in helping out with any other part? Would any members just like to play with the Raspberry Pi? 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.
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.
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.