The Blender addon is unable to connect with Notochord.

Firezac

daylanKifky I did the whole process of resetting the attribute dtparam = i2c_arm_baudrate = 550000, restarted the raspberry but nothing happened, just the errors keep happening.
About your questions:
1-I am using the raspberry pi model B + first version.
2-In this case, the error is accusing all sensors, not just the tips.

daylanKifky

Firezac About the order of the sensors, could you explain this mark (0,1,2)

He's referring to the translation value of the sensors, the one that's is set with the jumper J5. Admittedly, is kind of hidden, no explicit marks on the PCB. This is something that will be improved on future versions.

Firezac -I am using the raspberry pi model B + first version.

This is probably what's causing the issue. The system was developed and tested with a RPi 3 (or superior) the earlier models might work, but is hard for us to give support for them. Do you have opportunity to borrow a model 3 or above to test if it solves the issue?

Firezac

On the sensors, is this marked on the K-Ceptor or the HUB? Is there a difference between the K-Ceptors or are they all the same?
About the Raspberry, it makes sense. Unfortunately, I don't have a model 3 here, but I will look for one. Can this error happen even with the individual tests of the sensors working correctly?

daylanKifky

Firezac
The KCeptors of Revision 2.3 (the ones of the second beta'testing program) are all the same. But in order to co-exist in a given branch their translation address should be different. This translation address can be set by moving the black jumper to one of the rows of the J5 header

Firezac

Hello again!
I ended up taking a long time to return here on the forum due to some personal problems and involving my Chordata HUB, as I told by email to daylanKifky .
In short, I made the switch to the Raspberry Pi 3, but the problem remained. During the tests to try to solve, my colleague innocently ended up removing one of the plugins during execution, burning the HUB.
I tried to follow the advisors presented in these links for an alternative way to connect the card (https://forum.chordata.cc/d/97-killed-my-hub), but I am unexpected with the electrical development part and I was afraid to end up making even worse mistakes over the HUB of my Chordata.
So, I would like to ask if before we continue to solve the problem if you could indicate a visual material (a video or step by step for images) that can help me how to make the 3v3 call through SBC?
Thanks for all the help!

Firezac

Understand. I imagine that would not be the case, due to the raspberry problem, but would you know to indicate where I would have a tutorial for me to check this process?

daylanKifky

Hi,
I made a video explaining how to proceed to use the alternative power source. Let me know if it helps

https://forum.chordata.cc/d/132-beta-testing-troubleshooting-video-series

Firezac

Hello again!
Again, I'm sorry for the delay, unfortunately, I've been running very little in the last few days due to work and this has slowed my progression with the Chordata stages a lot.
First of all, I just wanted to thank you so much for posting the videos, they were extremely helpful and my HUB is back to working properly! Now I can resume testing with K-Ceptors, which I should do in the next few days to see if the sensor detection problem still occurs.
As soon as I perform the test, I'll post it here telling you if it worked, ok?
Again, thank you very much to all of you for your help and patience! 🙂

Firezac

So, now that my HUB is back to working properly and I'm using the Raspberry Pi 3, I tried the whole biped capture procedure again, and in the end, the same error continues to occur: The system does not detect the sensors even if all are properly connected.
I did some calibration tests with the sensors and apparently all of them, during the calibration test, worked correctly, only during the complete test that this error happens. How do you think I can proceed?

Firezac

Adding: I did a capture test of the biped model in 3D while making the raspberry run the whole process again. While processing and he accused the errors of the sensors, the model detected some movement, because while the errors ran, he ended up moving to this position:

daylanKifky

it seems like it's not recognizing any KC after the first one in each chain. Please send me this information to better diagnose the problem.

Are you using self crimped cables? as the ones described in the second video from the troubleshooting series
Are you using the Raspbian image we provide?
Could you send me the output of this command? scripts/get_i2c_freq.sh (should be runned from the notochord folder)
Could you send me some pictures of your setup? I'm interesting in seeing details of the KCeptors, their translation values (jumper J5) and the order in which they are connected.

Firezac

About my Chordata:
1- Yes, I am using the same cables provided by the Chordata team.
2- Yes, I am using the Raspberry 3, the raspebian - notochord 0-1-2, downloaded from the Chordata website.
3- Regarding the shortcut you gave me, the system simply accuses that the path or directory does not exist, I tried the case by several different paths. Here is the print:

4- Regarding my board, here is the photo:

Well, considering that the file was not found by the search, I am thinking of maybe downloading the new version of the notochord, maybe "renewing the system" solves this problem, no?

daylanKifky

Hi!

Unfortunately the cables we provided with this beta-testing edition are not working well. We are suggesting to use another type of cables as explained in the second video of this series: https://forum.chordata.cc/d/132-beta-testing-troubleshooting-video-series

Probably the fastest way of getting them is crimping them your own as explained here: https://wiki.chordata.cc/wiki/User_Manual/1._Chordata_parts/1.2._Cables
If you don't fell like crimping them drop us an email.

Firezac am thinking of maybe downloading the new version of the notochord, maybe "renewing the system" solves this problem, no?

You are indeed probably using an old version of the notochord. Check it by running ./notochord -V. The current one is 0.2.0.
This would explain why there's no get_i2c_freq.sh script
In order to update (from the notochord folder)

git checkout develop
git pull
scons -j3 debug=1

« Previous Page