Hello,
After finishing system assembly last week, I have had time to properly set everything up in connection with Blender. Simultaneously, however, I am trying to run a previously coded slip detection algorithm on the pi that takes accelerometer and gyroscope inputs. Is there an easy way to get these values out of the Notochord?
Thanks in advance.
Hi and welcome to the forum!
The notochord allows you to redirect the "transmission" stream containing the processed quaternion data, and optionally also the raw sensor data.
The output options are stdout, stderr, file and osc. You can set those on the configuration xml or as arguments on the command line.
For example, this is a part of the default xml. It sets the log stream (messages for the user) to stdout and file, while the transmission stream to just osc.
<Log>
stdout, file
</Log>
<Transmit>
osc
</Transmit>And this cmd line call will output the transmission stream to both file and stdout while keeping the log stream on just stderr. The --raw flag makes the notochord output the raw sensor data as well
notochord -t stdout -t file -l stderr --rawBy the way, I'm curious about the use you are giving to the system. Why are you using a the slip detection algo?
Thank you for the response!
I will try experimenting with changing the output streams later today when I get home, and post an update when I get it working.
As for our use, my team is developing a knee brace to assist with certain types of slip. The slip algorithm we are using was developed in the past by one of our researchers to use five IMUs on the leg. Our hope with using Chordata is to have a simple and contained method of both getting observable data out (we used a full motion capture system prior to this - it required a lot of post-processing) while linking all the IMUs via I2C to make it easier to get the values we need at the same time.
Eventually, we are hoping to run this slip prevention strategy as a standalone system with just the pi and IMUs. This is why I am trying to avoid routing the algorithm data through blender.
Hello,
Didn't manage to get back to the project until today. I made use of the stream redirect which allowed me to get the data out of the Notochord program. However, no matter if I use the --raw or not, I get the same output. I do get acknowledgement that the --raw flag was detected because of the log message "info~[ 113] Raw data mode" but that is not shown in the output.
Update: also connected to blender and checked the osc stream. Gives the same four numbers.
First Command
pi@Raspi:~/notochord/bin $ ./notochord --scan -t stdout --raw
info~[ 0] Notochord start @ Wed Jun 17 19:41:57 2020
info~[ 0] Verbosity level 0
info~[ 0] K-Ceptor revision 2
info~[ 100] I2C adapter initialied on /dev/i2c-1
info~[ 100] Starting Armature scanning.
info~[ 100] Scan: [Base Mux] Hub
info~[ 101] Scan: [Base Mux] Hub, GATE: CH_1
info~[ 101] Scan: ~~K-Ceptor [kc-CH_1-0], value 0
info~[ 103] Scan: [Base Mux] Hub, GATE: CH_2
info~[ 105] Scan: [Base Mux] Hub, GATE: CH_3
info~[ 107] Scan: [Base Mux] Hub, GATE: CH_4
info~[ 109] Scan: [Base Mux] Hub, GATE: CH_5
info~[ 111] Scan: [Base Mux] Hub, GATE: CH_6
info~[ 113] Armature Created.
info~[ 113] Starting timer. [NODES < 1 , 1 > = 2 | ODR = 50 | Sleep = 19955us]
info~[ 113] Sending rate = 50Hz
info~[ 113] **Raw data mode**
The lectures from the K-ceptors will be transmitted without any processing
Using this flag for calibration is deprecated! use --calibrate instead
Press a key to continue...
info~[ 621] Timer started, 2 nodes on scheduler
info~[ 1145] K_Ceptor kc-CH_1-0...: setup OK.
/Chordata/q/kc-CH_1-0,1687,0.999923,-0.015190,-0.011926,-0.005348
/Chordata/q/kc-CH_1-0,1707,0.906664,-0.063043,-0.015006,-0.417876
/Chordata/q/kc-CH_1-0,1728,0.793232,-0.040305,0.008369,-0.608303
/Chordata/q/kc-CH_1-0,1756,0.749926,-0.031837,0.015274,-0.661299
/Chordata/q/kc-CH_1-0,1796,0.748128,-0.031948,0.014793,-0.663336
/Chordata/q/kc-CH_1-0,1836,0.746222,-0.032592,0.014215,-0.665457
/Chordata/q/kc-CH_1-0,1876,0.744875,-0.032385,0.016113,-0.666930
/Chordata/q/kc-CH_1-0,1916,0.743315,-0.031471,0.015329,-0.668728
/Chordata/q/kc-CH_1-0,1956,0.742980,-0.030820,0.016504,-0.669100
/Chordata/q/kc-CH_1-0,1996,0.742173,-0.031562,0.016647,-0.669954
/Chordata/q/kc-CH_1-0,2036,0.740573,-0.031670,0.014042,-0.671773Second Command
pi@Raspi:~/notochord/bin $ ./notochord --scan -t stdout
info~[ 0] Notochord start @ Wed Jun 17 19:45:19 2020
info~[ 0] Verbosity level 0
info~[ 0] K-Ceptor revision 2
info~[ 101] I2C adapter initialied on /dev/i2c-1
info~[ 101] Starting Armature scanning.
info~[ 101] Scan: [Base Mux] Hub
info~[ 101] Scan: [Base Mux] Hub, GATE: CH_1
info~[ 101] Scan: ~~K-Ceptor [kc-CH_1-0], value 0
info~[ 104] Scan: [Base Mux] Hub, GATE: CH_2
info~[ 106] Scan: [Base Mux] Hub, GATE: CH_3
info~[ 108] Scan: [Base Mux] Hub, GATE: CH_4
info~[ 110] Scan: [Base Mux] Hub, GATE: CH_5
info~[ 112] Scan: [Base Mux] Hub, GATE: CH_6
info~[ 1193] Armature Created.
info~[ 1193] Starting timer. [NODES < 1 , 1 > = 2 | ODR = 50 | Sleep = 19955us]
info~[ 1193] Sending rate = 50Hz
info~[ 1193] Timer started, 2 nodes on scheduler
error~[ 1194] error switching branch CH_1. Retrying.. (0)
info~[ 1738] K_Ceptor kc-CH_1-0...: setup OK.
/Chordata/q/kc-CH_1-0,2280,0.999923,-0.015301,-0.011855,-0.005170
/Chordata/q/kc-CH_1-0,2300,0.908427,-0.070330,-0.013958,-0.412893
/Chordata/q/kc-CH_1-0,2321,0.795581,-0.046672,0.009567,-0.604751
/Chordata/q/kc-CH_1-0,2341,0.746410,-0.037838,0.018337,-0.664874
/Chordata/q/kc-CH_1-0,2375,0.728370,-0.036969,0.018675,-0.684624
/Chordata/q/kc-CH_1-0,2415,0.727302,-0.035217,0.017943,-0.685869
/Chordata/q/kc-CH_1-0,2455,0.727737,-0.034173,0.021360,-0.685361
/Chordata/q/kc-CH_1-0,2495,0.727750,-0.034814,0.020546,-0.685338
/Chordata/q/kc-CH_1-0,2534,0.727417,-0.033568,0.021527,-0.685715
/Chordata/q/kc-CH_1-0,2574,0.726350,-0.035252,0.021401,-0.686764
/Chordata/q/kc-CH_1-0,2614,0.725879,-0.035464,0.020762,-0.687271this is strange 
could you paste the output of ./notochord --version?
and,
Could you confirm the raw values are getting out when you use the osc output? perhaps the Blender addon with a dump node is a good way to tell. If you prefer a cmd line method to be run directly in the RPi you can navigate to the folder
notochord/lib/oscpack_1_1_0and compile a cmd line utility to dump OSC messages with
make dumpyou can run the program with
bin/OscDump [port]Of course, in order to get anything from it you need to run the notochord with a localhost target. I'm almost sure the OscDump listens at port 6565 by default.
Based on the output from the dump files, it looks like the raw data is being transmitted fine.
I double checked what happened when streamed to stdout after seeing these results - output still not raw.
pi@Raspi:~/notochord/bin $ ./notochord --version
Chordata's Notochord v0.1.2b #13da69dpi@Raspi:~/notochord/lib/oscpack_1_1_0 $ bin/OscDump 6565
listening for input on port 6565...
press ctrl-c to end
[/Chordata/raw/kc-CH_1-0 int32:1, int32:2, int32:-5, int32:232, int32:101, int32:4062, int32:482, int32:690, int32:-3104]
[/Chordata/q/kc-CH_1-0 float32:0.999924, float32:-0.0113211, float32:-0.0159547, float32:-0.00410321]
[/Chordata/raw/kc-CH_1-0 int32:1, int32:2, int32:-5, int32:232, int32:101, int32:4062, int32:482, int32:690, int32:-3104]
[/Chordata/raw/kc-CH_1-0 int32:1, int32:2, int32:-5, int32:232, int32:101, int32:4062, int32:482, int32:690, int32:-3104]
[/Chordata/raw/kc-CH_1-0 int32:1, int32:2, int32:-5, int32:232, int32:101, int32:4062, int32:482, int32:690, int32:-3104]
[/Chordata/raw/kc-CH_1-0 int32:1, int32:2, int32:-5, int32:232, int32:101, int32:4062, int32:482, int32:690, int32:-3104]
[/Chordata/raw/kc-CH_1-0 int32:1, int32:2, int32:-5, int32:234, int32:92, int32:4076, int32:482, int32:690, int32:-3104]
[/Chordata/raw/kc-CH_1-0 int32:-5, int32:6, int32:-6, int32:234, int32:92, int32:4076, int32:482, int32:690, int32:-3104]
[/Chordata/raw/kc-CH_1-0 int32:-5, int32:6, int32:-6, int32:234, int32:92, int32:4076, int32:462, int32:687, int32:-3190]
[/Chordata/raw/kc-CH_1-0 int32:-5, int32:6, int32:-6, int32:234, int32:92, int32:4076, int32:462, int32:687, int32:-3190]
[/Chordata/raw/kc-CH_1-0 int32:-5, int32:6, int32:-6, int32:234, int32:92, int32:4076, int32:462, int32:687, int32:-3190]
[/Chordata/raw/kc-CH_1-0 int32:-5, int32:6, int32:-6, int32:234, int32:92, int32:4076, int32:462, int32:687, int32:-3190]
[/Chordata/raw/kc-CH_1-0 int32:-5, int32:6, int32:-6, int32:234, int32:92, int32:4076, int32:462, int32:687, int32:-3190]
[/Chordata/raw/kc-CH_1-0 int32:-5, int32:6, int32:-6, int32:234, int32:92, int32:4076, int32:462, int32:687, int32:-3190]
[/Chordata/raw/kc-CH_1-0 int32:-5, int32:6, int32:-6, int32:234, int32:92, int32:4076, int32:462, int32:687, int32:-3190]
[/Chordata/raw/kc-CH_1-0 int32:-5, int32:6, int32:-6, int32:234, int32:92, int32:4076, int32:462, int32:687, int32:-3190]
[/Chordata/raw/kc-CH_1-0 int32:-5, int32:6, int32:-6, int32:234, int32:92, int32:4076, int32:462, int32:687, int32:-3190]
[/Chordata/raw/kc-CH_1-0 int32:-5, int32:6, int32:-6, int32:234, int32:92, int32:4076, int32:462, int32:687, int32:-3190]
[/Chordata/raw/kc-CH_1-0 int32:-5, int32:6, int32:-6, int32:234, int32:92, int32:4076, int32:462, int32:687, int32:-3190]
[/Chordata/raw/kc-CH_1-0 int32:-5, int32:6, int32:-6, int32:234, int32:92, int32:4076, int32:462, int32:687, int32:-3190]
[/Chordata/raw/kc-CH_1-0 int32:-5, int32:6, int32:-6, int32:234, int32:92, int32:4076, int32:462, int32:687, int32:-3190]
[/Chordata/raw/kc-CH_1-0 int32:-5, int32:6, int32:-6, int32:234, int32:92, int32:4076, int32:462, int32:687, int32:-3190]
[/Chordata/raw/kc-CH_1-0 int32:-5, int32:6, int32:-6, int32:234, int32:92, int32:4076, int32:462, int32:687, int32:-3190]
[/Chordata/raw/kc-CH_1-0 int32:-5, int32:6, int32:-6, int32:234, int32:92, int32:4076, int32:462, int32:687, int32:-3190]
[/Chordata/raw/kc-CH_1-0 int32:-5, int32:6, int32:-6, int32:234, int32:92, int32:4076, int32:462, int32:687, int32:-3190]
[/Chordata/raw/kc-CH_1-0 int32:-5, int32:6, int32:-6, int32:234, int32:92, int32:4076, int32:458, int32:691, int32:-3298]
[/Chordata/raw/kc-CH_1-0 int32:-5, int32:6, int32:-6, int32:234, int32:92, int32:4076, int32:458, int32:691, int32:-3298]
[/Chordata/raw/kc-CH_1-0 int32:-5, int32:6, int32:-6, int32:234, int32:92, int32:4076, int32:458, int32:691, int32:-3298]
[/Chordata/raw/kc-CH_1-0 int32:-5, int32:6, int32:-6, int32:234, int32:92, int32:4076, int32:458, int32:691, int32:-3298]
[/Chordata/q/kc-CH_1-0 float32:0.959729, float32:-0.00227811, float32:-0.0315342, float32:-0.280023]
[/Chordata/raw/kc-CH_1-0 int32:-2, int32:2, int32:-5, int32:229, int32:100, int32:4047, int32:458, int32:691, int32:-3298]
[/Chordata/raw/kc-CH_1-0 int32:-2, int32:2, int32:-5, int32:229, int32:100, int32:4047, int32:458, int32:691, int32:-3298]
[/Chordata/raw/kc-CH_1-0 int32:-2, int32:2, int32:-5, int32:229, int32:100, int32:4047, int32:458, int32:691, int32:-3298]
[/Chordata/raw/kc-CH_1-0 int32:-2, int32:2, int32:-5, int32:229, int32:100, int32:4047, int32:458, int32:691, int32:-3298]
[/Chordata/raw/kc-CH_1-0 int32:-2, int32:2, int32:-5, int32:229, int32:100, int32:4047, int32:458, int32:691, int32:-3298]Blender Console Raw Sensor Data Dump:
[Dump Node] RAW:kc-CH_1-0 => (0, 1, -3, 262, 99, 4096, 449, 812, -3202)
[Dump Node] RAW:kc-CH_1-0 => (-3, 5, -6, 261, 99, 4132, 457, 867, -3232)
[Dump Node] RAW:kc-CH_1-0 => (-1, -1, -4, 263, 111, 4113, 399, 801, -3215)
[Dump Node] RAW:kc-CH_1-0 => (-1, 4, -5, 255, 120, 4119, 443, 841, -3314)
[Dump Node] RAW:kc-CH_1-0 => (2, 2, -3, 261, 122, 4098, 421, 815, -3164)
[Dump Node] RAW:kc-CH_1-0 => (-1, 4, -4, 253, 110, 4127, 429, 814, -3223)
[Dump Node] RAW:kc-CH_1-0 => (0, 2, -5, 259, 114, 4100, 409, 875, -3247)
[Dump Node] RAW:kc-CH_1-0 => (-2, 3, -5, 257, 105, 4115, 436, 865, -3188)
[Dump Node] RAW:kc-CH_1-0 => (1, 1, -7, 259, 109, 4107, 451, 875, -3323)
[Dump Node] RAW:kc-CH_1-0 => (-2, 1, -9, 257, 109, 4135, 442, 893, -3185)
[Dump Node] RAW:kc-CH_1-0 => (-1, 2, -5, 262, 118, 4102, 445, 837, -3228)
[Dump Node] RAW:kc-CH_1-0 => (0, 1, -4, 262, 110, 4118, 455, 872, -3211)
[Dump Node] RAW:kc-CH_1-0 => (1, 2, -3, 245, 105, 4100, 454, 832, -3225)
[Dump Node] RAW:kc-CH_1-0 => (-2, 5, -4, 246, 107, 4132, 440, 865, -3315)
[Dump Node] RAW:kc-CH_1-0 => (-1, 2, -4, 256, 113, 4096, 458, 864, -3147)Hi, I didn't realized you were part of the betatesting program. I gave you betatester permissions now.
It seems like a bug in the notochrod program. Could you report it in the notochord issue tracker. I will try to fix it as soon as possible, but we are a little busy right now with the pre-campaign so it might take a few days.
How were you planning to exchange data btw notochord and your slip detection program? is piping the stdout a good solution for you? And in which language is this slip detection routine written?
Perhaps using OSC as IPC channel is a good solution
Submitted this to gitlab as an issue, I re-copied all the logs and linked the forum post just in case. It can be found here: https://gitlab.com/chordata/notochord/-/issues/2
The real-time version of the program is written in Python. As for transmission, I'm only a beginner-intermediate programmer so I likely haven't been going about this properly. I originally wanted to try to take advantage of Python's multithreading node, but when I got into the notochord source code I was a little lost. So I made this post here, after which I tried using the stdout stream which would be acceptable if it had the correct data. After seeing that the osc stream outputs the correct values I tried to write a listener using Python's python-osc library but wasn't getting anything when listening for the notochord on localhost.
I have a basic knowledge of inter-process communication, mostly with sockets. However. it's my (possibly incorrect) understanding that the socket has to be opened from both sides, and I'd rather not go digging in the source.
Currently looking more into OSC servers for python.
Take a look at osc4py3, in the documentation there are several working examples.
Otherwise you can try our COPP Server. It's the osc server used in our blender add-on. It's partially based on osc4py3, exchanging the msg dispatching and routing mechanism for more simple queues.
The receive_sample_messages.py is a simple example of it's usage. As you will see you are responsible for polling the queue to get the incoming msgs
duncan006 when I got into the notochord source code I was a little lost
The current notochord is a wild beast. It's performantive, but the foundations were written several years ago when Chordata was a quite different system and after that several pieces were added over the years. The result is a complex codebase which is hard to modify and expand even for us (the bug you found is an evidence of that). We are planning a deep rewrite which will make tweaking it much easier. I wouldn't advice you to try to modify it right now
Finally managed to receive the OSC stream. I tried a couple of different nodes to do it, but had trouble with most of them. The code that finally worked for me was the blocking server in the python-osc documentation found here.
Of course, this is a temporary solution until the stdout streaming is fixed - as pointing the osc to localhost means that blender can't receive data.
made a quick fix, take a look at the issue tracker
daylanKifky just tested the fix out, works great! Only thing I noticed was that when streaming the OSC, both raw and quaternion values were sent using an address of /Chordata/raw/ or /Chordata/q/ to differentiate. However, in the new stdout stream only the raw values are output with an address of /%/. I understand that this was a quick fix and there may not be a properly implemented solution for some time, but I was wondering if this could be implemented eventually.
Update: These could be unrelated issues, but they only started happening after pulling the latest version from git so I wanted to document it.
I went back to compare stuff between the OSC stream and stdout stream, and started getting some brand new errors. First, OSC addresses are not being printed with their arguments. Instead, something weird is happening where the first half of the address is received without arguments, then the arguments are received with just the k-ceptor number. Still getting quaternion and raw data, fortunately. Additionally, however, "root:unhandled parameter type: N" started printing after every message was received. When investigated in the built in OscDump program, it seems that the unhandled parameter is a result of the disjointed addresses - because the first half of the address sends with argument "nil" while the second half sends with the actual args. I could, of course, write a little extra code to handle the disjoint, but wanted to get a record of this for y'all.
Finally, as if this wasn't enough already - Blender does not show the root:unhandled parameter error and streams OSC data fine, but instead disconnects from the stream within 10 seconds of connecting.
Logs are included below from my custom OSC receiver, /notochord/lib/oscpack_1_1_0/bin/OscDump, blender python console, and blender log.
Edit: Downgraded to the last version before I ran the git pull, recompiled, and the OSC stream and blender both work fine again. Definitely an issue somewhere in there. Going to stick with the older version and working OSC stream for now until there's a proper fix for the stdout stream.
pi@Raspi:~/scripts $ ./customOSCreceiver
WARNING:root:Unhandled parameter type: N
DEFAULT /%%/Chordata/q: ()
DEFAULT /%/kc-CH_1-0: (-0.3447900414466858, 0.5741108655929565, -0.3720789849758148, -0.6427083015441895)
WARNING:root:Unhandled parameter type: N
DEFAULT /%%/Chordata/raw: ()
DEFAULT /%/kc-CH_1-0: (5, 3, -2, -4106, 353, -271, 2910, -12, -1489)
WARNING:root:Unhandled parameter type: N
DEFAULT /%%/Chordata/q: ()
DEFAULT /%/kc-CH_1-0: (-0.3447365462779999, 0.5738995671272278, -0.372271865606308, -0.642814040184021)
WARNING:root:Unhandled parameter type: N
DEFAULT /%%/Chordata/raw: ()
DEFAULT /%/kc-CH_1-0: (5, 3, -2, -4106, 353, -271, 2910, -12, -1489)
WARNING:root:Unhandled parameter type: N
DEFAULT /%%/Chordata/q: ()
DEFAULT /%/kc-CH_1-0: (-0.344708114862442, 0.5737206935882568, -0.37244048714637756, -0.6428912878036499)
WARNING:root:Unhandled parameter type: N
DEFAULT /%%/Chordata/raw: ()
DEFAULT /%/kc-CH_1-0: (5, 3, -2, -4106, 353, -271, 2910, -12, -1489)
WARNING:root:Unhandled parameter type: N
DEFAULT /%%/Chordata/q: ()
DEFAULT /%/kc-CH_1-0: (-0.34470033645629883, 0.5735676884651184, -0.37258896231651306, -0.6429458856582642)
WARNING:root:Unhandled parameter type: N
DEFAULT /%%/Chordata/raw: ()
DEFAULT /%/kc-CH_1-0: (5, 3, -2, -4106, 353, -271, 2829, 2, -1511)
WARNING:root:Unhandled parameter type: N
DEFAULT /%%/Chordata/q: ()
DEFAULT /%/kc-CH_1-0: (-0.34470871090888977, 0.5734347701072693, -0.37272143363952637, -0.6429831981658936)
WARNING:root:Unhandled parameter type: N
DEFAULT /%%/Chordata/raw: ()
DEFAULT /%/kc-CH_1-0: (5, 3, -2, -4106, 353, -271, 2829, 2, -1511)
WARNING:root:Unhandled parameter type: N
DEFAULT /%%/Chordata/q: ()
DEFAULT /%/kc-CH_1-0: (-0.3447302579879761, 0.5733190774917603, -0.3728412687778473, -0.6430053114891052)
WARNING:root:Unhandled parameter type: N
DEFAULT /%%/Chordata/raw: ()
DEFAULT /%/kc-CH_1-0: (5, 3, -2, -4106, 353, -271, 2829, 2, -1511)pi@Raspi:~/notochord/lib/oscpack_1_1_0/bin $ ./OscDump 6565
listening for input on port 6565...
press ctrl-c to end
{ ( 12737474 )
[/%%/Chordata/q (Nil)]
[/%/kc-CH_1-0 float32:0.773735, float32:0.280695, float32:0.412029, float32:-0.390867]
}
{ ( 12737582 )
[/%%/Chordata/raw (Nil)]
[/%/kc-CH_1-0 int32:0, int32:-2, int32:-6, int32:-3598, int32:440, int32:-2051, int32:3892, int32:1188, int32:-1773]
}
{ ( 12777457 )
[/%%/Chordata/q (Nil)]
[/%/kc-CH_1-0 float32:0.773407, float32:0.281013, float32:0.412542, float32:-0.390747]
}
{ ( 12777551 )
[/%%/Chordata/raw (Nil)]
[/%/kc-CH_1-0 int32:1, int32:5, int32:-6, int32:-3473, int32:485, int32:-2091, int32:3901, int32:1192, int32:-1822]
}
{ ( 12817454 )
[/%%/Chordata/q (Nil)]
[/%/kc-CH_1-0 float32:0.774162, float32:0.280697, float32:0.411174, float32:-0.390919]
}
{ ( 12817543 )
[/%%/Chordata/raw (Nil)]
[/%/kc-CH_1-0 int32:3, int32:-3, int32:-7, int32:-3409, int32:475, int32:-2093, int32:3777, int32:1270, int32:-1811]
}
{ ( 12857455 )
[/%%/Chordata/q (Nil)]
[/%/kc-CH_1-0 float32:0.77414, float32:0.280337, float32:0.411186, float32:-0.39121]
}
{ ( 12857542 )
[/%%/Chordata/raw (Nil)]
[/%/kc-CH_1-0 int32:4, int32:12, int32:-6, int32:-3521, int32:432, int32:-2059, int32:3829, int32:1255, int32:-1824]
}Blender Dump from Python Console:
Chordata Engine (v1.0.0, #d8227990) started @ 2020-06-19 14:58:22
[Dump Node] RAW:kc-CH_1-0 => (-11, 20, -12, -3913, -1063, 530, 4549, 2253, -1025)
[Dump Node] RAW:kc-CH_1-0 => (7, -8, -10, -3859, -1064, 488, 4533, 2253, -978)
[Dump Node] RAW:kc-CH_1-0 => (-2, 11, -12, -3898, -1063, 488, 4589, 2230, -994)
[Dump Node] RAW:kc-CH_1-0 => (1, 3, -10, -3877, -1046, 492, 4612, 2226, -987)
[Dump Node] RAW:kc-CH_1-0 => (7, -4, -5, -3975, -1057, 477, 4589, 2177, -1005)
[Dump Node] RAW:kc-CH_1-0 => (-6, 9, -9, -3889, -1060, 512, 4531, 2236, -999)
Chordata Engine stoppedBlender Dump from Blender log:
Stopping Chordata engine due to an unknown error
float division by zero
Stack trace:
See console for details
Chordata Engine stopped