Coming in to the Hackathon, the Aboriginal Nonentity Congressmen (ANC) had a couple of contenders for top idea. They wanted a project that incorporated as many of the unique elements of the event as possible, not just a phone app that had been ported to the Pebble. Here are a couple of the top choices:
This would be like everyone's favorite Tamagotchi, with the addition of pluggable power-ups that would be inserted into the SmartStrap.
The Nintendo PowerGlove, made ready for the 20th century. John Anderton look out.
Say you are adjusting a slider with a default stop in the middle. Have your Pebble "click" when it is at center.
Check Point Race
Receive GPS coordinates and a time on your watch. You have so many minutes to get to a location and solve a puzzle before you can receive the next clue.
That Thing from Cowboys and Aliens
After hearing about the special bonus 8th LulzBot available for, and some quick deliberation, a 3D printer-based idea was agreed upon.
This idea would incorporate the best aspects from a few different projects, namely:
- Something that a smartphone alone would not be capable of
- Used unique parts provided to us by the Hackathon
- Ability to print fun 3D models
- Not too much low level hardware interaction
- Option to add our Maxim DS2401 silicon serials if we had time
What exactly was this idea?
You know those scrolling games where you have to avoid random terrain? We decided to make on of those, but in the physical world, controlled by the Pebble. A mechanical game you say? Let the fun begin.
First order of business: acquire 3D printer.
The Congressmen immediately headed toward the LulzBot area, hoping to beat the rush. Surprisingly, nobody else queued up in line. Odd, for a 3D printer / Pebble hackathon. Solitude strengthened resolve! The printer came back to level 2, table 5, and work commenced.
There were three main programming challenges:
- Communication between the Pebble app and the
Corerunning on a computer
Corefiguring out ship position and collision logic
Coretalking to the LulzBot Mini
Wolfshirt took the lead on the game code, relying on his advanced knowledge of Laplace Transforms, Hohmann transfer orbits, and general linear algebra badassery to guide him through the basic trig that would be needed for the project.
Thompson would use his experience coding in the Pebble environment to tackle the challenge of establishing low-level communication between the Pebble and a nonstandard host device.
And Sibicle's MacBook would have a chat with the LulzBot.
Two A.M saw three tired developers with three proofs of concept. The Congressmen toyed around with the idea of an all-nighter, but in the end a recess was decided upon. The scoreboard:
Sibicle wrestled with an unfamiliar language (Python) for an embarrassingly long time. With some help from the friendly folks at rc.freenode.net #reprap who pointed to Printrun, a G-CODE "REPL" existed that could accept G-CODE strings from the command line, and send them directly to the Mini. In the end, the code was incredibly simple:
from printrun.printcore import printcore if __name__ == "__main__": printer = printcore('/dev/tty.usbmodemfa131', 115200) while (true) : command = raw_input("cmd: ") printer.send(command)
Wolfshirt had the Lion's share of the architecture on his hands. After a couple of false starts, we had a motion model that we thought would be fun, and suit the project. Essentially, the craft would have a velocity vector, and a constant, unmodifiable speed. The buttons on the Pebble would control the angle of the velocity vector, and allow you to steer.
Thompson crushed the Core code, quickly getting to a point where it was possible to receive communications from the Pebble. He moved on to wire framing the Watchapp.
After a refreshing 6 hours, and an industrial sized batch of eggs-a-lá-Wolfshirt, the Congressmen were ready. The team split up, with Wolfshirt and Thompson heading back to Galvanize, and Sibicle holding down the fort to do some modeling on a more powerfully dual-monitored machine. This is when things started to get exciting.
Within hours, Thompson was sending commands from a fully functional Watchapp to our
Core. Sibicle used his meager design skills to furnish Thompson with a suitable craft for the journey.
Wolfshirt, meanwhile, had a fully fleshed out virtual environment, and was beginning work on virtual collision detection.
Sibicle got started creating the models that would be required for the project. The most important component would be the terrain through which the craft would navigate. Solid modeling a landscape seemed like an exercise in frustration, and Sibicle's geometric modeling skills were rusty with a decade of neglect, so a heightmap conversion was chosen. Using Photoshop, a nice terrain brush pack [http://1k0.blogspot.com], a conversion tool [Windows] from the Thingiverse, and some artistic compromise, an intimidating canyon was born.
Wolfshirt also needed a simplified collision matrix, so Sibicle provided one using some more Photoshop munging, an online image to byte array conversion tool, and regex.
Also on Sibicle's docket was the adapter arm:
And the craft itself.
Three false starts, and altogether too much HIPS, gave rise to a landscape!
All that remained was to debug the Core code and implement a main run loop. After a successful all-nighter (it is a Hackathon after all), the Congressmen turned in for a couple of hours at 7:30 AM.
Oh, the 80 / 20 rule. Nothing too exciting to report, other than countless hours spent watching the printhead move, stop, start again only to reset. With two hours to spare, Wolfshirt and Thompson put the finishing touches on the Core code, and began the process of tuning and calibrating the system for maximum replayability.
There are a number of improvements that could be made to LulzBlap. Here are a couple ideas:
Of course every flying game needs different landscapes to fly over. It would be a relatively simple endeavor to print out other terrain maps, and create a corresponding collision array. the limiting element of this enhancement would be positioning the terrain in a more repeatable and less permanent fashion than hot glue.
The most exciting idea we came up with would be integrating the Pebble with a game-specific Smartstrap. In this idea, the Pebble would communicate through its Smartstrap port with a Teensy micro controller, which itself would implement the Maxim 1Wire communication protocol to read the serial number off a Maxim DS2401. This serial number could then be interpreted as a power, unlocking any number of special features on the craft:
- Slow down time
- Increase turn rate
- Increase elevation
One problem noticed early on, but never solved, is the fact that at times the craft would be flying backwards. Not until the second morning did ANC see what had been sitting in front of them since the beginning—a stepper motor already positioned, geared, and ready to serve.
To realize this improvement, an alternate extruder body would be created, along with an extra herringbone gear. Since these files are all open source, the process would be a relatively straightforward affair. Then, using bevel gears, the rotational motion could be redirected downwards to allow the craft to point in the direction of its motion.
That's All, Folks!