12/11/2017 at 20:32 •
It's been a while since I don't post any update here.
Last month we were very busy in the making of a better looking prototype to be shown on this year edition of the Maker Faire, here in Rome.This new prototype really shows the potentialities of the system, even tough several adjustments and calibration procedures should be still implemented.
Public's response was really positive and several people showed interest in accessing to a cheap and hackerable mocap system. This response convinces us on putting more effort on its development.
We also received some exciting collaboration proposals so perhaps we'll have some interesting announcements to make on the incoming weeks.
11/09/2017 at 18:22 •
I finally have all the parts to start building a second and more complete version of the system. The PCBs, stencil, and components were already arrived some time ago, but the solder paste kept me waiting for a long time, if you want to hear the whole story, please refer to The solder paste odyssey.
If everything goes right I should be able to build at least twelve of the sensor nodes, and arrange my first whole-body capturing suit.
The problem: apart from the general refactoring that I’m performing on the code, I will have to implement the lecture of the LSM9DS1 instead of the LSM9DS0 from the previous board. Fortunately sparkfun offers a library for arduino, which can be easily adapted to this system
The real problem: home soldering 12 of these units with their tiny LGA packages, represents 12 one-shot opportunities... of getting it wrong.
10/19/2017 at 19:14 •
As I said, it was time to make a second version of the PCB in order to be able to build a complete body suit. I’ve called it “K-Ceptor” (Kinetic perCEPTOR).
The changes are detailed on the previous log entry, and listed here:
- Changed the LSM9DS0 for the LSM9DS1
- Added an address translator and removed multiplexer
- RJ-12 connector for both input and output (or optionally solder a regular 2,45mm header)
- An EEPROM memory
One thing that I hadn’t planned for (it came out while I was making this new pcb) was to arrange some of the components on a separate board: the “id_module”.
This module is a tiny, one-layered pcb, containing the EEPROM, some resistors to setup the translation value of the LTC4316 (i2c address translator).
This separation allows for greater flexibility and hardware resources reutilization. For example, suppose some user has a complete suit and, at some point, he is using it for two different activities taking place in different environments, namely: a capture for an animation performed outdoors and the rehearsals of a live performance in a theater. Since the electromagnetic interference on each location is completely different, the ideal would be to perform a calibration* on each sensor at least once for each place. Having a duplicate set of cheap id_modules would allow the user to easily apply the corresponding calibration before each use.
(*) again: I'm talking about the sensor calibration, not to be confused with the pose calibration which should be performed before every capture.
A render of the id_module stacked in position, on top of the K-Ceptor.
10/03/2017 at 09:04 •
Here's a video showing the current state of the capture. This 3 sensor prototype it's with what I've been working on in the last months, even if it's not as spectacular as a whole body capturing suit, it allowed me to easy test the features as they were implemented.
The focus on this part of the development was put on:
- General stability of the program.
- Capability for reading sensors arranged on any arbitrary disposition (or hierarchy).
- Obtaining readings of each of the sensors at a regular interval, no matter in which part of the hierarchy it was.
- Capability for reading a single sensor on the hierarchy, process it's raw data and generate calibration information. Dump this information to a file.
- Implementing a correction step for each sensor, with data obtained on a previously done calibration, before the sensor fusion.
The Imu-Proto sensor unit,
physical base of the prototype is simple pcb featuring a IMU sensor, and an i2c multiplexer. The idea was that this units should be easily interconnected allowing the creation of tree shaped hierarchies. So it had a 4 pin input and output carrying the current, and the i2c bus. It also exposed pins for the secondary gates of the multiplexer.
This arrangement was great for testing, but now I'm working on the creation of more user-friendly version of the sensing unit, which will have the following features:
- -Lack of a multiplexer which will be on a separate unit, and instead implement an address translator.
The multiplexer works fine, but it wasn't really used on all nodes, in the other hand it added unnecessary overhead to the bus, having to switch it for each sensor before the reading. Instead having it on a separate unit will allow a more flexible creation of arbitrary trees.
- An easy pluggable connector.
Of course, having to solder 4 wires in order to create the suit wasn't flexible at all. This connector should allow the performer to freely move while keeping the connection stable, should be cheap and common, and not excessively bulky. At the moment I'll go with the RJ-12 connector (the one regular telephones use).
- An on-board memory.
The main function of this memory will be storing the sensor calibration data. This calibration should only be performed once in a while*, and until now the generated data was stored on a file in the Hub, not allowing a particular sensor to change Hub, or position on the hierarchy.
(*) I'm talking about the sensor calibration, not to be confused with the pose calibration which should be performed before every capture.