Sunday, November 1, 2020

Halloween project: A safe non-contact automated candy dispensing device.

    Our neighborhood never has a large number of trick-or-treaters, even on a normal year, but I do always make a point of having candy on hand for the dozen or so kids that we get. This year, I wasn't certain we would get any at all, and I wasn't sure I'd feel safe handing out candy face-to-face with them if any did come by. I had for a while been planning to just shut the outside lights off and lock the door, but decided, a few weeks before holiday, that I could hand out candy in a safe, no-contact way after all.

    I saw how some people were setting up delivery tubes for safe remote candy delivery. I had a cardboard shipping tube on hand that I could use for that, but I realized that I could do better than just dropping candy in by hand. I designed a carousel mechanism based around a FIT0441 blushless gearmotor, which would have compartments for up to 10 loads of candy.


About a 28 hour long print on my printer, one of the largest single pieces I've ever printed.


Room for 10 loads of candy, although one will always be empty due to being over the dispending hole.

    A microswitch acts as a position sensor, telling the motor when to stop after rotating to release the next load of candy. The carousel mechanism was mounted at the top of the tube, so that candy would slide down the tube after being released.


Quick assembly of the mechanism.

    To control the system, I used some old Arduino Pro Mini clone boards left over from another project a few years back. I ran into a significant problem with these, as the power supplies on the board failed, and in once case literally exploded, as I tried to run them off the 12VDC power supply I had on hand. The Arduino Pro Mini has an on-board power regulator which is supposed to handle a 12VDC input, but every one of these boards failed when powered at 12V. This was especially surprising as I had powered these exact same boards off this exact power supply when I first bought them a few years ago. I can only assume that they somehow degraded while in storage, but I'm still baffled. Perhaps this is just a lesson that I should be using actual Arduino boards rather than cheap clones.

    I eventually resorted to desoldering the failing power supplies from the boards, and using an external 5V regulator to power them instead. This worked with one of the three boards I had on hand, the other two seemed to be completely dead.

    At this point, it was getting fairly late on the day before Halloween, after spending a full day on getting the Arduino board to work, so the remaining wiring is a bit of a mess. Driving the motors was easy since the FIT0441 has a built-in motor control circuit. It has one wire for direction, and another which is used as a PWM speed control line. There's also a feedback line indicating motor rotation, but I didn't end up doing anything with that signal. Position control came from a big old microswitch out of my junk box which would be pressed to stop the motor after rotating.

Somewhat messy wiring in the final assembly, but it worked. The motor is driving the carousel through an inside ring gear built into the underside of the carousel. I made spaces for three motors, but only one was needed.

    I could at this point have made the device dispense candy with a button push, but I wanted it to be truly non-contact, not requiring either the visiting kids or myself to have to touch anything. I had on hand an IR emitter/detector assembly from a broken hands-free paper towel dispenser. This was fairly easy to hook up to the Arduino Mini. The IR receiver this module was using to sense reflected light was originally designed for TV remote control use, and was only sensitive to light pulsed at 38khz. Getting the Arduino to output a 38khz signal requires my directly writing to the timer 2 registers, as there doesn't seem to be any clean way that I could find through the Arduino libraries. Once I figured out how to do that, it was easy to get the proximity detector to sense when someone was holding their hands, or a bag or basket, under the end of the tube.

Downward-facing IR LEDs and sensor on the board at the bottom. Big red LED at top.

    As a final touch, I added a blinking red LED to attract attention to the end of the tube. My wife drew up an instructional sign, and sacrificed one of her old pairs of tights to cover the tube and all the exposed wiring.

Finished candy dispenser.

    We ended up getting about half a dozen kids, in two groups. The dispenser worked well, and with some guidance from their parents and me calling out instructions from inside, all the kids were able to get candy from it. I did determine during testing that Twix bars would sometimes jam in the cartridges due to being just the right length to get caught diagonally, but once I pulled those out the mechanism worked well enough.

    This was a fun project for Halloween, built entirely with parts I had on hand. I'm not sure if I'll bother with something like this again next year, though if I do I'll probably redesign it from scratch, as the rotating carousel mechanism for dispensing candy was really crude and could be made a lot more reliable.

Wednesday, April 15, 2020

Building my quarantine garden

This year I began an experiment in indoor micro-gardening, which I came to through a comvoluted path that started last year due to my wife's chronic medical issues. My wife is chronically ill, and among other problems has trouble regulating her blood electrolyte levels. Last year, after taking a careful look at her diet, she decided to start eating daily meals of foods high in potassium, especially roasted sweet peppers and mushrooms. This had a notable effect on her energy levels, to the point where she was able to actually start cleaning and shopping and doing other physical chores several days a week again.

Her favorite variety was a type of sweet pepper from Snyder's Farm, a local farm which had a weekly market near us. I'm not a big fan of sweet peppers, but I loved the hot peppers from the same farm for use in chili and marinades. We went through a lot of peppers that summer.

One day, as an experiment, she took some seeds from their sweet peppers and buried them behind a bush in our front yard. Astonishingly, despite being planted in terrible red clay soil and lacking any direct sunlight, the pepper seeds sprouted and grew. I transplanted them to a proper put with better-quality soil, and added a few dozen more seeds from other farm-market peppers. Many of those also sprouted. We didn't get any actual peppers out of those plants, of course, as they were planted late in the season, overcrowded and not at all growing under ideal conditions, but it starter me thinking about whether we could actually grow these same peppers ourselves with some care.

With the next batch of peppers we bought, I carefully removed and cleaned the seeds, then wrapped them in paper towels and set them aside. I also harvested some seeds from jalapeno and habanero peppers from the grocery store as an additional experiment. After drying them for a week, I discarded any that were discolored or mouldy, and packed the rest away over the winter.

Jalapeno, Habanero, Snyder Sweet, and Hungarian Hot pepper seeds.

At this point I didn't have anything other than vague plans for what I was going to do with these pepper seeds. I have nearly zero experience with gardening. I grew up in a house with a vegetable garden in the back yard, but as a child I had zero part in actually tending to those plants. My sole plant-keeping success prior to this was keeping a snake plant alive, which isn't much of a challenge as snake plants are only slightly harder to keep than a plastic plant would be.

We also are not living somewhere good for gardening. My wife and I live in a condo, and we aren't actually permitted to plant anything outside.  We own everything from the walls in, but the grounds belong to the condo association, and they really aren't happy when residents try to turn patches of yard into vegetable gardens. We can generally get away with putting planters on the patio, as long as we don't overdo it, but setting up raised beds would be out of the question.

Our second problem with growing anything is that our particular condo unit is on the northeastern side of our building. We get a few hours of direct sunlight through our east-facing windows, which is only really strong during the early spring until the line of trees that shade the side of the building grow proper foliage. We've always been grateful for not having to spend much on air conditioning, but it's not a great place to try and grow full-sun plants.

I didn't have great expectations for these seeds beyond throwing a few of them into a planter and maybe getting a few stunted peppers eventually. I marked down a good time on the calendar to try and sprout them, and then didn't think about them further for a while.

March eventually rolled around, and the world was getting concerned about this Coronavirus thing. My wife and I went on a cruise in early March, which turned out to be one of the last cruises that didn't turn into a quarantined ship, making it home just in time before everything got really bad. I bought a seed started kit, deciding to splurge on the 72 cell model. Following the instructions, I soaked the seeds in hot water overnight, then placed about 3 in each cell. I put the seed starter in front of an east-facing window, where it would at least get a few hours of direct sunlight per day. I still didn't have great expectations of results, thinking that maybe a handful of the seeds would actually sprout, since I knew they weren't getting as much light or heat as they should.

Pepper seeds, hopefully sprouting soon.

And then the plague got worse. Our state went into mandatory lockdown. My job was still considered essential, but the company decided to have everyone work from home if at all possible. I moved my entire engineering development setup home to our living room, and learned to teleconference with my co-workers several times a day.

This had the side effect of letting me check on the pepper seeds a few times a day, making sure they were optimally placed to get the meager sunlight available. And those pepper seeds sprouted, doing far better than I had expected they would. The Hungarian Hot peppers from Snyder Farms sprouted first, followed by the sweet peppers that my wife so loved.

Happy little pepper seedlings

The Habanero peppers sprouted slowly and reluctantly, only after being moved to a warmer spot with more consistent sunlight. And the Jalapeno seeds never sprouted at all. I don't know if they were a non-viable hybrid strain, or had been picked immature and ripened in transit, or some other cause entirely. The peppers from local farms were the ones we were most interested in growing, and every single one of those sprouted.

With far more pepper seedlings than I expected, the realization that fresh groceries were getting harder and harder to find, and the overwhelming urge to use the time I was stuck at home to do something, I decided to scale up my gardening plans. We still couldn't plant anything outside, but I decided to take the fullest advantage possible of our few hours of direct sun to try to grow peppers. We bought a cheap portable greenhouse, a handful of planter boxes and some planter soil. I took the grow-light that had previously been keeping the snake plants alive and set that up in the greenhouse to give the pepper seedlings a bit of extra light until they were ready to transplant.

Making the most of what little sunlight we get.

After a few more weeks of this, the pepper seedlings were large enough to transplant.  All except the jalapenos, which never sprouted at all.

True leaves are coming in, and it's getting crowded in there.

Finally, on a warm mid-April day, I filled the planter boxes with planting soil and transplanted the seedlings into them. I chose the best developed-looking plants, putting them into the soil spaced at about 4 inches. This is still more crowded than is generally recommended, but I expect that some won't survive being transplanted, and if they do I'll likely cull the smaller ones to thin them out.

Cramming in as many planter boxes as I can fit in there.

I fit a total of seven planter boxes in the greenhouse. Three full of hot peppers, three of sweet peppers, and one of the grocery-store habaneros that I still don't have great expectations of getting anything from.

I still don't have really great expectations for this garden.  I'll consider a single meal of peppers to be a success, and I'll be ecstatic if this garden means one less trip out to the grocery store (and therefore reduced chances of either my wife or I getting COVID-19). But victory gardens are essentially symbolic in nature anyway, born out of the need to be doing something even if minor. And having something living to take care of and nurture has been tremendously helpful to my mental state during this trying time.

Top boxes still get supplemental light from the grow-lamp.

And now that I have the peppers in their hopefully permanent homes, I'm thinking about enhancements. I have most of the parts on hand to set up a Raspberry Pi based monitoring and automatic light and water control system. Since I'm going to be stuck at home for the forseeable future, that will be a fun project to occupy my time.  Stay tuned for updates here.


Monday, November 18, 2019

Building the Nemesis Staff

It's all a Nemesis plot

August 2019.  My wife is getting ready to go to DragonCon, mostly to meet up with friends that she knows from online games, including the recently resurrected MMORPG City of Heroes.  About two weeks before the convention, she tells me that she’s going to the steampunk-themed ball, where two of her friends are getting engaged. I decide to try and make a Nemesis Staff, a gear-shaped weapon from the steampunk themed Nemesis villain group from CoH.  I didn’t think it would be too hard, but what followed was one of the hardest and most rushed printing projects I’ve ever done.


In City of Heroes, Nemesis is one of the higher-level endgame villain groups, and Lord Nemesis’s signature weapon is the Nemesis Staff.  The prop I was building was not the full version wielded by Lord Nemesis, but the lesser version available as a temporary weapon for players to use.  Mostly because it was much easier for me to get screenshots of the readily available temporary weapon, rather than hunting down Lord Nemesis or one of his many duplicates.

I was ultimately going to have to work from screenshots for making the prop.  Extracting actual geometry files from City of Heroes is difficult. Object geometry isn’t stored in any easily accessible format.  The usual method to record scenes is with utility that runs on top of CoH and intercepts geometry data on the way to the graphics card, but that results in recording the entire scene, at which point I’d have to manually filter out just the nemesis staff geometry.  But even if I did that, I could already see that I’d have to redraw the staff from scratch anyway. The in-game prop is painfully low-polygon, big chunky triangles approximating a circular shape and gear teeth that were suggested by image mapping rather than being actually drawn in.  This game is about 15 years old, and the graphical models were quite crude, and would have looked terrible if I had simply printed them out as-is.

Instead, I decided that I was going to draw the Nemesis Staff from scratch, using the appearance of the item in the game as a rough guide, but ultimately redrawing the whole thing from scratch.  My goal was to try and intuit the concept that the artists who drew the game model were working from, and to come up with what it would have looked like if they’d had unlimited rendering resources to work with.

While peering at the screenshots and trying to figure out the design of the gear mechanism, I realized that there appeared to be a lot of subtle detailing on the part, especially on the outer ring.  In the texture map, there appeared to be suggestions of engraved and embossed details. I tried to reproduce these on the printed prop, although it was at times difficult to tell if what I was seeing was intentional detailing or image compression noise.  As mentioned previously, the source images were painfully low-resolution.


Recreating the fine detailing in Solidworks

In other places, the texture mapping had obvious rivet heads and other details, which I expanded into actual physical shapes, in places making them actual separate pieces so they could be different colors from the surrounding materials.

The outer ring was clearly intended to be circular, rather than the crude polygon of the game model, so I drew it as such.  The central hub was also clearly intended to be circular. The sun gears, on the other hand, had detailing that suggested that they were intended to be actual hexagons, with six well-defined gear teeth.  There were lines on the inside of the ring and outside of the hub suggesting gear teeth, but they didn’t mesh with the planetary gear in any meaningful way. I added actual working gear teeth to make the mechanism actually work as a planetary gear mechanism, with the outer gear rotating and the planet gears going around as they do in the game.


Side by Side. Redrawn nearly entirely from scratch.


However, you may have already noticed the problem.  The Nemesis Staff isn’t actually a functional planetary gear mechanism, as it only has only two gears and nothing else locating the outer ring.  If I built it as-is, it would be likely to simply fall apart if you tried to rotate it. I considered a few different options on how to fix this, including redesigning it to have three or four gears, or adding some kind of hidden internal support structure to hold the planets and ring in place. 

For this prop I decided on making two design changes.  First, I added a hopefully unobtrusive carrier frame to hold the planets in line with the sun gear.  Second, I added a small brace piece to the inside of the fork to grip the ring and hold it in place. The outer ring already had a black line that suggested an inset groove, and a ridge on the brace fit into this did a pretty good job of holding the ring in place.  I also designed the teeth on the planet gears to fit into the sun and ring in such a way to try and lock everything in place once assembled. The result was really tight, tight enough to be difficult to rotate at first, and to be in some danger of damaging the plastic from the forces needed to make it turn.  In retrospect, I could have made it a bit looser.


I had decided that to save time, I would design the part to be completely unpainted, using the colors of the bare plastic. I had seen some amazing prints done with metallic Silk PLA, and wanted to try that out.  While I was designing the part, we ordered a few reels of copper and gold silk filament for overnight shipment. These arrived with a free replacement nozzle and a bag of nozzle-cleaning needles. I should have taken this as a warning.  The printing process saw repeated nozzle clogs, the Silk PLA was somewhat tricky to work with, and I think I may have ruined the nozzle in the process.

I had the design mostly done after a weekend of work.  Printing took much longer. The printer was exiled to the spare room where it wouldn’t keep anyone up as it was printing all night, and I had my wife check on it while I was at work as it was printing during the day.  The total print time on all these parts was over 100 hours, but that doesn’t include the multiple prints wasted from clogs that happened halfway through. This was the most demanding print project I’ve ever done, in terms of how many long prints I had to do back-to-back.  Not long after finishing, I did a complete teardown and rebuild of the arms and hot end, as everything was showing a lot of wear although I had been using the printer for years before this.

My big fancy custom Delta printer

The biggest problem was nozzle clogs happening midway through long prints.  I had a really surprising amount of difficulty printing with the silk PLA. Doing a nozzle flush with clear filament between every print with silk appeared to help, along with cleaning out the nozzle with the cleaning needles that came with the filament.  In retrospect, I suspect I may have been running at slightly too low of a temperature, as Silk should be printed at higher temperatures than normal PLA.

Printing took place over about a week of solid day and night work for my printer.  I was still designing parts of the piece during printing - the outer ring was designed first, with the inner part and fork printed while the large ring pieces were printing.  Some of the larger parts took over a dozen hours to print each, and there were a few print failures due to clogs, with many hours wasted.

Normally, with a complex piece with moving parts like this, I would go through multiple iterations and tweak the geometry until it was right.  But with the schedule I was under, there just wasn’t time. Nearly all of the parts on the finished staff were first draft parts. The clearanced were too tight on many of them, I had to do a bit of sanding to make the ring rotate smoothly, and there was some ominous creaking from the plastic as I tried to make it rotate.  If I was to make another one of these, I’d tweak the geometry and open up the clearances a bit. (Actually, I’d probably redesign the entire thing from scratch, but a quick cleanup would be acceptable if I wanted to make another one of these as-is).

Parts coming along. Getting ready to assemble everything.

Done. Attached to the first walking stick, which was not the one taken to the convention.

The last part to be designed was a mount to go on my wife’s lightweight walking stick.  Originally I had designed the Nemesis staff topper to attach to the top of her usual walking stick, which had a knob that could be unscrewed to reveal a threaded rod.  While packing she decided that this stick was too large and heavy to take on a plane, so she switched to a lightweight collapsible pole instead. This lacked the threaded rod, so I needed to at the last minute design and print a sort of clamshell clamp that went around the top of it.  It worked, sort of. It was ugly, and in the end relied on zip-ties, tape, and epoxy for structural strength. Not my best work.

My wife at DragonCon

The piece was finished just barely in time to be packed up for her flight to Atlanta.  She went to the City of Heroes meetup, and attended the steampunk ball, and showed off the piece to a lot of people.  It did eventually break, the last-minute walking staff adaptor breaking apart, and there was also some cracking around the planet gear frame and hub, but nothing that couldn’t be repaired on site.  Overall I consider it a successful design, especially considering how rushed the project was.

After this piece, I started working on a complete redesign.  Aside from the structural problems mentioned previously, this Nemesis Staff was too small.  Comparing the finished piece to the screenshots from the game, it came out about half the size it should.  It’s hard to tell exactly, since all character objects scale with the size of the character, but from comparing the picture of my wife to the images from the game, it’s clearly too small.

Scaling it up would make some of the mechanical parts easier to make, I’d have enough thickness for better axles and bearings.  In fact, with a bit of work, I could even fit motors and batteries in, and make it rotate. And if I was making it rotate, I might as well also install lighting and sound effects, to make it look and sound more like the actual weapon from the game.

Motors and bearings and working gears, and eventually lights and sound.

That fully working design has been put on hold for now.  I did enough modeling to determine that it would be practical, but haven’t done much more work than that for now.  If my wife wants to cosplay at a convention again, I’ll probably finish the design, but until then I have other more pressing projects to work on.

STL files for this have been posted at Thingiverse.

Monday, November 11, 2019

Building the Key of Aaravos


A few months ago, my wife and I binge-watched the first two seasons of The Dragon Prince on Netflix.  It’s a cute little cartoon show with some really good writing and well fleshed out characters, and with only 18 episodes so far it doesn’t take long to catch up on the whole thing.
In the show, there is a magical device initially referred to as the “Primal Cube” initially, though revealed in the second season to be more properly called the Key of Aaravos.



The Primal Arcanum Cube
aka
The Key of Aaravos

The cube has six sides, each with a symbol of one of the types of primal magic in the show, that lights up when in the presence of each type of magic.  After watching the show, I wondered if anyone had published 3D files of it for printing. A quick search on Thingiverse brought up a few results. I was considering printing one, but my wife pointed out that I should make one that lights up.  It shouldn’t be too hard, I thought. Just a few colored LEDs, right?

I downloaded one of the better Key of Aaravos files from Thingiverse to use for reference, but ended up redrawing everything essentially from scratch anyway. I tried to guess based on stills from the TV show just how large it was supposed to be, which was difficult as we really don’t know how large Callum’s hands are. I scaled the cube relative to my own hands, which may have resulted in a slightly oversized cube in retrospect - I have large hands.

To test how it would look, I split the cube into faces, and split the raised illuminated sections on each face into a separate section that would be printed in translucent plastic and pressed into the face pieces. I was lucky to have a reel of a beige color that fairly closely matched the color of the cube on the show, and a reel of ‘natural’ translucent PLA, both of which I had no other immediate use for. The test print, held up to the ceiling light for backlighting, revealed some issues with how light bled through both the transparent and the opaque plastics. Too much light was bleeding through the parts of the structure that were meant to be opaque, and the transparent parts didn’t look right either, but I was pretty sure I knew how to solve both issues.


Initial illumination test. Still needs a lot of work.

At this point, I needed to choose internal components, so I could design the final printed parts. My initial plan had been to simply grab some ultrabright LEDs in various colors, but I wasn’t sure I could exactly match the right shades of colors with easily available LEDs. It occurred to me that I might need to mix multiple colors of LEDs to get it just right. Fortunately, there’s an off the shelf solution for that. Neopixel LEDs have red, green, and blue LEDs along with a control chip all combined in one package, programmable through a serial data link that’s daisy-chained from one LED to the next. I had never worked with them before, and this would be a good excuse.

I decided to use one Adafruit Neopixel Ring, and one Neopixel Jewel, inside each face of the cube, for a total of 19 Neopixels in each. In retrospect, this was far more than I needed. I didn’t realize just how bright these things are, it actually hurts to look at the LEDs at full brightness without the printed faces over them.

Neopixels require a microcontroller to command them, something with enough memory and a sufficiently fast port for the required serial data signal. I had originally considered an arduino, but looking through the Adafruit catalog I noticed the Trinket M0, a remarkably small and inexpensive control board capable of running CircuitPython. I’ve been using Python for various projects for years on larger computers, and was surprised and somewhat skeptical that it was even possible to make it run on an embedded controller. I decided to try using it to control this project.

The cube would need a battery, for which I chose the 1200mAh Lithium Ion Polymer cell from Adafruit. I also chose the Adafruit Powerboost 1000 to act as a charger and 5V regulator. I’d used it on previous projects with success, and it would handle more than enough current to drive a single face at full brightness.

One problem was that while the Trinket M0 would accept 5V input power, it would only output 3.3V on its data pins, and the Neopixels really want the serial data signal to be at the same voltage as the power line. I added in a little bi-directional voltage level shifter to do the conversion from the Trinket to the Neopixels. It has four channels, but I’m only using one.

Being able to just buy simple drop-in breakout boards makes designing things like this so much easier. I remember back in the day, when I first started doing electronics, I would have to draw and etch my own circuit boards, ironing transfers onto bare copper boards and then carefully washing them in tubs of unsafe chemicals. These days, having companies like Adafruit that make everything available on breakout boards just makes everything so much easier.

With power and serial data control of the LEDs worked out, I needed a way for a person to indicate which side of the cube should light. Adafruit didn’t have any primal magic detecting sensor boards available, so I’d have to fake it. I considered building a separate remote control with buttons for each side of the cube, but I really wanted this to be a single-piece build. I also considered using a Bluetooth connection to control it from a cell phone, but that was more work than I wanted to spend on this project. Another idea was to use an accelerometer, and have the person holding the cube gesture or angle the cube a certain way to indicate which side to light. Awkward, but Adafruit did have an inexpensive accelerometer board available. Then I saw the 12 channel capsense board, and though that it might be possible for the cube to detect your hand and light the side opposite where it was being held by. I wasn’t sure if the capacitive sensing would work well enough, so I included the accelerometer anyway as a backup.
Final schematic and parts list



All of the parts were conveniently available from Adafruit. A few days later, and I had a pile of boards ready to start working with.


Always a nice day when my Adafruit order has arrived.

A test with a single side and just enough electronics to make it light up showed a bit more of a spotlight effect than I’d like, but it was acceptable.


Far brighter than expected.  I could probably have used fewer LEDs

Before doing anything further, I needed to do a detailed design of the interior. The structure ended up a lot more complex than I initially expected. Each face has a LED assembly consisting of one Neopixel ring and one Neopixel jewel, centered in a truncated pyramid which acts as a light baffle to block light from one side from bleeding into another. In the center is a roughly cubical space where most of the electronics go, although the Powerboost charger/regulator board and the Trinket needed to be arranged such that their respective USB ports were accessible from the outside of the cube. Fitting the battery in place was tricky, as it had to extend slightly into the diagonal spaces between the light baffles. The Trinket ended up having to go into a corner behind the Star arcanum space, as it was the only place it wouldn’t block any light.


Each edge of the cube needed to contain an antenna for capacitive proximity sensing. I experimented with a few different ideas before deciding to use strips of copper tape. The Adafruit Captouch board that I was using was really meant for touch sensing, but I needed to detect a person’s hands through some distance of plastic, since the electrodes wouldn’t be on the surface. I had a challenge in how to route the wires from the breakout board to each of the edge electrodes, as I wanted to route them away from potentially electrically noisy components in the center. I also wanted to keep the wires away from the outside to avoid incorrect sensing of user’s hand. This meant carefully routing the wires through carefully designed holes and channels inside the walls between faces, avoiding the battery charger and other components.

Capsense wires in red, fanning out to antennas on edges.

The segments of the core took about six hours to print each. There were a few iterations of the design, mostly as I figured out how to route the capsense antenna leads. The final design did make it difficult to install them, and results in them essentially stitching the pyramids together, but does keep them away from the LEDs and other electronics. These pieces were printed in black, with a high infill, to keep them opaque and prevent light from bleeding over from one side to another.

Printing core segments on my sweet custom Delta printer.

For the outer shell of the cube, I had a reel of tan filament on hand that was a near perfect match for the color of the cube.  I also had a reel of translucent ‘natural’ PLA which I’d been looking for an opportunity to use.  You can’t really print transparent parts with a printer like mine, but I was hoping I could get a decent frosted-glass look that would let the light through while also diffusing enough to prevent hot spots.

The initial test print showed several problems.  The plastic I chose for the shell just wasn’t opaque enough.  There was far too much bleed through when any bright light was behind it.  I had really underestimated just how bright the Neopixels were, and although I liked the brightness and how they illuminated the runes, I didn’t like how much bled through the parts that were supposed to be opaque.  The nice tan plastic that matched the color of the cube just wasn’t very opaque.

Too much light bleeding through the center.

I considered a few different options for making the faces block light better.  I considered lining the inside with dark tape, printing an inner shell out of black plastic, or even taping copper foil over the inside, which I briefly thought might have been required for proper capsense function.  The simplest solution - several coats of black spray paint - turned out to work very well.

Careful masking to keep the paint on the inside.

The other issue was the proper appearance of the translucent parts.  I discovered very quickly that the infill pattern would be highly visible due when illuminated.  I wanted the lit parts to look smooth and without pattern, which wasn’t really possible with a printed translucent part.  After a few experiments I found that printer settings with no infill, no top and bottom, but very high side wall thickness, worked the best.  This setting resulted in a part that was made up entirely of concentric shells.  When illuminated, the pattern was barely visible, and when not illuminated it had a shimmering, almost crystalline look that I really liked.

All six faces, with translucent parts inserted.

I had a challenge in figuring out how to attach the faces to the core.  I decided early on that I wanted it to be possible to completely disassemble the cube without breaking or cutting anything.  No glue or plastic-weld, it had to be fit together with fasteners.  For the initial design I had small wood screws hidden in the leaf detailing near the corners.   I built up a full prototype cube this way before deciding it was unacceptable.  The screw heads stood out far too well against the plastic, and the edges of the plastic faces tended to curl away from each other resulting in visible seams.  It looked terrible.


Unacceptable.  Time to re-think the design.

I went back to the drawing board on the faces, and ended up redesigning the core too.  I decided to attempt a friction interlocked, puzzle-box type design.  The faces would have edges that locked into each other in a way that was designed to hide the seam between faces from the viewer, breaking up the seam and hiding it in the detailing.  The resulting design relied on friction and interlocking geometry to attach the faces edge-to-edge.  The corners became separate pieces which were inserted after the faces were in place, to furner lock them together and pin them to the core.  The resulting design was surprisingly strong, had no visible screws or other fasteners, and did a good enough job of concealing the seams.  I could probably have done a bit more work to make the seams harder to see, but at this point I was getting tired of the project and was also running low on tan filament from having printed so many prototypes.

Of course, I had to completely re-print the core, since I had redesigned them to interlock with the corners and also to address some assembly issues found earlier. 

Much better.

With the design finished and all parts printed, it was time for the final build.  Assembling the core was difficult, as it’s very tightly packed in there.  All of the boards and other parts had pockets to hold them in place, and routes for wiring built into the plastic.  Everything had to fit in just exactly the right spots.

I even made mounting brackets to hold these four electrolytic capacitors, added to ensure a stable regulated voltage with the LEDs being PWM-switched.  These are almost certainly overkill electrically, but they were a convenient place to tie all of the 5V supply lines to.

First side of the core to be assembled.

The lithium-polymer battery is crosswise across the internal cubical space, as that’s the only place it will fit, and actually extends slightly into the space between faces.  Note the fanout from the capsense board.  Each antenna wire has its own channel in the plastic from the board to the antennas.  I hadn’t worked much with capacitive sensing before, and was worried about electrical interference and crosstalk, so I tried to keep each of the antenna wires away from the parts in the core.

Stitching the sides together with wire

Blue painter’s tape was used to hold parts in place temporarily until the rest of the cube was assembled around them.  The final steps of assembly were very tricky, as I was trying to carefully tuck wires and parts into pockets in the plastic as I closed the core parts up.

Almost there.  Just have to tuck these last wires in place.

The final wiring was installing the actual capacitive sensing antennas.  The wires from the capsense breakout board were each run out to one edge of the cube.  Initially I had planned to simply have metal rods running along each edge for the actual antennas, but that did not work well.  When using capacitive proximity sensing, the more surface area you have in your antenna, the more sensitive it will be.  I ended up using adhesive-backed copper foil along each edge, soldered to the antenna lead in the middle, and this gave me acceptable antenna sensitivity.  It did however slightly violate my initial goal of not having anything glued together, and if I ever want to disassemble the cube I’ll need to cut off the copper foil.
Taped together, but I'll live with that.

One thing that I was never completely happy with on this design was the charging port.  I needed to leave open a USB port where I could plug in a charger to charge the internal battery.  I couldn’t figure out a good place to integrate the charger into the cube’s design, and ended up just putting it behind one of the corners of the cube.  It’s not ideal, as you have to take the corner off to charge it, and the corner piece actually falls off easily as it’s not held in nearly as securely as the other corners are.  This would be something to think about if I ever decide to redo this design.

Not ideal, but where else am I going to put it?

This project was my first experience with embedded Python.  I’ve been programming in Python for years, but never tried the embedded CircuitPython version, and I was curious as to what you could actually do with it.

What I learned was that while it’s easy and fun to work with, and amazing that it works on such a small processor at all, CircuitPython is severely limited in its capabilities.  I was fighting with memory and processor speed limitations throughout this project.  Though it was a fun learning experience, if I had to do this again I’d just write it in C.

The code on this cube has to talk to three external devices:  the MPR121 capsense board, the LIS3DH accelerometer, and the chain of NeoPixel devices.  It also has to keep track of the state of 216 NeoPixels, and have unique animation routines for all six sides of the cube.  I discovered very quickly that the Trinket M0 running CircuitPython just doesn’t have the memory for all of this.  I couldn’t even load all of the libraries for the devices I was trying to talk to.  I ended up not using the LIS3DH library, instead using direct I2C access to read the accelerometer registers.  Along with careful pruning and optimization of my code, that got all of the functionality I needed to work.

For all the difficulty in getting it to work, the only thing that I ended up using the accelerometer for was to detect when the cube is being held.  I had originally planned to use a gesture-based system to select which side to light if I couldn’t get the proximity sensing to work.  I did ultimately get that to work, so the accelerometer is simply used as an on-off switch, to shut the cube off if it’s not being held.  The main loop polls the accelerometer and looks for changes in the readings, and only permits the lights to be on if there’s been enough change in the readings to indicate that the cube is being held.

The MPR121 capacitive touch board is really intended for touch sensing, with essentially no distance between the touch antenna and someone’s hand.  Unfortunately, I needed to have the foil antennas on the inside of the casing, with a shell of plastic between the antenna and the user’s hand.  With the initial settings, the sensors would almost never register contact.  With a bit of searching online, I found a register I could write to in the MPR121 that would increase the sensitivity enough to detect a hand at a distance.  This was also done with a direct I2C write, as the MPR121 driver did not include this function.

Glowy.

The code contains an animation engine which illuminates one side of the cube at a time, as determined by the location of the hand holding it.  Each side has a slightly different algorithm to generate the RGB values for the 19 LEDs making up the face, with a random effect to make a unique shimmering appearance for each side.  I tried to match the appearances to the arcanum runes shown on the show, although I had to completely guess for the Star and Earth runes as they haven’t been shown on the show yet.  There is also a ramp function, so that the sides will gradually fade in and fade out as needed.



The resulting cube probably runs for a few hours continuously, which should be enough for doing cosplay at a convention, if I was inclined to do that.  The truth is, I don’t really do cosplay, and mostly built this just as a learning experience.  Building the cube was educational and fun, but I’m not really sure what if anything I’ll be doing with it now.


Came out pretty well.  I think this is about the best match I can get, considering the materials and parts I have to work with.

I have posted all the files needed to re-create this, including the schematic and Python code, on Thingiverse at https://www.thingiverse.com/thing:3970763.

Sunday, July 19, 2015

Papercraft Pluto, and a papercraft planet pattern generator

Several years ago a friend of mine asked me to make a program for mapping a globe onto a twenty-sided die.  I wrote a simple Python script, some basic coordinate remapping and image processing with a simple GUI wrapped around it.  The script takes an image that's a flat projected map of a planet, builds a virtual icosahedron around it, projects the image of each part of a globe onto the faces of the icosahedron, and then arranged them on an output image along with fold lines and glue tabs where needed.

Other than sending it to the friend who requested it I didn't do anything else with the software until the recent flyby of Pluto by the New Horizons probe.  Seeing the images coming down I thought I'd try to make a papercraft globe of Pluto, once good surface maps were available.  The 20-sided shape that my script generated was a crude approximation of a globe, so I reworked it to generate an 80-sided geodesic that better approximates a sphere.

You can download the finished Python script here.  You will need Python 2.7.8 to run it, and you will also have to install the Python Image Library.  The program should be fairly self-explanatory.  There are buttons to load the source file, and save the finished destination file.  You can adjust the scale - by default it makes the output file have about the same DPI as the image file, but you may want to scale it up if working from a low-resolution image.  You can turn the glue tabs off if you wish, and set the color for the fold lines and cut lines.


There are also three sliders which are used to optionally rotate the pattern relative to the globe.  This is helpful if you want to arrange it so that some feature of the globe isn't on a cut line or vertex.

I'm still waiting for a good global map of Pluto to use.  So far the best I've found was unofficial and incomplete, but I was able to use it to make this:





(you can download the pattern to make your own here)  Once better imagery has been downloaded and released I'll put together a better globe.  But you don't need to wait, you can download the script and make your own.

7/29/2015 update:  I found a better surface map here and used it to make a higher resolution papercraft model.

Monday, June 8, 2015

Building my PSP (PiStation Portable) Retropie gaming station.



After seeing this project on Thingiverse, I decided to build my own portable Retropie gaming console.  It looked easy enough to do, there were software builds available ready to install on a SD card, and it would be an excuse for me to gain more experience with Linux and on the Raspberry Pi.  Of course, I couldn’t just build the existing design as-is, eventually redesigning the entire case for the features I wanted.  I really wanted to improve the ergonomics and packaging efficiency of the design, to make something that would fit well in my hands and be easy to play and that wouldn’t be any larger or heavier than absolutely necessary, something that I could sit and play on a long car or train ride for hours without getting hand cramps.  I also wanted some features lacking on the designs I saw, including built-in battery charging, headphone jack, and a USB port available for loading ROMS.

I designed the printed parts in Solidworks.  I've been slowly teaching myself Solidworks over the last half a year, after finally getting completely fed up with the terrible 3D drawing capabilities of AutoCAD.  AutoCAD is a fine 2D drafting program, but a terrible 3D drawing program, and I'd been hitting against its limitations for a while.

Of course, I bought the original parts for this project about a week before the Raspberry Pi 2 was announced.  The Pi 2 would have made certain parts easier, having more processing power, more convenient mounting holes, and more USB ports, but I decided to press ahead with the parts I already had rather than start over with new parts.  If I build another one of these, I’ll redesign it for the Pi 2.

Nearly all of the parts came from Adafruit, the main exception being the video screen which is a cheap car backup camera.  The screen claims to need a 12V input, but I found that it runs just fine on 5V - the 3.3V switching regulator on the screen interface PCB still handles the lower voltage.  It does get a bit warm, and I suspect that there are parts in the regulator that are running more current that intended at the lower voltage.

I initially was going to use the same cheap multi-color membrane pushbuttons that everyone seems to use, but after trying them didn’t like the way they felt.  Too stiff and too clickey for my tastes.  I decided to use these slightly more expensive illuminated mechanical pushbuttons instead.  They cost more and take up a lot more space behind the panel, but they have a really smooth action and actual mechanical contacts inside instead of a membrane switch.  Being illuminated in a range of colors was a nice added cosmetic bonus.  I’m still using one of the membrane buttons for a control mode switch, and intend to use a second for a power switch once I get the soft power circuit working.

The controls are all managed through a Teensy 2.0 acting as a joystick/keyboard USB device.  The Raspberry Pi doesn’t have analog input, and I wanted an analog joystick, so the USB solution was the easiest way to go.  

I originally had a design involving 2 analog joysticks plus a D-pad and about a dozen buttons before coming to my senses and realizing that a single joystick and 8 buttons were enough for any game I’d be emulating.

There is one additional button not being directly used by the joystick.  This button is an input to the Teensy which changes its mode from a joystick to a keyboard.  When in keyboard mode, the joystick is mapped to arrow keys, and the buttons are mapped to a handful of selected keyboard buttons:  escape, return, tab, and some of the function keys.  This lets me navigate the setup menus and file transfer utilities without having to plug in an external keyboard.  The second USB port on the Pi is still accessible from the outside of the case, so I can still plug a keyboard in if I need to.  Mostly the external USB port is to be used to transfer game ROMs with a USB thumb drive.


Originally I planned to use a large 5V USB power pack for power.  This did not work out well.  These battery packs are designed for charging cell phones and don’t like to be used for other purposes.  The output protection circuit trips very easily, I wasn’t able to get it to play nice with a Mausberry soft power switch, and trying to use an audio amplifier to power speakers would trip the battery off when any loud sound played.  The voltage output from this pack is badly regulated, the screen would flicker as the voltage varied and there was a lot of noise in the audio from the Pi when using it.  It was also impossible to play games while charging the battery - when the charger was active the voltage output would get very low and erratic, the screen would flicker and the audio buzz, and plugging or unplugging the charge cord would cause a momentary power interruption that would reset the Pi.  










That battery pack was also a giant inconvenient brick that I had trouble fitting in the case.  

 After several frustrating weeks trying to get it to work I switched to a discrete battery and power boost /charger board, which works much better.












I still haven’t managed to get a soft power function working, with power on via button and power off automatically after shutting down Linux. The Mausberry doesn’t seem to have any easy way to work with the boost/charger board, so I’m working on my own latch circuit that uses the enable pin on the boost regulator.  It shouldn’t be hard to get to work, but until then I’m just using a toggle switch for manual power control.

The audio noise went away when I changed the battery, but the audio quality is still not great.  This is mostly due to the default audio output on a Raspberry Pi being rudimentary at best, but also apparently partly due to the game emulators not being quite powerful enough to smoothly reproduce the audio output on some of the consoles.  The SNES is especially bad, when there is a lot of movement on the screen the audio output gets really choppy.  If I really cared I could install a HifiBerry I2S plugin board, and then overclock the Pi to better handle SNES emulation.

I went through a lot of design iterations getting the shape right.  I wanted something that I could print in as few pieces as possible, with controls that were comfortable for my large adult man hands.  Widely spaced mechanical buttons and an smoothly-acting analog joystick won out over a D-pad and membrane buttons, even if it made the wiring and placement harder.  I struggled with getting everything to fit until I decided to solder the video, power, and USB connections directly to the Raspberry Pi board rather than use the provided connectors.  This saved a tremendous amount of space, especially for the composite video feed, although it means the Pi isn’t likely to be re-used for another project now.


The other breakthough on the design was having the video screen front panel outside the printed case.  I figured that it had a nice-looking front bezel already, so why not use it as-is?  Fitting the screen outside the case rather than wrapping the case around it saved space and made the packaging easier.  With directly soldered connections to the Pi I was able to fit the Pi, Teensy joystick board, battery, and power boost/charge board entirely in the space behind the screen.  That just left small extensions on either side for the joystick and buttons.  This was the point that I decided on the “PiStation Portable” name.  I hadn’t originally intended to model it after a PSP, everything just came together that way.  Ironically PSP games are quite hard to emulate, well beyond the capabilities of a Raspberry Pi.


The end result is quite compact and comfortable to hold, and I was just barely able to print the front and back halves as single pieces on my 3D printer.  It was very tight - the case is about 237mm wide at the widest point, and my printer has a 250mm diameter circular print area, so it was coming really close to the edges of the print space.  It did take several tries to get the back case to print successfully, it has some really difficult overhangs.






I’m running a standard copy of Emulationstation 2.6 on an 8gb flash drive.  I know that 3.0 is out now, but it looks like changing over to that will mean having to replace all of my ROMs from scratch.

So far I have Atari 2600 games working very well.  I found a ROM pack of what appears to be every 2600 game ever made and installed it - they only take up a few kilobytes each, so I had plenty of room.  Most of them haven’t aged well, but I do still enjoy Yar’s Revenge.  I have managed to get the Gameboy and Gameboy Colors emulators to work, but Gameboy Advance emulation still doesn’t work.









NES emulation seems to be the sweet spot for this design - there are a lot of fun games available, and the Pi emulates the NES very well.  













SNES emulation works, but the framerate suffers at times and the audio is choppy.  Getting MAME working will be my next goal, I should be able to play a lot of the older classic arcade games on this.

The only remaining hardware changes I intend to make to this one are to try to figure out a soft power switch as mentioned above, and to add a low battery light to the front panel.  There is a low battery light on the power management board, but it’s shining out the back of the case at the moment.  I need to find a spot to put another light visible from the front, so I have some warning to save my game and shut down before the battery dies.

If I had to do this over from scratch now, I’d start with a Raspberry Pi 2.0.  More USB ports, faster processor, better audio circuitry, and a more compact SD card slot.  It would mean a significant redesign of the case, and probably different wiring for the video and audio connections.  I’d also try to fit miniature speakers in somehow, so I could at least have some sound without having to plug in headphones.  An amplifier board and volume control would also be nice - the full volume output of the Pi is still fairly quiet.  The joystick/keyboard mode switch should probably be a small slide switch instead of a button, but other than that the ergonomics are perfect.



Plans, such as they are, are posted here.