Progress/Experience using Chordata

HalloweenBob

I did try to use the Blender model with the new KCepter, but got the exact same results as the first one I tried. There seems to be nothing that I can do which allows me to stay connected for more than a few seconds no matter what tests I run.

I will try running Blender on a different computer just to see if that makes a difference, although the computer I'm using has no issues with any other program I run and has more resources than would ever be needed for this project.

Anything else I should try? I am getting worried that I will not be able to get this to go.

HalloweenBob

Installed everything on a new laptop, and gave it a try. slight variations on the issues but still getting the divide by zero error and the disconnects. The connection seems to last longer on this computer, but5 still only 10 or 20 seconds at the most.

It also has a curious difference that you can see in the Blender image I uploaded.
It shows the KCepter model, and when I connect, it superimposes a second model on top of the first that moves with the KCepter, while the original model remains static. Weird, but looks more like a display issue than a fundamental problem with the program.
I loaded puTTy on that machine as well and it connected fine and I scanned it to the new IP address and it connected, but had the issues I outlined above.

After seeing that, I surmise that my computer I was using in the first place was indeed not the issue after all since the same issue (with slight variations) is happening on both computers.

I will take some closeup pictures of my wiring between the Pi and the Hub just to confirm that I have it all correct. I did follow the directions exactly as far as I know from the video, but I do have to run a USB from the hub to the Pi to power it up even though I have the jumper cables in place as instructed. Pictures coming soon.

daylanKifky

Hi @HalloweenBob
Thanks for your detailed report.
The division by zero errors have nothing to do with the KCeptors or notochord. It's just a small bug in the Blender addon. We are taking more than usual to fix it because in these days we are the crowdfunding campaign is requiring some of our time and attention.
The behaviour you are getting is quite strange, deleting the Stats node should avoid the calculation in which the error happens. So I made a quick patch that should get rid of the error while we work on a more definitive solution. You can download that version of the Addon here: https://gitlab.com/chordata/Blender-addon/-/jobs/635384237/artifacts/file/chordata_1-0-0_2d1f0f8b.zip
You should uninstall the previuous version and install this one. Please make sure it prints the following hash in the internal blender console when starting the capture: #2d1f0f8b

HalloweenBob when I connect, it superimposes a second model on top of the first that moves with the KCepter, while the original model remains static.

It seems like there are two KCeptors in the scene, and only one is being controlled by the testcube node. Please confirm that's the case, otherwise we should take a deeper look at what's happening. In order to see the existing objects in the scene you can use the outliner area, on the center top zone of the blender interface as in the screenshot you sent.

HalloweenBob

Just in case, here is how I connected the jumper wires from the hub to the Pi. My understanding was that the power source, (In my case a 2 amp 5VDC power adapter) was plugged directly into the hub through an on/off switch. The jumper cables should have transferred the power to the Pi, but did not as configured. I added the USB cable to transfer the power and the Pi came to life and I was getting results I have been talking about in this thread. I even used the same colors as shown in the video just so I was absolutely clear on which wire belonged where and there was no confusion. Here are my pictures:

HalloweenBob

I will have to have another look at that in blender. I didn't set up 2 KCepters in the scene. I'm not even sure how I would do that. I was just using it to calibrate and observe it working.

You didn't address the issues I had calibrating. Where it had so many "Too Much variation" warnings while it was absolutely still, and why the samples collected were 0.

Also, was looking for confirmation that I have wired the Hub and Pi together correctly, and if so, why I still need the USB power cord between them.

Thanks, I hope to get back to work on this tonight after I have a chance to try your patch, but would like to be sure about the calibration and wiring as well.

duncan006

HalloweenBob Hey, not sure about the larger issues you're having but I can answer a couple of the questions you asked in your last post.

For the two k-ceptors, you can add multiple by clicking the add k-ceptor button in the chordata drop-down menu more than once. You can drag one to another place in the view and connect another k-ceptor (using another node to view multiple at a time) or click on it in the hierarchy pictured below and delete it.

I can't speak on the "too much variation" warnings, as I frequently get them myself. I usually don't touch it and it will calibrate after a few seconds worth of messages. As for the "samples collected: 0" line, I can tell you that it doesn't actually show anything - it's a little bit of the old calibration that needs to be cleaned up. It's not connected to any actual number. From @daylanKifky himself here: https://forum.chordata.cc/d/131-calibration-errors-broken-magnetomer/4

The hub and pi appear to be wired correctly. Particularly regarding the USB that you asked about, you need either the USB (to power the pi from the hub) or a jumper on the 3v3 pin (to power the hub from the pi). One or the other is necessary as far as I know. If you'd like to get rid of the USB, you can look here in the docs to see where you'd need the extra wire and how you'd have to switch your power/jumper around. I am unable to tell you if there are any advantages/disadvantages to one approach over the other.

Hope this helped.

daylanKifky

Thanks for you comments @duncan006!

Regarding the: "too much variation" part: The program is discarding accelerometer readings which are noisy. The first ones when the sensor has recently started normally are, so it's normal to get a couple of this messages during calibration. The real problem would be if the notochord keeps repeating this stage forever.
By the way, the sensibility of this filter is really high, so for example it will detect the vibration of you typing on your keyboard if the KC is standing over the same table.

HalloweenBob

OK, well, that addresses everything I was wondering about aside from the disconnecting issue which I can't seem to get past no matter what. Is there anything anyone can suggest that might solve that issue? I've done every test suggested so far, changed the KCepter, Changed the computer and along with it, the installation of Blender and can't get past this disconnect issue. That only leaves the hub and the Pi as constants.

What are the chances that one of them would be likely to cause an issue of that sort? I could replace the Pi, but I only have the one hub.

daylanKifky

HalloweenBob the disconnecting issue which I can't seem to get past no matter what.

Do you mean the addon stopping because of the division by zero bug? Have you tried the patched version i described above?

HalloweenBob

Just tried the patched version of the addon.

SUCCESS!!!!!

It has been connected and been showing good smooth movement now for 10 minutes with no glitches or disconnects.

That's it! Now, I need to put together the whole chain and start moving around the model, then get to work in converting the output to a usable format for the software I use for the skulls.

Thank you daylanKifky and everyone else who contributed here.

Whatever was in that patch fixed this up good. Do we know why some people need the patch and others don't? Also, do we know if someone who wasn't having an issue used the patched version, would it give them problems, or just keep working. If it doesn't cause anyone a problem, perhaps the patched version should become the main version.

HalloweenBob

I was trying to put together the KCepters in the right order and assign them the proper jumpers for channel numbers, and came across this listing in the Default_biped .xml:

It says that the order for the arms is forarm, arm, then hand labeled 0, 1 and 2 or the first jumper, second jumper, third jumper, when it seems that the actual order should be arm, forearm, hand as shown in the diagram here: https://wiki.chordata.cc/wiki/File:DefBipedConf.png. If the forearm actually has a setting of 0, or jumper 1 as an identifier, that would mean that the KCeptor that comes first out of J1 should be identifier 1, then the next one in that chain should be identifier 0, followed by the hand at identifier 2.

What are the correct setting here?

I have to review all the instructions for moving the Default_biped model, because I thought that since my KCeptor model was reacting correctly to the motion of the KCepter, when I switched to the Biped model, the motion of my KCepter would move a portion of that model corresponding to J1, position 1 with identifier 0, which depending on where you look is either the left forearm or the left arm. I got no motion. Where can I find the instructions for creating motion with the default_biped model. Does it require a different command to the Pi? Do all the KCepters need to be connected? I think it's all working now, but I am just missing something. Also, another question. If I were only interested in capturing the motion of the head, would I only need a single KCeptor pluged into J2 and set to identifier 2 (the third jumper), or do I also need the Dorsal KCepter connected in order for the head to know where it is?

daylanKifky

Hi
There was a naming confusion from the beginning on our side. The Picture you linked has the first naming convention we used. See here for more details about it: https://forum.chordata.cc/d/98-build-log/19

As I said in the linked thread the naming conventions will change in the future, but the current armature works with the xml you pasted

In order to capture the complete body you should start the notochord with the default_biped.xml like this:

bin/notochord -c default_biped.xml <YOUR IP>

HalloweenBob If I were only interested in capturing the motion of the head, would I only need a single KCeptor pluged into J2 and set to identifier 2 (the third jumper), or do I also need the Dorsal KCepter connected in order for the head to know where it is?

If you want to get spatial translation of the head in reference to the hips you would need to use the three central KCs. If you just want the rotation of the head you can omit the other ones

HalloweenBob

OK, I tried to use the default_biped.xml tonight and couldn't get it to move at all. I thought I would start by trying just a single KCepter, the head. I plugged it into J2 on the hub and set the identifier to the 3rd jumper position (The closest one to the input socket) That seems to be where the xml expects to find it.

I used the following instructions to set everything up and run it:

CAPTURE PROCEDURE

Open New Project in Blender
Delete EVERYTHING. That box, the camera, the light, everything.
Select Window > Chordata > Add a Mocap Avatar to the scene
Select the "Mocap" tab that appears
There will be three nodes, the Notochord node, the Armature Node, and a Status Node
Add a new "Record" Node.
Connect the "Data Out" output of the Armature Node to the In on the Record Node.
Set the Target Object in the Record Node to the Chordata Biped.
Make sure the Notochord node is not in "Demo Mode"
Start Notochord on the Pi with ./notochord -c ../default_biped.xml <IP ADDRESS> Where "<IP ADDRESS>" is the actual IP address of the computer running Blender. No "<" symbols, just the number.
Hit "Connect" on the Notochord Node in Blender
Click "Show Advanced" on the armature Node to reveal Timed Calibration.
Click that button, making sure to set the timer for the appropriate number of seconds.
Look towards the SOUTH and assume T-Pose for Calibration.
When Calibrated, Hit "Record" on the Record node. And click it again to turn off the capture.
Each pass is saved as an "action." Select the "Active Action" you want from the pulldown menu in the node.
Hit "Play" on the Record Node to preview.
Select Chordata_biped in the Collection window of Blender. The motion capture data will show in the timeline.
Select "Export-> BVH" to make a BVH file to apply in another program.

In the SSH window, as soon as I sent the command, it started giving me error messages saying that it couldn't find all the KCepters that I wasn't using. I thought I would be able to only use one if I wanted to. It would seem that is incorrect. I did the timed calibration as outlined in the list above, and then started moving the KCepter, but it had no effect on the model.

Do I have to plug in every KCepter just to test the motion for one?

Perhaps I need to make my own xml that only includes the one KCepter, if I want to do that. I'm not sure. Ultimately, I want an xml that only contains the head, and the arms. For my application, those are the only moving points. The rest of the body remains static. I don't even need the hands. Just 5 KCepters (Although I may include hands for future expansion).

How should I be proceeding in order to make an arrangement like that to work?

daylanKifky

HalloweenBob Do I have to plug in every KCepter just to test the motion for one?

If you pass an xml file with the flag -c the notochord will try to find every KC described there, and assign the corresponding name to it. In order to capture just the head you can:

Modify the xml to include just that KC, in this case it will have a meaningful name (for example head)
Use the --scan function, in this case the notochord will look for connected KCs and assign generic names based on the location and value of the KC (for example kc_CH1-2)

When the data is sent to blender the armature will be moved if it receives a message from the notochord matching the name of one of the bones. The current armature does have a bone named head so you will see it moving if you used the first strategy.
You could also rename the bones on the armature to match the generic names given by the notochord to each sensor if you prefer the --scan method.

Let me know if this solves your doubts

daylanKifky

PS: The Dump node can be useful to better understand the messages you are receiving from the notochord. Take a look at this video we recently made where we explain how to add and manages nodes. together with some other basic blender actions.
https://forum.chordata.cc/d/136-new-video-blender-basics

HalloweenBob

I know it has been talked about here on the forum, but can you point me to a thread or something on the Wiki that tells me exactly what the required parts are, and the correct syntax to a custom xml file so I can make one using just the parts I will need? Or even a link to the default xml that I can just edit out the parts I don't need. If I remove all the parts related to the legs for example, do I remove all references to them or just the KCepter branches leaving the main Branch names there, but empty? I don't know if it looks for the entire structure of the xml to work with the Biped model or if it doesn't need it all. I hope I'm explaining this correctly.

HalloweenBob

I found a copy of the default_biped.xml file here on the forum. I will modify it for what I need and post it here. Hopefully someone will be able to tell me if I have done it correctly, or broken it somehow. I won't be able to test it until late tonight, so the feedback will help me save trial and error time tonight.

HalloweenBob

OK, here's what I have. I only care about the arms and the head. I don't really care about the hands, but have left them in just in case I add motion to those in the future. As a reminder, I am using this to program lifesize skeleton animatronic props. They are static except for the arms and the heads. The bodies are clamped to stands, so there no way for them to move their legs, torso, the dorsal area, or anything else other than the two arms and 3 axis motion of the head (and their jaw, but that is being handled in a different way).

I will post what I did to modify the xml file, and would ask that someone verify that it would indeed work, or if I removed too much of the main structure and would cause it to crash.

I also have questions about the IP address embedded in the xml file. Is that supposed to be an address in my local system? Is is supposed to be the address of the device running blender, or the Pi? I ask because it looks like a local network address, but it is certainly not my local network address.

My final question is do I name this file something unique, and save it to the notochord/bin directory? I don't know the SSH command to move or copy files, so I would need that. Once in the correct directory, I assume I would follow those numbered directions in my previous post from yesterday and use the -c command just modifying it to reflect the new filename I create. Does all that sound right?

Here is the modified xml file I created

modified-biped.txt

2kB

This is the text from it, in case it didn't show up in a readable format:

<!-- Chordata.xml -->
<Chordata version="0.1.0"> 
    <Configuration>
            <KC_revision> 2 </KC_revision>
            <Communication>
                <Adapter>
                    /dev/i2c-1
                </Adapter>
                <Ip>
                 192.168.85.123
                </Ip>
                <Port>
                    6565
                </Port>
                <Log>
                    stdout,file
                </Log>
                <Transmit>
                    osc
                </Transmit>
                <Send_rate>
                    50
                </Send_rate>    
                <Verbosity>
                    0
                </Verbosity>
            </Communication>
            <Osc>
                <Base>
                /Chordata
            </Base>
                
            </Osc>
            <Fusion>
                <Beta_start>
                1.0
            </Beta_start>
                <Beta_final>
                0.2
            </Beta_final>
                <Time>
                5000
            </Time>
            </Fusion>
        </Configuration>
    <Armature>
            <Mux Name="main" id="0">
                0x73
                <Branch Name="left_arm" id="1">
                        CH_1
                        <K_Ceptor Name="l-forarm" id="2">
                            0
                        <K_Ceptor Name="l-arm" id="2">
                                1
                                <K_Ceptor Name="l-hand" id="2">
                                    2
                            </K_Ceptor>
                        </K_Ceptor>
                    </K_Ceptor>
                </Branch>

                <Branch Name="body" id="1">
                        CH_2
                    <K_Ceptor Name="head" id="2">
                                2
                    </K_Ceptor>
                </Branch>

                <Branch Name="right_arm" id="1">
                    CH_3
                    <K_Ceptor Name="r-forarm" id="2">
                        0
                            <K_Ceptor Name="r-arm" id="2">
                            1
                                <K_Ceptor Name="r-hand" id="2">
                                2
                                </K_Ceptor>
                            </K_Ceptor>
                    </K_Ceptor>
                </Branch>
            </Mux>
        </Armature>
</Chordata>

Thank you!

daylanKifky

HalloweenBob I will post what I did to modify the xml file, and would ask that someone verify that it would indeed work, or if I removed too much of the main structure and would cause it to crash.

It's looking right to me. It will try to read 7 sensor in total, the complete hands and the head (as you described). By the way: at the beginning of the execution the notochord will validate the structure and syntax of the XML, so if there's an unperceivable syntax error it will inform you.

HalloweenBob I also have questions about the IP address embedded in the xml file. Is that supposed to be an address in my local system? Is is supposed to be the address of the device running blender, or the Pi? I ask because it looks like a local network address, but it is certainly not my local network address.

It is the same address you normally pass to the notochord as a command line option. We normally don't mention this because most people don't tweak the XML, but you can just write the address of the PC running blender there instead of passing it to the notochord every time. Many other options can be set in the XML as well as in cmd line but the latter ones (if present) will overwrite the former ones.

NakedRabbit

Is it me, or does this part look wrong?

               <Branch Name="body" id="1">
                        CH_2
                    <K_Ceptor Name="head" id="2">
                                2
                    </K_Ceptor>
                </Branch>

I ask because I had issues with this exact same sort of thing. This would indicate that J2 on the Hub has one Kceptor with the jumper at J5 set to the THIRD position. My understanding was that you should have it set to the FIRST position for the first Kceptor on the line, and then the XML should have a value of "0" for that Kceptor. But maybe it does not matter as long as it is consistent? I dunno...

HalloweenBob

NakedRabbit That's a good question. I assumed that the jumper identifies that KCepter as the "Head" so it knows what thing to move around, but maybe it's just the name or the ID line.

By the way, that particular branch only has two items in it in the regular xml. They are set to the 2nd and 3rd jumper. That branch does not have a KC set to the 1st jumper.

If I have an issue with it, I'll try changing the jumper, but if that were the case, it wouldn't work in the default_biped.xml file either.

I'll know later tonight when I get home and get to try it out.

« Previous Page Next Page »