Chordata motion capture dancer and 3D model

A Motion Capture System For Everyone

September 24, 2018 by Steven Dufresne 23 Comments

[Chordata] is making a motion capture system for everyone to build and so far the results are impressive, enough to have been a finalist in the Hackaday Human Computer Interface Challenge. It started a few years ago as one person’s desire to capture a digital performance of a dancer on a stage and has grown into a community of contributors. The board files and software have just been released as alpha along with some instructions for making it work, though more detailed documentation is on the way.

Fifteen sensor boards, called K-Ceptors, are attached to various points on the body, each containing an LSM9DS1 IMU (Inertial Measurement Unit). The K-Ceptors are wired together while still allowing plenty of freedom to move around. Communication is via I2C to a Raspberry Pi. The Pi then sends the collected data over WiFi to a desktop machine. As you move around, a 3D model of a human figure follows in realtime, displayed on the desktop’s screen using Blender, a popular, free 3D modeling software. Of course, you can do something else with the data if you want, perhaps make a robot move? Check out the overview and the performance by a clearly experienced dancer putting the system through its paces in the video below.

As a side note, the latest log entry on their Hackaday.io page points out that whenever changes are made to the K-Ceptor board, fifteen of them need to be made in order to try it out. To help with that, they show the testbed they made for troubleshooting boards as soon as they come out of the oven.

Continue reading “A Motion Capture System For Everyone” →

Doing Logic Analysis To Get Around The CatGenie’s DRM

September 4, 2018 by Steven Dufresne 53 Comments

The CatGenie is an amazing device to watch in action, basically a self-cleaning litter box for cats that even does away with the need to replace the litter. It’s comparable to what the indoor flush toilet is for humans compared to maintaining a composting toilet. However, there is a problem. It uses costly soap cartridges which have to be replaced because an RFID reader and a usage counter prevent you from simply refilling them yourself.

[David Hamp-Gonsalves] reverse engineered the electronics so that he didn’t have to pay for the cartridges anymore. This has been done before and one of those who did it created a product called the CartridgeGenius, but it’s made and sold as a parttime project and there were none in stock. The cartridges have an RFID tag and another solution which we’ve covered before is to replace the RFID reader board with an Arduino. That’s the solution [David] adopted. So why write this post if this isn’t new?

The RFID reader board communicates with the rest of the CatGenie using I2C and he needed to know what was being transmitted. To do that he learned how to use a cheap logic analyzer to read the signals on the I2C wires, which makes this an interesting story. You can see the logic analyser output on his blog and GitHub repository along with mention of a timing issue he ran into. From what he learned, he wrote up Arduino code which sends the same signals. He and his cat are now sitting pretty.

What he didn’t do is make a video. But the CatGenie really is amazing to watch in action as it goes through its rather complex 30-35 minute process so we found a video of it doing its thing, shown at 3.5x speed, and included that below. If you’re into that sort of thing.

Continue reading “Doing Logic Analysis To Get Around The CatGenie’s DRM” →

Dual Brushed Motor Controller Doesn’t Care How It Receives Commands

July 18, 2018 by Ben James 3 Comments

The simple DC brushed motor is at the heart of many a robotics project. For making little toy bots that zip around the house, you can’t beat the price and simplicity of a pair of brushed motors. They’re also easy to control; you could roll your own H-bridge out of discrete transistors, or pick up one of the commonly used ICs like the L298N or L9110S.

But what if you want an all-in-one solution? Something that will deliver enough current for most applications, drive dual motors, and deal with a wide range of input voltages. Most importantly, something that will talk to any kind of input source. For his Hackaday prize entry, [Praveen Kumar] is creating a dual brushed motor controller which can handle a multitude of input types. Whether you’re using an IR remote, a Pi communicating over I2C, an analog output or Bluetooth receiver, this driver can handle them all and will automatically select the correct input source.

The board has an ATmega328p brain, so Arduino compatibility is there for easy reprogramming if needed. The mounting holes and header locations are also positioned to allow easy stacking with a Pi, and there’s a status LED too. It’s a great module that could easily find a place in a lot of builds.

If you need even more control over your brushed motor, you can soup up its capabilities by adding a PID loop for extra smarts.

A Crash Course In Reliable Communication

June 14, 2018 by Tom Nardi 21 Comments

It’s probably fair to say that anyone reading these words understands conceptually how physically connected devices communicate with each other. In the most basic configuration, one wire establishes a common ground as a shared reference point and then the “signal” is sent over a second wire. But what actually is a signal, how do the devices stay synchronized, and what happens when a dodgy link causes some data to go missing?

All of these questions, and more, are addressed by [Ben Eater] in his fascinating series on data transmission. He takes a very low-level approach to explaining the basics of communication, starting with the concept of non-return-to-zero encoding and working his way to a shared clock signal to make sure all of the devices in the network are in step. Most of us are familiar with the data and clock wires used in serial communications protocols like I2C, but rarely do you get to see such a clear and detailed explanation of how it all works.

He demonstrates the challenge of getting two independent devices to communicate, trying in vain to adjust the delays on the receiving and transmitting Arduinos to try to establish a reliable link at a leisurely five bits per second. But even at this digital snail’s pace, errors pop up within a few seconds. [Ben] goes on to show that the oscillators used in consumer electronics simply aren’t consistent enough between devices to stay synchronized for more than a few hundred bits. Until atomic clocks come standard on the Arduino, it’s just not an option.

[Ben] then explains the concept of a dedicated clock signal, and how it can be used to make sure the devices are in sync even if their local clocks drift around. As he shows, as long as the data signal and the clock signal are hitting at the same time, the actual timing doesn’t matter much. Even within the confines of this basic demo, some drift in the clock signal is observed, but it has no detrimental effect on communication.

In the next part of the series, [Ben] will tackle error correction techniques. Until then, you might want to check out the fantastic piece [Elliot Williams] put together on I2C.

[Thanks to George Graves for the tip.]

Continue reading “A Crash Course In Reliable Communication” →

General Purpose I/O: How To Get More

June 14, 2018 by Inderpreet Singh 28 Comments

The first program anyone writes for a microcontroller is the blinking LED which involves toggling a general-purpose input/output (GPIO) on and off. Consequently, the same GPIO can be used to read digital bits as well. A traditional microcontroller like the 8051 is available in DIP packages ranging from 20 pins to 40 pins. Some trade the number of GPIOs for compactness while other devices offer a larger number of GPIOs at the cost of complexity in fitting the part into your design. In this article, we take a quick look at applications that require a larger number of GPIOs and traditional solutions for the problem.

A GPIO is a generic pin on an integrated circuit or computer board whose behavior, including whether it is an input or output pin, is controllable by the user at runtime. See the internal diagram of the GPIO circuit for the ATmega328 for reference.

Simply put, each GPIO has a latch connected to a drive circuit with transistors for the output part and another latch for the input part. In the case of the ATmega328, there is a direction register as well, whereas, in the case of the 8051, the output register serves as the direction register where writing a 1 to it sets it in output mode.

The important thing to note here is that since all the circuits are on the same piece of silicon, the operations are relatively fast. Having all the latches and registers on the same bus means it takes just one instruction to write or read a byte from any GPIO register.
Continue reading “General Purpose I/O: How To Get More” →

Automatic I2C Address Allocation For Daisy-Chained Sensors

May 23, 2018 by Jenny List 23 Comments

Many readers will be familiar with interfacing I2C peripherals. A serial line joins a string of individual I2C devices, and each of the devices has its own address on that line. In most cases when connecting a single device or multiple different ones there is no problem in ensuring that they have different addresses.

What happens though when multiple identical devices share an I2C bus? This was the problem facing [Sam Evans] at Mindtribe, and his solution is both elegant and simple. The temperature sensors he was using across multiple identical boards have three pins upon which can be set a binary address, and his challenge was to differentiate between them without the manufacturing overhead of a set of DIP switches, jumpers, or individual pull-up resistors. Through a clever combination of sense lines between the boards he was able to create a system in which the address would be set depending upon whether the board had a neighbour on one side, the other, or both. A particularly clever hack allows two side-by-side boards that have two neighbours to alternate their least significant bit, allowing four identical boards each with two sensors to be daisy-chained for a total of eight sensors with automatic address allocation.

We aren’t told what the product was in this case, however it’s irrelevant. This is a hardware hack in its purest sense, one of those which readers will take note of and remember when it is their turn to deal with a well-populated I2C bus. Of course, if this method doesn’t appeal, you can always try an LTC4316.

Push It To The Limit: SSD1306 At 150 FPS

May 8, 2018 by Tom Nardi 38 Comments

A good deal of the projects we cover here at Hackaday are not, in the strictest sense, practical endeavors. If we required that everything which graced our digital pages had a clear end result, the site would be in a rather sad state of affairs. Sometimes it’s enough just to do something for the challenge of it. But more often than not, you’ll learn something in the process which you can use down the line.

That’s precisely what pushed [Larry Bank] to see how well he could optimize the frame rate on the popular SSD1306 OLED display. After several iterations of his code, he was able to achieve a blistering 151.5 FPS, with apparently still some room for improvement if he’s feeling up to the challenge. But considering his first attempt was only running at 5.5 FPS, we’d say he’s already more than earned his hacker cred on this one.

A few different tricks were used to achieve such incredible performance gains. To start with, while the official I2C specification says you’re supposed to wait for an acknowledgment back from the device when communicating with it, [Larry] realized the SSD1306 didn’t actually care. He could continuously blast commands at the display without bothering to wait for an acknowledgment. He admits there are problems with this method, but you can’t argue with the results.

To really wring all the performance out of the system he could, [Larry] donned his Assembly Cap and examined how the Arduino IDE compiler was interpreting his code. He identified a few areas where changing his C code would force the compiler to generate faster output. He notes that this wouldn’t normally be required when working with more advanced compilers, but that the Arduino toolchain needs its hand held occasionally.

This isn’t the first time we’ve seen somebody try and push more pixels through the very same OLED display, and it’s interesting to see the two very different approaches to the same goal.