Progress/Experience using Chordata

HalloweenBob

Thanks for the heads up on the KCeptor_R1 label. I was wondering about that. Regardless, my KCeptor did not show up in the download list. I tried checking the Osc Stream as you suggested but got the following result:

I tried it both with `/notochord, and with ./notochord just in case it was a typo or something. The result was the same.

Any other suggestions? This is so close now. The Pi thinks everything is fine, and I can communicate with it through SSH.
That means that it is communicating with my computer. I'm not sure where to go with it next. I was thinking of trying a different cable to connect the KCeptor to the hum, but if that were the problem, I wouldn't have been able to calibrate it.

duncan006

Try this:

./notochord/lib/oscpack_1_1_0/bin/OscDump 6565

And when you run the notochord in another window, make sure it's set to localhost.

HalloweenBob

How do I set it to localhost? I'm using PuTTY and I connect by using the IP address of the Pi.

HalloweenBob

Here was the result

duncan006

Make sure to run
make dump
in the /oscpack_1_1_0 folder first

HalloweenBob

How would anyone ever know to do this stuff? Will I have to do this every time I want to run this? I'll give it a try.

daylanKifky

HalloweenBob Will I have to do this every time I want to run this?

The procedure @duncan006 is suggesting can be uses to troubleshoot connection problems like the one you are facing. It doesn't have to be repeated once you get it working.
I have the feeling there's a firewall blocking the messages. Many windows users reported similar problems, and had to make many attempts to get the firewall configuration right. The oscdump procedure confirms data is coming out from the notochord by redirecting it directly to the raspberry itself, thus avoiding any possible firewall

HalloweenBob

OK, it finally worked, sort of. It understood the command, but apparently didn't find anything to listen to.

I left it listening for about 2 minutes before pressing ^C. Also, During that time, I connected with Blender, and was moving the KCeptor.

duncan006

Apologies if the comment that I linked earlier didn't help enough.

The osc listener runs simultaneously with the notochord and does not connect with blender in any way. In order for it to capture the data, you run the notochord in another window connected in the same way with SSH. Then instead of your computer IP, you use localhost.
./notochord --scan localhost
If the problem is with the communication to blender, you'll see data in OscDump. If the problem is the k-ceptor's communication, you won't.

HalloweenBob

OK, just got back to this tonight. I have had some very brief success. I went through everything again, and started notochord, scanned the computer running blender, connected found the right KCeptor and selected it and it started moving exactly as it should in blender!

That lasted for about 5 seconds then I got the error message I have included here and Blender disconnected. I tried again a dozen times and got disconnected every time, most of the time faster than I could reach for the KCeptor. A few times I got a few seconds before it crashed.

At least I know I'm connecting correctly and don't have WiFi or Firewall issues.

Any ideas?

HalloweenBob

Tried again just for laughs. This time it started and stopped giving me the error as before, but when I restarted it, things were different. It didn't disconnect, but instead the KCeptor model froze while I was moving the device, and I got this message:

It doesn't even look like a real sentence and I have no idea what it means.

Disconnecting and reconnecting made no difference. The KCeptor Model remained frozen and I got this error message again, but it still said it was connected in blender.

daylanKifky

Hi,
The float division by zero bug is already reported https://gitlab.com/chordata/Blender-addon/-/issues/7
You should be able to sidestep it for now by unplugging the Stats node.

Let me know how it goes

HalloweenBob It doesn't even look like a real sentence and I have no idea what it means.

It's just the tooltip containing a brief description about the "Connect" operator but written with my terrible english in combination with little attention paid to these details. To anyone willing to start contributing on the code: correcting the many weird sentences that are distributed among all the codebase would be an easy task.

HalloweenBob

No problem on the sentence. It was hard for me to tell if there was a thing called a Parses Tree or if something was parsing a tree (Which makes more sense) I will look up how to unplug the Stats node.

daylanKifky

HalloweenBob
you can also just select the node and hit delete

HalloweenBob

daylanKifky Thanks! That is useful info for me. I will try that tonight.

HalloweenBob

More trouble. I tried everything I could find. I pinged the computer running blender from the Pi and got valid responses. I was connected with SSH, so WiFi is fine. I installed and ran the copp_server using 2 separate SSH windows and it did show me data streaming when I started it. I was able once again to see the correct KCepter show up in my drop-down list and I was able to move it and see it mimicked in blender for a few seconds, then it automatically disconnected with the same divide by zero error as before. Every subsequent attempt immediately disconnected less than a second after connecting. I was unable to get it to last more than a second or two just like before.

My communication is working between devices as proved by being able to log in with SSH, the ping test, and the copp_server. Also the initial several seconds of seeing the motion on the screen, so that is not likely the problem. Not 100% sure how to eliminate the stats node. I clicked on it so that it showed up, and deleted it. I tried again and there was no difference. I clicked on it again, attached it to the main node and then deleted it. Same results.

I decided to try a different KCeptor. I powered everything down and started from scratch. I went to calibrate it and followed the procedure in the video, and at the end, it said it calibrated the KCeptor successfully, but when I looked back, I saw issues. I didn't save a screenshot from the first one I calibrated, so I don't know if it had the same issues.

First, I say many too much variation warnings while the KCepter was sitting absolutely still on my desk with no vibration that I could detect. Second, when it got to samples collected, it said zero, but then calls it a success at the end.

I don't know if any of that happened with the first KCeptor, and I don't know why that would cause it not to stay connected, but I did find it odd.

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:

« Previous Page Next Page »