Categories
Uncategorized

MMPIS (Part III)

Quote

See Also: MMPIS (Part I), MMPIS (Part II), and MMPIS (Part IV).

The MMPIS should also be somewhat whimsical. We like to be serious and safe at Milwaukee Makerspace, but we also like to have fun.

Buried in the deepest regions of the Milwaukee Makerspace wiki (actually it’s just in the ‘Miscellaneous’ section) is the quotes page. The quotes page is filled with insightful wisdom and… ok, many of the quotes are just amusing. At least to me, or other members.

Any member can get an account for the wiki, and therefore any member can add a quote to the page, and some have! I thought about scraping the page for quotes, but some are really long, and some I don’t find as amusing, so every now and I then I grab new ones I like and dump them into a text file. Then there’s a simple PHP page which reads in the text file, randomly grabs one, and outputs it. That’s what you see. (I’d share the code but to be honest if you’ve ever written any PHP at all, this should be a five minute exercise.)

Here’s a collection of some of my favorites. And yes, some of mine are in there, but they were added to the wiki by others, not me.

Quote

Quote

Quote

Quote

Quote

Quote

Quote

Quote

Categories
Uncategorized

MMPIS (Part II)

Info Screen

See Also: MMPIS (Part I), and MMPIS (Part III), and MMPIS (Part IV).

MMPIS is semi-related to reMMinderbot, in that it’s meant to actually provide helpful information. reMMinderbot lets us know (via email) when there is a meeting, or if we haven’t blogged in a while, or when the monthly cleanup day is coming. (It has to remind us of that twice! On Wednesday and Saturday before the actual Sunday we clean.) There’s lots of Perl and cron involved in reMMinderbot.

reMMinderbot is also supposed to send an email telling us what’s on the calendar each day. This occasionally works. I’ve been writing code to deal with calendars for way too long. It’s sort of a nightmare. The iCalendar format is best described as Wibbly Wobbly Timey Wimey.

There’s an old saying:

Some people, when confronted with a problem, think “I know, I’ll use regular expressions.”
Now they have two problems.

Parsing iCalendar files can be like that. Luckily, Perl has a module for everything! So iCal::Parser was pulled into service. Unluckily, it has bugs. iCalendar can be tricky. There are repeating events, but they can have exceptions, days they don’t actually happen. I’ve seen weird time zone issues, and differences between clients. Anyway, it’s all wibbly wobbly.

Our original Perl code grabbed the calendar file from Google, parsed the file, and then output the upcoming events to a file that is then included in the main page. As I said, though… it doesn’t always work. So I decided to scrap it.

In an ideal world, we would just clone the calendar page on the web site and display that. There’s just way too much Javascript on that page though, and it takes too long to render. I then remembered a web application I used years ago, so I turned to PHP iCalendar.

PHP iCalendar

PHP iCalendar manages to display things properly! All events revealed! Though the monthly view is not what I want. Nor is the daily or weekly view, but… At the bottom is a “This Month’s Events” section. We can use that!

List of Events

I took the files that showed the monthly view and started hacking. I stripped out the unneeded HTML, edited the CSS to get what I wanted, and it was pretty close, but… it was just displaying the current month’s event. This would mean that if there was an event on the first of the month, you’d never see it until the first of the month, which is silly. Digging through the PHP it was just a matter of changing things to look at the current month and the next month. Not 100% perfect, but an acceptable solution.

Right now it’s looking two weeks ahead, so you’ll get any event for the next 14 days. This is what you see below.

MMPIS Events

I may play around with setting the viewport to be 1920×1080 and then using overflow: hidden to better use the space on the screen, but I’ve also got the issue that I’m doing development on a 1280×720 screen, so I may need to do some CSS stuff depending on the screen size, if that’s even possible. (Also, to pick a nit, the resolution of the TV I am using today says it is displaying 1360×768.)

Anyway, the PHP iCalendar solution has been working so good I’ll probably roll it into reMMinderbot’s calendar code. It’ll take a bit of Perl-fu to do the right thing there (multiple servers are involved) but it should be a major improvement. (Hopefully.)

What’s that? You can’t wait for Part III? It’s coming…

Stay Tuned!

Categories
Uncategorized

MMPIS (Part I)

MMPIS

See Also: MMPIS (Part II), MMPIS (Part III), and MMPIS (Part IV).

I typically write about a project after it’s done, but I thought I should turn that around and start writing about a project much closer to the start. So here’s Part 1 of the story of the MMPIS, the project more formally known as the Milwaukee Makerspace Pi-powered Information System, which is a kiosk at the makerspace which will provide members (and guests) with useful (and silly) information.

First, the name… We have a history of naming things with acronyms and/or using an many “M”s as possible, such as: HMMMMMM, M6 (Milwaukee Makerspace Morgifying Marble Manipulation Machine), M4 (Milwaukee Makerspace Maker Mobile), reMMinderbot, M2C2 (Milwaukee Makerspace Can Crusher), MMLC (Milwaukee Makerspace Lighting Controller), and of course, BADASS (Beer Automated Dispensing And Security System). I choose MMPIS because it’s fun to say. I nearly went with MMKIS (Milwaukee Makerspace Kiosk Information System) but unless I’m outvoted, I’ll probably stick with MMPIS.

I’ve long had an interest in digital signage and kiosks, so after my recent Sir Like-A-Lot project, I felt like pursuing a kiosk for the Makerspace. We had a Raspberry Pi that had been floating around waiting for a project, and there’s a huge TV that jason g. brought in that we used only occasionally. Those two pieces and a few other things were all it took. Well, that and writing some code.

The heavy lifting is all provided by Screenly, and actually, it’s the Open Source Edition of Screenly. (Also on GitHub.) Screenly is a pretty nice open source kiosk application. I’ve discovered a few bugs, and have some feature requests, but it definitely works. I’ve been meaning to check out Concert and Xibo as well, but I’ve not dug into those yet.

The first group of screens is pretty simple, here’s a few grabs.

Info Screen

Here’s the main screen (for now) which tells you where you are (duh!) and shows the date and time. It also tells you where to park, has a quote from the wiki, and shows the upcoming events. Well, some of them. We’ll get into that in Part II.)

Park!

We’re also showing our Parking App to let members know which side of the street to park on. (This, as every other screen, may change in the future.)

HMMDMMH

We’ve also got our How Many Members Does Milwaukee Makerspace Have? page. The HMMDMMH page uses our member management software to let us boast about this impressive number.

What's Cookin'?

Prepare Thyself for Making

The last two are just graphics that live on the Pi that runs Screenly. All the others are web pages out there on the big old Internet. Oh, I should note that the pages need to be fairly simple. Large, complex pages utilizing Javascript or other heavy lifting don’t do very well, due to the lightweight nature of the Raspberry Pi and the browser Screenly uses.

OK, that’s our intro to the MMPIS. In the next installment we’ll get into the events that the MMPIS shows, or should show.

Stay Tuned!

Categories
Uncategorized

Sir Like-A-Lot

Sir Like-A-Lot

My latest project was sort of a failure, but I’m going to post about it anyway, because such things are important.

For a recent event I wanted to create a unique way for people to LIKE something, and get a reward for it, so I grabbed a Raspberry Pi and got to work. The idea was pretty simple, a full screen display showing the number of Facebook likes, with the URL for people to visit the page (on their mobile devices) and like it. The display would then update in “near” real-time (Well, every 10 seconds) and there would also be a surprise…

Step #1 is always configuring the Raspberry Pi. I installed Raspbian, had it set to boot to the desktop, and installed the packages I needed, mainly Apache and Chromium, since I’d be using a local web server and web browser for the display.

Getting the Raspberry Pi to work as a kiosk display was next. I didn’t want any menus or OS parts showing, so I used Chromium running in kiosk mode. My /etc/xdg/lxsession/LXDE/autostart file looked like this:

# config to launch Chromium in kiosk mode and load our application
@xset s off
@xset -dpms
@xset s noblank
@chromium --kiosk --incognito http://127.0.0.1/likealot/

We got rid of the part that lets a screensaver run, and added in the bits to fire up Chromium in full-screen kiosk mode. (Oh, one note about Kiosk mode, it does not hide the mouse pointer, but we’ll deal with that later.)

LIKES

The results on the screen looked like this. Full screen, no browser or OS bits showing. I like this solution as it can be used for pretty much anything you can code up as a web page.

The display is set to refresh every 10 seconds, so it’s pretty up-to-date, and you’re really only limited by what you can display in a browser (Chromium) running on Linux (on a Raspberry Pi, in this case.)

As for the code, it’s less than 50 lines of Perl running as a CGI, and about a dozen lines of HTML in an HTML::Template file. There’s also a little CSS and an image.

Speaking of the CSS, it was the solution to hiding the mouse pointer for Chromium running in kiosk mode. I just added this bit:

/*
 * using CSS to hide the pointer
 */
* { cursor: none !important }

For an informational kiosk you just want people to look at and not have to interact with using a mouse or keyboard, this solution works well.

JSON

You might be saying “Hey! How do you get the number of likes!?” Well, you just ask JSON, or http://graph.facebook.com/?ids=z2marketing to be more precise. Facebook Graph API data holds the key, you just need the value.

Oh, there was one more really fun bit! When someone liked the page and the page refreshed and the number increased, you’d hear applause!

The original idea was to just have the CGI do a system call to play the file using aplay. That did not work. I also tried mpg321 and that didn’t work. In the end I went the other way around and added… another Perl script! There’s a cron job that runs on startup, which launches a Perl script, which loops forever and looks at the counter file that the CGI uses. Every time the counter file changes (due to the CGI updating the number) the Perl script uses aplay to play the applause file.

The end result is pretty good. A person sees the display, goes to Facebook, likes the page, and within 10 seconds the display updates and you hear some applause!

I planned on making a sign or adding some text to entice people take action and get a “reward”. And of course the URL isn’t as helpful on a mobile device where you probably use an app instead of a browser, but this is all a good start.

Now, I mentioned a failure, so I should explain that part. For anything like this, where it needs to run for hours reliably and not just be a quick technology demo, you need some burn-in time. I had this running for a week with no issue. The first issue that came up was, what to do if you lose the Internet connection. (Hey, we use Time Warner, it happens!) You really don’t want to see a default Apache 500 error page, so the error page looked just like the main page, but with a message that said ‘Please stand by…”. That 500 page was set to redirect to the main page after 10 seconds, which would deal with occasional Internet or network outage situations. Since we were also using a WiFi connection with the Raspberry Pi, there’s always the chance of losing the WiFi connection. This didn’t seem to happen much, but it’s something you may need to deal with.

I also set Apache to not do any logging, as there’s really nothing valuable gained from logging after you’ve got everything running. It also helps to write less data to the SD card that holds the system because… corruption.

Oh yes, corruption! Every now and then I would reboot the system to make sure it would start up properly. It almost always did. Except when it didn’t. Once the Pi booted and there was a warning that the file system needed repair, so I repaired it, and all seemed well. I tested again for another week, and things seemed good. But then…

The day of the event, I had to move the system into place, and when I did that, and started it up, Linux would not boot. Even after 13 years I am still not enough of a Linux expert to fix every problem it throws at me, and I was stuck, and had a dozen other things to do, so it was dead.

I did the dozen other things and then ended up reinstalling Raspbian and trying to quickly reconfigure it, and get all my files in place, and got everything working except the audio… and the WiFi. There are a few tricks to getting audio working properly on the Raspberry Pi. I eventually got it working, but it was too late to deploy it. Oh well…

So next time, I will have a BACKUP SD card ready to put in place when the first one destroys itself. Or maybe I’ll just build two complete Raspberry Pi systems. Backups are good. Backups are good. Backups are good.

But don’t worry, I’ll take all the successful bits of this project and re-implement it in some other way in the future.

Categories
Uncategorized

Miltalkee (The Talking Robot)

Miltalkee

Wow, somehow it’s been months since I first mentioned my entry in the Great Robot Showdown, and it’s been another (or a few more) since I promised a write-up on said robot… so here it is.

Proposal

For the Flying Car Milwaukee 2013 event there were a number of competitions held, one of which was the “Great Robot Showdown” which tasks people to “create an energetic, entertaining robot that actually does what it’s designed to do.” And noted that the robots would be “unleashed at the Flying Car Gala to delight and entertain the crowd.”

How could I resist? I had already shown things like the Friday Night Drawbot and the Arc-O-Matic at previous events in Milwaukee, so I figured I needed something new, something specifically for this event.

Miltalkee

I wrote up a proposal describing what I planned to build, included a quick sketch, and some links to previous projects, and mailed it in. About a week later Dana and I were putting a bid on a house, and I got a call. I checked my voicemail later and found out I was selected, which was awesome, but it also meant I had about 30 days to build the robot, move everything I own, and also take part in a gallery night I had committed to. Fun!

Miltalkee

It was time to get to work! My plan was to cut all the pieces of the robot from 3mm Baltic Birch plywood. That stuff is great to work with if you’ve got a laser cutter handy, and we happen to have one at Milwaukee Makerspace! There was a lot of cutting to do. Basically the robot consists of 8 “boxes” of various sizes to comprise the body, head, legs, feet, and arms. After cutting and assembling everything (with glue and strategically placed magnets) the pieces were painted with grey primer, and then with metallic silver paint. All sprayed in my home-built spray booth.

Miltalkee

I ended up spending the majority of my time doing the physical build, all the time thinking the programming would be the easy part. I was (mostly) right. Since I was using a Raspberry Pi I was in my comfort zone. A bit of sudo apt-get for the right packages, some Perl, a text file, and we had a talking robot. I ended up abandoning the idea of a screen or LCD display of any kind due to time constraints, but it’s an idea for the future.

Miltalkee

There is a hole in the center of Miltalkee’s chest where a speaker goes. It’s a powered speaker, using 3 AAA batteries, which works well in a semi-quiet room, but in a large room filled with people and music, it’s not exactly loud. (I should thank Dori Zori for turning down the music a bit!) If I ever want Miltalkee to be extra loud, I can always run the output to an external amp I guess.

One of the neat things about Miltalkee is the construction. The faceplate and chestplate are interchangeable, and if I get ambitious in the future, I can swap them out for new ones. This should make upgrading to a screen fairly easily.

There’s a bunch of technical stuff I’ve not included in this post, mainly because I’ve already rambled too much. In future posts I’ll talk about the Raspberry Pi, the code, and a few other construction secrets.

Miltalkee

Enjoy!