New Blender 2.8 Chordata Node System Addon

AxonSpark

@Guiltyfeet Looking good! It'll be nice to setup/run everything inside Blender, and I hope that the debug nodes will give you data that's more useful than this.

Will individual K-Ceptor calibration still need to be performed using the terminal interface, or will there be a node for that as well? Or is there a scan mode for the Notochord node? If we'll be able to calibrate the sensors directly in Blender, would there be an accompanying .blend file that would trace our movements as we performed the calibration procedure in real-time? I figure this might help ferret out potential issues during calibration.

Lastly, should I recalibrate my K-Ceptors before trying the 2.8 plug-in when it's released? Or should I keep my current calibration in order to determine if the new software will fix the drift issues I've been having? Also, will the read rate in this version be odr 100?

Thanks!

Guiltyfeet

AxonSpark Our current main objective for the new Addon is re-designing a clearer interface and structure both for our users and our developers and integration with Blender 2.8. In the beginnning this will bring mainly more consistent and easier access to the system. Secondly we're designing everything to fully integrate, in the near future, the Control Server functionalities. This will bring easier and more complete access to Notochord unit. What will come next is an update of the actual Notochord software itself.

AxonSpark Lastly, should I recalibrate my K-Ceptors before trying the 2.8 plug-in when it's released? Or should I keep my current calibration in order to determine if the new software will fix the drift issues I've been having? Also, will the read rate in this version be odr 100?

Calibration and read rate will be addressed in the Notochord update, not in this new Addon release.

Once we're confident about this first release we'll start exposing more features like the one you suggested so please keep us posted with all your ideas! 🙂

Lorenzo

Guiltyfeet

AxonSpark

amjaddb We don't have an official release date yet but we'll keep you updated!

AxonSpark

Guiltyfeet One more thing: the root bone does not move in the current version of the add-on. Will there be a check box option to enable root bone height in the Blender viewport instead of only being available when retransmitting data?

daylanKifky

AxonSpark Will there be a check box option to enable root bone height in the Blender viewport instead of only being available when retransmitting data?

Absolutely.
This is one of the most annoying things on the old add-on even for us

In order to keep all the ideas and suggestions for the new addon organized it would be great if you guy can open issues on the gitlab issue tracker for the addon: https://gitlab.com/chordata/Blender-addon/issues

please use the label [paper-cut] for this type of annoying little details

bristle2008

yes i would rather use 2.8 instead of 2.79. I was going to look at the Blender client to see how it would be changed to 2.8. But since you are doing it, lucky me-- i can forget that part. Also i am going to use an IMUSim so i can hooked up the sim to the Blender client.

daylanKifky

Hi everyone!

We created a small DEMO to share with you the state of the add-on development.
As you can see, the base of the new node system is running (and I can tell you, making an node execution engine inside blender was not an straightforward task 😅 ), and some basic functionalities are already implemented.

The add-on is still not usable to receive actual capture data from a mocap suit. But we are releasing an executable DEMO version togheter with the video for a couple of reasons:

Stability tests

We are particulary interested in testing the stability while the node execution engine is running, so please: hit the "connect" button and try to mess around with the objects in the scene or nodes in the tree. Move them, delete them, group them, press UNDO and REDO several times, open a different file, import an FBX, whatever..
If blender crashes while doing it please let us know.

UX feedback

This is a great time to hear your opinions about the overall direction the GUI and user experience is taking.
For example: We placed some "meta-nodal" operators inside Window menu > Chordata simple because we couldn't think of a better place. Perhaps you can come up with a better one.
We would also like to know your opinions about names: does TestCube node mean something to you? What about the "Connect" button?
Feedback regarding it at this stage is very welcome!

☢ So fell free to download the DEMO add-on from our download page and give it a try. ☢

AxonSpark

Looking good so far! It'll be great to have everything in one place. I'll do some stability testing and let you know what happens.

daylanKifky

A new Beta of the addon is released!

It has networking functionalities and armature support. So you can already receive the capture coming from the Chordata hardware

Here's a brief explanation on how to install it and setup the capture: https://wiki.chordata.cc/wiki/User_Manual/1.Chordata_parts/1.4.Client_software

Another nice advanced features that we added recently are:

A vector node which allows to visually debug one of the raw vectors coming from a sensor. It can also draw a point cloud to visualize the results of the magnetometer calibration.
A custom node, which includes a python boilerplate script to easily code custom processing of the capture stream. This might serve for users like @HalloweenBob who need to convert the capture to a custom text format.

The release is still a Beta (hence the B1 in the version number), since many of the functionalities need polishing. For example you might notice that the capture visualization is a little more noisy than in the previous addon. The record node requires further testing, and the forward node is still not implemented. Our own testing showed a much improved stability with respect to the previous version of the addon, but if you still get crashes please try to inform us using the issue tracker

We are working on documentation on the usage of this new addon, keep an eye on this thread

HalloweenBob

daylanKifky Thank you!! I will be looking into this!

AxonSpark

Hey @daylanKifky, Hope you and the team are staying healthy.

I attempted to use the 2.8 add-on in Blender 2.82 on my relatively new Windows laptop, but ran into an odd error. Getting everything up and running through the terminal worked, but when I tried to connecting with the Notochord Node, I kept getting this error with different body parts indicated each time I tried it:

Unfortunately, when I checked the console window, there were no additional details.

The result was the same both with a Firewall setup with permissions for Blender, and with the Firewall completely turned off.

I tried looking through the forum for answer to this, but couldn't find one. Any ideas why this is happening? Thanks!

daylanKifky

Hey AxonSpark! is great to see you are trying the new addon.
The problem is probably caused by an outdated version of the notochord which sends messages in a slightly different format than what the new addon expects.
Updating your notochord with the usual pull and compile should solve it

AxonSpark

daylanKifky Ok, I pulled and complied the latest Notochord software, and that fixed the connecting issue. I did some tests with as single K-Ceptor and I noticed that it doesn't matter if I changed the send rate and/or the odr, the Packet Rate in the Stats Node tends to hover around 23-24. Is this normal?

daylanKifky

for now the packets receiving rate is initiated at the scene's fps. We are restructuring the way packets are exchanged, so it might change in future versions. If you want to test it at 50Hz for now just change the scene's FPS

AxonSpark

daylanKifky So I did a full biped test with the new add-on and it looks like the knee bend problem is still an issue. Before I start a new testing thread, I wanted to ask:

Would it be helpful to use the Dump Node to gather some data for you? If so, which boxes should I be checked?
Would further spine or spine & leg tests help at all? Or maybe setting up groups of 3 K-Ceptor models in order to see if the axes align properly?

I made notes on where all the sensors were placed, so hopefully that'll help with troubleshooting.

daylanKifky

The second beta of the addon is out!

Here's the changelog:

Chordata addon v1.0.0-B2 Changelog
==================================

Armature node:
- add smooth filter
- add root bone height
- add timed calibration
- add Armature out Socket

Record node:
- add option to use the current accion
- use Armature in Socket

Notochord node:
- include pre-registered captures on Demo mode```

daylanKifky

AxonSpark
Hey!
I think starting a new clean thread with just the problem that you are currently having would be a good idea.

I still think this is a magnetic problem. Have you ever tried the suit outside your flat? sometimes modern apartment buildings have an incredible amount of iron in the structure which distorts the magnetic field inside them. This would explain the errors in heading you experiment, which are always located at the lower part of the body (thus closer to the floor, where big iron beams support the structure).
We are currently working on a magnetic correction algorithm that should help to compensate this type of disturbances. Yet, having a test in a different environment would help confirm the hypothesis.

A way to get an idea of your vertical magnetic disturbance profile would be this:

Start the notochord with the --raw flag, and just one KC attached
In the Blender addon Use the Vector node to visualize the incoming magnetic vector. If you keep your KC in the same orientation and move it around the arrow should always point in the same direction (heading north, and about 65° ~ 70° off from the horizontal)
Keeping the KC in the same orientation pull it above your head, as far as your arm (and the KC cable) allows you, then slowly pull it down up to the floor.

Did the arrow changed direction during this process? If it did, was the angle of heading change similar to the angle of heading error you get in the knees?

PS: there's a bug on the vector node, it sometimes doesn't create the correct list of incoming KC names. If this happens to you just plug a Testcube node in the same tree, and it will populate the list that is used also by the Vector node.

Another thing to keep in mind: Magnetometers are affected by torsion. This is a known fact, but we recently made some tests, and the influence of just a small torsion can be huge. Are you by chance calibrating your sensors outside the case, and then screwing them? Or perhaps adjusting the screws from time to time? Those actions might change the torsion of the PCB, and invalidate the previously done calibration. I'll upload a demo video soon

AxonSpark

daylanKifky I'll have to wait until social distancing/lockdowns have subsided before trying the suit outside of my apartment. The building I live in is over 100 years old (converted hotel from the early 1900's), so I'm not sure how much metal it contains, but there could be a fair number of pipes under my floor. I'll try running the test you suggest to determine if that's what's causing my issues (although it's odd that it sometimes affects one leg and sometimes both).

As for your questions about torsion, I do not remove the K-Ceptors from their cases for calibration. I put calibration markers on all the project boxes, so I wouldn't have to remove them. I'm also not adjusting the screws, as nothing has come loose yet. However, some of the screws might loosen over time since I'm moving the boxes around. Would this cause torsion issues?

Teleman

AxonSpark Have you tried switching K_Ceptors around into alternate positions? Is it just the knees or specifically those K_Ceptors? I've gotten some very strange poses by inadvertently mixing up channels and/or pins. ;-)

I had head nodding issues at first -- i.e. the head would nod forward instead of backward. That was fixed by facing South during Blender calibration. Also, the hands were drifting without the performer moving -- we had to recalibrate all the sensors. After calibrating, each sensor was reviewed in Blender -- some still had a little imperfect drift or alignment, but would slowly adjust itself to stability. We found that during K_Ceptor calibration that if we would pause a moment after each turn of the cube, giving the system a chance to stabilise after each turn, this definitely helped get rid of drift from the sensors, some more than others.

AxonSpark

Teleman Weirdly, it doesn't seem to be a K-Ceptor specific issue (at least I don't think it is). I tend to use the same K-Ceptors for the base, dorsal, and head, but I've tried switching up all of the arms and legs, and I still get this odd sideways knee bending (sometimes it's one leg, sometimes it's both).

If you're still having drift issues, I'd start with this post in the Calibration Issues threadregarding i2c baudrate and see if it helps (it solved a lot of problems I was having for months): https://forum.chordata.cc/d/63-calibration-issues/80

Teleman

AxonSpark What if you stand on a chair during Blender calibration?