Chordata is an action capture system you can build yourself, which is an open hardware-software framework based on the inertial sensor, and anyone can use it to build a human sports capture system. Its goal is to capture the world into the DIY technology field by open hardware methods.
List of this project:
You can understand all the contents of Chordata by the following info:
Why choose chordata?
The origin of ChORDATA is a basic demand. Bruno I want a method to inject dance actions for performance fragments, but there is no useful tool in line with his needs (nor does it comply with his budget). Now this system is open (as a beta version) and can find a large number of documents on the above websites.
The following is the original description of this project, mainly to record this item because it is written when the main part of the system is being developed.
Original description of the project:
The project consists of three parts:
Hardware (K-CEPTOR):
The action capture refers to the direction of each limb or part as accurately as possible. A simple MEMS IMU device and the freely provided sensor fusion algorithm are sufficient to get good results. When you want to get the data of multiple devices, the problem is coming. Most of these devices have an I2C interface, but their addresses are fixed in hardware. Therefore, one of Chordata's build modules is the sensing unit that can coexist with several "brothers" on the same bus: "K-CEPTOR" is composed of LSM9DS1 IMU and LTC4316 I2C address converters.
While developing and prototyping, the internal manually welcoming a lot of such a circuit board is handled, so that the SMD element as possible per board makes this process easier.
Software (NOTOCHORD):
Get the data of a large number of sensors in real time, process it, and send it to a client with easy-to-read format is not a simple job, so you need to develop a software from steps to handle it. And this software is responsible:
Build a digital model of the physical level of the sensor. Initialize I2C communication on the hub and run configuration routines on each sensor;
Perform reading of each sensor with the specified refresh rate;
Deviations obtained using the previous calibration process corrected each sensor reading;
The sensor fusion is performed on the calibrated sensor reading, and the absolute direction information is obtained in the form of a quad number;
Use an open protocol (such as OSC) to send direction data to the Sensor_ID and timestamp to the client.
After multiple tests, it is found that the single board computer running Linux is the best choice for hosting such a program, so all the development of this part of the software is done on C ++, using the Raspberry PI 3 as the hub. Some advantages of this type of hub compared to the simpler microcontroller are:
It is not an expensive component.
Programming and debugging is greatly simplified.
Some of these devices, such as Raspberry PI 3, are all ready, all of which are equipped with all communication peripherals required to perform comfort, as an example of WiFi adapter.
Perform sensor fusion in the hub is based on:
The main cost of the IMU unit capable of fusion on the chip
The original data is corrected by calibrating the previously completed calibration to calibrate the main accuracy of the sensor fusion.
Since the bandwidth in the I2C bus will generate bottlenecks in the data acquisition of the sensor, the fusion sensor processing inside the hub does not increase significant overhead.
Software (Customer):
Since the protocol of transmission data is clear, the client can be anything capable of displaying a 3D skeleton.
Most of the time, using the Python script running in Blender, it acquires quadular data from OSC, and rotates the bones of the 3D skeleton.
This idea is to publish a basic client in the form of a Blender plugin, mainly including the following parts:
Establish some handshake communications with hub, check compatibility and status;
Communicate the state to the user (the person in front of the computer);
Acting as a GUI to run a site calibration process and start capturing;
Display the captured preview in real time and allows the user to register part;
Allow users with Blender's basic experience to create a custom distribution of sensors on the virtual model of the human body, export it to structured data formats (such as XML) and send it to hub.
Note: For the sake of simplicity, it refers to the IMU device, but in order to correctly say it is an IMU (gyroscope and accelerator).
Be
Source: HackADAY.IO
Our other product:
