Notochord OS v0.1.2 has been released!
This release is the result of the first round of feedback and implementation mainly gathered from the backers of our Kickstarter campaign. So a big shout out to all of you sharing your experiences and giving suggestions here in the forum!
This version solves some networking issues that have raised from the experience of our users. It implements an Autohotspot functionality: the Raspberry will search for known WIFI networks within range, and will attempt to connect to them. If none is available it will revert to Hotspot mode. This way you will never get blocked out from the remote console, and it will allow you to set external networks easily (which are useful to update the firmware, and recommended to obtain better networking performance).
Together with the NotoOS we have implemented several functionalities in it's two mayor components:
Notochord python module v1.0.2
This version comes with several upgrades. The one immediately visible is the new Websockets communicator option. The notochord communicator can be configured to use websockets for its three stream of communications: messages, errors and transmit (payload).
An important feature of this release is the addition of an armature abstraction. Until now the notochord was unaware of any relation between the nodes. The forward kinematics and other processes required to transform the data from the sensors to an usable virtual skeleton was done in the client. Having an armature inside the notochord will allow for a much quicker implementation of more clients (since developers won't need to replicate the main algorithmic logic). We have also ported the pose-calibration processing inside the notochord.
This changes are currently not used, since the Blender addon still uses its internal armature for all the processing. But this was a required step to start several developments that were planned. See below for more details.
Notochord control server v0.1.2
This server exposes the network API used to control the notochord from the outside. It exposes a new interface to manage the addition or editing of WIFI networks. It also implements the client side of the Websocket communication to receive messages and errors from the notochord and display them in the web terminal.
Next steps
Blender addon
We are working in a mayor rework of the addon. In general our addon implements some functionalities (like a server, or the real-time modification of the viewport from an external stream of data) that are pretty incompatible with the way the blender python API is conceived. So making changes and keeping it stable is challenging, even if we put a lot of effort and attention on keeping as well behaved as possible.
In it's current shape it's hard to track and solve some errors. The recent changes in the notchord module allows the clients to put much of the heavy processing load to the "backend" part of the system. This gives us the opportunity to simplify several parts of the addon. In the process we will make the required changes to make things like network communication more reliable.
Remote console
The recent changes in the notochord also opens the possibility of implementing one of the most expected pieces of our the Chordata Framework: the (complete) remote console. In it's current shape it's just a simple HTTP interface to control the main capture processes (start/stop, calibrate, update firmware). But we want the remote console to be a complete client, giving you full control over the management and visualization of the capture from any device (including your smartphone). This development has started two weeks ago, we will be posting updates as soon as possible!
