• Hat Design

    avishorp11/27/2016 at 22:07 0 comments

    The hat design was particularly challenging. The hat has to be small enough to be comfortably worn, it should sit tightly on the head, allowing the person wearing it to move freely and to fit on many head sizes.

    I used rubber head straps from a cheap LED headlamp. After testing several design, I ended with a tight 3D printed housing for the PCB and the bettery mounted on top of a curved head pad (also 3D printed). On the side facing the head, I glued a piece of soft foam to make wearing it a little more comfortable and to absorb the hits. The two parts (hosing and head pad) were glued together with the rubber strap passing between them. The following drawing illustrates that:

    Let's have a more detailed look at the construction:

    On the lower side, the head pad (2) and the base (3) are glued together, with the head strap (1) passing between them. In the original design, these parts were supposed to be connected using magnets, but that design was not strong enough to withstand the hits. On the upper side, we see the semi-transparent dome (4) on which the Piezo sensor is mounted and the tab (5) that is put on to of that, to extend the hit area. They are all glued together. The circuit (6) is mounted on the bottom side of the dome. It is lightly glued, just to make it easy to disassemble - the circuit is pressed between the base and the dome.

    The two parts - the upper and the lower - are connected with two M3 screws which can be disassembled to gain access to the battery.

    Here's how the final result looks like:

  • Hammer Design

    avishorp05/30/2016 at 14:39 0 comments

    The hammer is assembled from 4 main parts:

    1. The hammer head.
    2. The PCB assembly
    3. End pads (x2)
    4. Handle

    The hammer head is 3D printed. It's designed as a hollow, T-shaped cylinder with rails that hold the PCB and the pads in place. It was printed from transparent ABS which was also acting as a diffuser. The PCB assembly includes the PCB and a 2xAAA battery housing, attached to it using VHB strip.

    The most interesting and complex part is the end pads. They include a 3D printed base plate surrounded by potted RTV, which gives its softness. Half of the pads also include a piezo transducer embedded inside the RTV.

    The handle is cut from a wooden broom handle.

    This is the end pad base-plate. It has a place for the piezo sensor assembly, and bridges, under which the RTV would flow and hold to the part.

    The end cap base plate, with Piezo sensor

    The potting of the RTV. The blue pads indicate that there's a piezo sensor inside, white are inert.

    Molding the RTV

    The final end pads.

    Assembly of the hammers

    And here's he final product:



  • The Circuit Board

    avishorp05/29/2016 at 05:54 0 comments

    Circuit Design

    As mentioned in a previous post, the circuit board is designed to be shared between the hammer and the hat, thereby reducing the design effort.

    The main component is, of course, the WiFi Micro module. It does all the heavy lifting of processing and communication. The module is connected to the main board using two single row, .100" spaced header connectors. Beside the module there are drivers for the RGB LEDs (there are four LEDs mounted at the corners of the board), a power supply circuit and an accelerometer.

    The circuit is designed to be powered by a pair of AAA batteries. This gives us a nominal operating voltage of 3.2V - 2.4V. Luckily, the CC3200 chip on the WiFi Micro module is designed exactly to work in such a voltage range, so it is connected directly to the battery power input. The problem arises with the LEDs. Some of them have very high Vf, approaching 3V, making them hard to drive directly from a 2xAAA setup. Therefore, I included a step up booster on the board, based on TI ???????. This chip is completely integrated with the power switch, it only needs an inductor and couple of capacitors.

    The accelerometer, ?????, is also quite simple, also capable of being directly powered by a pair of AAA batteries and connecting to the WiFi module via an SPI bus. I did include a jumper resistor, for disconnecting it from power completely, since I was not sure I would be able to assemble it. The power supply also has jumpers in the input and in the output, to ease testing and debugging.

    PCB Design

    The PCB design is pretty straight forward. It's size is 70x40mm, making it cheap to fabricate in common 100x100mm slice offered by Chinese manufacturers. The WiFI Micro connectors are on one of the short edges of the board and the four LEDs are mounted in the four corners. I opted for TH LEDs, because I had to mount them on both sides of the board, and that is hard to achieve in home reflow process (in retrospective, that was not a wise decision; soldering those LEDs manually consumed a lot of time).

    The PCB is relatively sparse and there were no notable routing or placement challenges.




    Assembly

    Having to assemble ~20 boards, reflow soldering was a natural choice. This is the first time I was doing such a procedure, and overall, it went pretty well.

    The one exception was the soldering of the tiny accelerometer. As I anticipated, it was pretty hard. It started with the application of the solder paste which smeared around the tiny pads, the placement of the component without a proper microscope and finally - checking whether the soldering was successful. After a few failed attempts, I understood that It's not going to work the tight schedule and decided to give up on the trials and back off the the backup plan - using piezo sensors for hit detection.

  • Hit Detection

    avishorp05/24/2016 at 21:41 0 comments

    In the project context, the term "Hit Detection" has two separate meanings. The first, trivial one is the method for detecting that a unit (hammer or hat) has been physically hit. The second, trickier one is how to detect which hammer hit which hat.

    Physical Hit Detection

    The problem of physical hit detection has been addressed many times. Two of the methods I considered are using an accelerometer and using a piezo sensor.

    An accelerometer can easily detect a strike as an acceleration spike. Among its advantages is the ease of handling a hit coming from different direction (for example, a hammer can be hit from both ends) and the fact that when it's mounted on a PCB, no wiring to external sensor is required. In the constraints of this project, namely time frame and price, this approach had one major drawback - the assembly. Accelerometers come in tiny, fine pitched packages. The one I selected for this project, LIS2HH12, is perfect from the technical aspect and rather cheap (everything comes in multiples of 20, so a 5$ sensor is out of the question), but is housed in a 0.5 pitch, 2x2mm QFN. Soldering such package at home is challenging, so I had to prepare a fallback option, in case I would encounter such problems. Eventually, this is exactly what happened. Almost none of those chips were assembled successfully, so I had to cut their current (I prepared a jumper resistor for that).

    A piezo sensor is much simpler device. When it is exposed to force, it generates a voltage pulse that can be picked up by the processor. A disadvantage of the piezo sensor is its directionality - the force has to come from specific direction, otherwise it will not be sensed. It is also much more challenging for installation. I will elaborate on that point on a project log describing the hammer mechanical structure.

    Eventually, as I already mentioned, I had to go in the piezo path, due to the failed accelerometer assembly.

    Hit Identification

    The game include a set of hammers and a set of hats. The basic capability required from the system is to detect which of the hammers hit which of the hats.

    When thinking of such a problem, RF proximity technologies, such as NFC and RFID come immediately in mind. NFC (at least passive one) is not suitable due to its long operation time (detection can take 100s of milliseconds). As to RFID - I didn't have any knowledge of that technology or experience with it, and I could not afford to take the risk.

    Rather, I took a completely different approach - temporal proximity. The idea is simple. When a hammer hits a hat, they both sense the hit at the same time. When they report to the management computer that they've been hit, they attach a timestamp designating the exact time it happend. When the management computer receives two hits that occurred at the time - it may conclude that theses two units hit each other. If the timing is fine grained enough (milliseconds), the probability that two different hits (two hammers hit two hats) occur at the same time is low. This scheme assumes one important thing - that all the units share the same timebase. Without this, there is no point for comparing timestamps. The way this requirement was met will be discussed later.

  • System Design

    avishorp05/22/2016 at 13:29 1 comment

    The system comprises of three elements:

    • Hammer - The unit held by the player's hand.
    • Hat - The unit the player wears on his/her's head.
    • Management Computer - A computer managing the game. It is connected to a scoreboard, showing live player score and status.

    All the units connect on a private WiFi network. The endpoint units (hammers and hats) contain a WiFi embedded module, and the management computer, which can be either a Raspberry Pi or a PC acts as as an access point. The management computer is also responsible for managing the scoreboard, which is currently implemented as a graphic screen on the video output, which is presented to the players through a large screen TV or a projector.

    Endpoint units

    There are two types of endpoint units - hammers and hat. Even though they differ in their form and role in the game, they are very similar in their electronic functionality. An endpoint should be:

    • Powered by a battery
    • Able to connect to a WiFi network
    • Able to change its color
    • Able to sense a hit

    The commonality between the endpoint types suggests that they can share one electronic design and one printed circuit board type.

    The ability to change colors is easily accomplished by RGB LEDs. It should be noted that it is not strictly required that the hammer color should be changeable - it could be simply painted with some fixed color (the color of the hammer does not change during the game). I chose to make it dynamic mainly for the flexibility of unit replacement - if a unit fails, it can be easily replaced be a different one without worrying about making it have the correct color.

    The battery requirement is trivial, but battery selection is not. The first intent was to operate all the endpoint units from non-rechargable, double AAA battery. The reason is that I didn't want to spend time on charging batteries, and there are a lot of them! In practice this design choice has been proven wrong for several reasons. I'll devote a separate project log for that.

    WiFi Connectivity

    When WiFi connectivity requirement is raised, ESP8266 is an immediate contender. In this project I chose to take a different route and selected the TI CC3200, mounted on a board called WiFi Micro, made by RedBearLab. The CC3200 is a powerful WiFi integrated microcontroller. It has much more I/O and features than the ESP8266, but is also much more expensive. Thankfully, the great folks at RedBearLab agreed to give me those boards with substantial discount, showing a continuous support in Open Source projects.

    The last requirement, namely hit detection, is somewhat tricky. I'll devote a separate project log to discuss it.