When David shared the one-time pad challenge with the team, I was eager to dive back into some C. In 2015, high-level languages prevail, so a low-level C implementation may be seen by some as work that is unnecessarily difficult, unnecessarily tedious, and, well, unnecessary. Since the exercise was presented as an entertaining diversion, I rejected these reasons and focused on the work that fluctuated between contemplation and frustration. Questions like "Do I have enough memory for that?" and "Is there a risk of overflow?" gave way to frustration when, yes, I inevitably forgot to increment a loop counter.
Despite this potential for frustration, C's storage of a character as a single byte eases the act of converting between a letter and its numeric equivalent. Treating the letter as a character will show the character. Treating the letter as a number will show the number; the conversion is implicit:
printf("The value of '%c' is '%d'.\n", 'a', 'a');
=> "The value of 'a' is '97'."
printf("The value of '%c' is '%d'.\n", 97, 97);
=> "The value of 'a' is '97'."
This representation is helpful in two other scenarios. Checking the inclusion of a character in a given range (though there is a better option, see is_hex_digit below):
Pattern library, styleguide, UI library, parts kit; call them what you want, but these are essential to building websites of any scale. Typically, this is something you manually construct to demonstrate all the modules and pieces that you have constructed, but I have been investigating ways to make them a bit more dynamic when building sites with Craft.
Just over a year ago I started using Gulp and created gulp-starter. The setup works great out of the box on projects that are unopinionated about assets. Rails, unfortunately, is very opinionated, and it's taken me a year of trial and error to land on a solution that fully integrates a Gulp-based asset pipeline with Rails without compromising existing features or sacrificing speed, power, or flexiblity. The following setup is specifically customized for Rails with Heroku, but is easily adaptable to whatever tech stack you're using.
After some back and forths on our blog this week, we’ve been discussing Progressive Enhancement a lot here at Viget. PE is commonly touted as a responsibility, the “right” way to do things, and a safe development practice. It's the way I learned to build websites, and the way a lot of up-and-coming developers are learning, too.
Recently, I've been forced to ask myself the same question I'm about to ask you: what does progressive enhancement actually do? The more scrutiny it's under, the less it appeals to me as a design strategy. I’d like to poke at a few myths about PE and statements I've heard on the topic.
(Note that in this article, I’m using the term PE to address the particular idea of HTML-first design that JS features “enhance”)
Every good Pointless project begins with a kernel of curiosity. We've been curious about stepper motors and have been looking for a project that would let us experiment with them. Stepper motors are the brushless electric motors typically used in hardware applications that require a high degree of rotational control. If you own a 3D printer, it’s very likely that the linear motions of the machine are driven by stepper motors.
We were inspired by Laura's mantra and decided our foray into stepper motors would benefit dirty office whiteboards.
Laura (Viget UX Designer) makes her position known.
MAKING MR.CLEAN PROUD:
This week, we set out to design and build a bot to take care of the simple cleaning task everyone in the office has failed at: cleaning the whiteboards. Make no mistake -- this is something of a problem at Viget. One of our conference rooms has remnants of Pointless Weekend doodles from late November. It’s February, friends!
The rough idea is to suspend a cleaning pad from two points and control it so that it moves across every inch of a whiteboard. We’ll use stepper motors for the puppeteer part of the design and a beefy brushless RC airplane motor to spin both the cleaning pad, as well as a propeller, so it pushes against a whiteboard.
This all sounds well and good; but, could it actually clean a whiteboard? First order of business: validate the idea. We dove right in with a prototype.
Using available spare parts, we hacked together a cleaning pad that spins and pushes itself against a whiteboard. That’s a brushless motor, attached to an RC propeller, attached to a foam scrub pad.
We built a prototype to quickly determine what level of cleanliness could be achieved by rotating a cleaning pad against a whiteboard. Something quickly became apparent: without the use of a solvent, our prototype could match the same level of cleanliness someone with years of experience and a hand eraser could produce.
In this first pass, we weren’t concerned with perfection. We build things iteratively and this was good enough.
There are two mechanical aspects to this project. The first is the business end of the device -- the spinning pad that pushes itself against the whiteboard. The other is the suspension system which controls and moves the pad across the whiteboard. Let’s talk about the math and motors involved with getting this right.
For this exercise, we’ll turn to a familiar static equilibrium scenario that represents the physics involved:
We began by creating a spreadsheet to model and calculate the forces acting on the suspension lines (T1 and T2). These important forces can be calculated by knowing three variables: the suspended weight and the position of that weight relative to the two points from which it is suspended (represented by two angles - A1 and A2).
Notice the stepper motors located in the upper corners and the cleaning device located in the middle. We'll actually position the motors above the whiteboard. A1 is represented by the green lines.
In this calculation, we modeled the worst-case scenario. Imagine a 1 lb object at rest at its highest vertical position in the middle of the whiteboard. We conservatively estimated that this would be roughly 10 degrees off the horizontal. This means that each stepper motor would endure about 3 lbs of force.
To inform our stepper motor selection, we began by determining the forces acting on each stepper. Our Boulder neighbors over at SparkFun have a number of steppers. They come in a variety of form factors and amounts of torque. For this application, we needed something with at least 3 lbs/inch of torque.
Photo Credit: Sparkfun
We found a stepper with 125 oz/in (or 7.8 lbs/in) of torque. While this is more than double what we were looking for, we didn’t mind the extra torque cushion. It gives us the ability to push through unexpected engineering issues, which always come up.
We rely on 3D printing for nearly all of our small part needs. Modeling in CAD is quick and designing parts for additive manufacturing is a trivial jump. It’s also low cost and a great way to meet your neighbors. Check out makexyz.com and see if someone near you can help bring your model to life. We’ve had great success with reputable local printers here in Boulder and I highly recommend you check out local resources before investing in your own 3D printer needs. (3D printing is still in its infancy and there are no true out-of-the-box solutions.)
In a future post, I'll share more about the CAD design we’ve been thinking about and how we rely on rapid prototyping to bring project ideas to life. I'll also share some thoughts on 3D printing and what you need to know to avoid common pitfalls.
Have your own vision for what a whiteboard cleaning bot could look like? Share them in the comments below. Sketches are welcome.