As you all know, the original Chordata Motion system was built by a small team with minimal resources. It works great, but it is still on the prototype stage.

With the upcoming Kickstarter campaign, many improvements in accuracy and usability will be applied to the system. During this process, we will reach another major milestone: the consolidation of the public control API and the internal structure of the Chordata Motion framework.

If you are not familiarized with programming all these technical terms popping up in our communication sometimes might get confusing. Questions like: ‘What’s an API?‘ or ‘Do I have to know how to program to use Chordata Motion?‘ might arise. In this article, we will explain what do these terms mean, and why they are important even if you don’t ever deal with them.

If you are instead confident with these concepts and are looking for the new specs you can go directly to the last part of this article to get a detailed description of what’s coming.

What’s an API?

When a programmer (or group of them) creates a bunch of code that is good at performing some particular task it might have thousands of lines of code split into many files, with several configuration possibilities and many other complexities.

Trying to document or share such a work would be unpractical. What normally gets done is adding a new layer of code which calls the more complex one from a reduced set of simplified endpoints. This is something that makes much more sense documenting and sharing, and what gets called Application Programming Interface.

Do I have to know how to program to use Chordata Motion?

Not at all. Code is not needed in order to use Chordata Motion. Even if you’re not a programmer, you’ll probably like to know that the flexibility at Chordata Motion’s nucleus can be easily leveraged by programmers (like the ones in our team, or some of our community users) to create new functionalities from where you can control, visualize or analyze the capture.

Why should I care about the API if I wont ever use it?

You will use it, even if not directly. The integrations developed by our team, or by third parties will be directly using the API. Having a broad, robust and open API will allow these integrations to grow fast and without difficulties.

Technical stuff

This is where you have to start reading if you want to know how the Chordata Motion public control API will look like.

What at this stage of the project we are broadly calling “the API” will, in fact, be a pair of APIs that will allow taking full control over the behavior of the mocap gear and one communication protocol for fetching the capture data.

The notochord python module will allow you to control the low-level operations from within the SBC. The Chordata remote action management protocol, a RESTful-like HTTP API, will allow you to control the life cycle of the capture from a remote device, and the Chordata open pose protocol, an OSC-based thin protocol, will allow you receiving the capture in any OSC capable client.

Notochord python module

This module will be based on the current core of the system: the notochord program. It is a C++ application that takes care of all the low-level operations like managing and reading the sensors.

The C++ core will be wrapped in a python interface and used to recreate a new default version of the notochord program. The module will then allow advanced users to tweak the behavior of the default notochord, or even rewrite it from scratch.

Chordata remote action management protocol (CRAMP)

In the current state of the project, to initialize a capture a user should directly launch the notochord through the SBC terminal environment. The main purpose of the CRAMP is to avoid just that. With the CRAMP captures can be started, stopped and configured directly within the client.

It is a RESTful-like HTTP API, which means it will provide a unified HTTP interface, formally inspired by the current conventions on RESTful Web APIs, but omitting some of the constraints of the REST architecture.

Chordata open pose protocol (COPP)

This is a thin layer of specification over the OSC protocol. It creates a specific tree where to target different types of data associated with the capture. Here you have an example of how the quaternion data for a bone named “head” looks like:

/Chordata/q/head <,ffff> [quat.w, quat.x, quat.y, quat.z]

The COPP is completely compatible with normal OSC clients.

Conclusion

We are pretty excited about the new capabilities these new features will give to the Chordata Motion framework. Many of these are already partially implemented, but the upcoming crowdfunding campaign will give us the resources to consolidate and document them. It will also bring many improvements in accuracy, usability, and features. Plus, of course, the campaign will guarantee the longevity of the project.

We are looking forward to see you on board!