BUILD LOG

HalloweenBob

Thanks for that. I have downloaded your files and will be printing them soon!

The only thing I didn't see was a file to hold the Pi. I had found the Hub file earlier. Have you made a container of a combined container for the Hub/Pi together?

These files will be incredibly useful to me.

Bob

duncan006

HalloweenBob If you're looking for a combined Hub/Pi case, @DigitalStages designed a pretty nice one that you can find here: https://forum.chordata.cc/d/106-mocap-system-related-3d-print-designs/4

HalloweenBob

That's a nice one, Thanks!

NakedRabbit

That's the one I keep referring to as better than mine!
I just searched "Raspberry Pi case" on Thingiverse and found something pretty basic. I'm not linking to it because it's so basic.

NakedRabbit

WHAT FRESH HELL IS THIS?

So now that my hardware is worked out, and now that I was able to calibrate all the Kceptors, I connected everything in the suit... with some unexpected results.

@daylanKifky , I call upon your expertise! Help a beta tester in trouble!

I started up Notochord,and got this error message:

info~[ 105] Timer started, 21 nodes on scheduler
error~[ 274] error switching branch right_leg. Retrying.. (0)
error~[ 463] error switching branch right_leg. Retrying.. (1)
error~[ 651] error switching branch right_leg. Retrying.. (2)
error~[ 840] error switching branch right_leg. Retrying.. (3)
error~[ 1028] error switching branch right_leg. Retrying.. (4)
error~[ 1048] Too many errors when switching branch right_leg.
error~[ 1049] An error ocurred: Can't write to mux

Seemed like a simple question of not having the leg connected to the Hub properly. But the connection seemed tight. Ran it again, same error. On a hunch, I tried --scan.

info~[ 437] Scan: No Hub found
error~[ 5817] Fatal error: No armature, aborting.

Shut it all down, checked the connections. Rebooted, this time I ran i2cdetect -y 1 - it showed no Hub! Shut it down, reconnected the jumper wires. Tried it again, this time the familiar 73 showed up. Maybe just a bad wire? A loose connection? So I tried these things:

Shut down. Connected Head/Dorsal and Base only (J2 and J5). Ran i2cdetect -y 1, it saw "73." Ran --scan, it saw everything on CH_2 and CH_5.
Shut down. Connected arms and legs. Ran i2cdetect -y 1 and it saw "73." Ran the biped, it said the base was missing now. Then I ran --scan and it said "No Hub!" ran i2cdetect -y 1 again and 73 was gone.
Shut down. Disconnected Base. Started up, ran i2cdetect -y 1 again, 73 was back. Shut down, connected base, ran i2cdetect -y 1, 73 was OK with the base now! Ran the biped. It couldn't find right leg again, just like above. Ran --scan, and it said "No Hub."

I'm not sure what is going on. Could my Hub be disintegrating before my very eyes? Could somehow the "base" connector, so close to the leg connectors that keep disappearing, be broken or shorted? Could a bad wire be the cause?

The weird thing is that two days ago I used the exact same Hub to calibrate all my Kceptors out of the J1 connector on the Hub and everything was just fine.

Experience my frustration yourself! Full logs in this pastebin here:

duncan006

NakedRabbit I Noticed in your original post that you said you're using the dedicated power source configuration, powering the hub directly and the raspberry pi indirectly.

NakedRabbit I connected the Hub in the "Dedicated Power Source" configuration. I've been using a Raspberry Pi power supply, and not a battery, for testing purposes, and that seems to have been OK. Bear in mind that this log ends when I somehow torch the Hub, so if this step is significant, please let me know. The power supply is the usual 5V2A.

You may have fried the buck converter. Not sure if this is actually the case, but a test fix is easy - power the pi instead of the hub, switch the jumper on the hub, and add another wire from the pi gpio to the hub as shown here

NakedRabbit

@duncan006 - Oh, I fried the buck converter a LOOONG time ago. A few posts down I mention having rewired it for the other configuration already. I think I'm one of the first group to find out about this issue the hard way!

duncan006

NakedRabbit My bad! I looked through the thread for a bit to confirm, but must've missed the bit where you talked about re-wiring it.

NakedRabbit

HELP @daylanKifky !

I have been busy, but I was also waiting around somewhat for some assistance on this issue. I seem to be having some trouble.

Start up the Pi, with any number of Kceptors - it does not seem to matter
i2cdetect -y 1reports 73. Hub OK.
Run Notochord
Bombs out with error~[ 5730] Program aborted because of an error: Cannot set subAdress to slave device
Run Notochord again says info~[ 437] Scan: No Hub found error~[ 5818] Fatal error: No armature, aborting.
i2cdetect -y 1again, does not see the Hub.

I'm not doing anything else, just running those commands in that order.

Also, after having run sudo ifconfig wlan0 down the wifi is gone forever, and sudo ifconfig wlan0 up will not return it. Shall I start with a fresh copy of the Notochord image? It sounds like something dodgy is happening here.

daylanKifky

NakedRabbit
Do you get the same result with no KCs connected to the hub?

NakedRabbit

Start up, NO Kceptors.
2.i2detect -y 1 shows 73
Notochord with --scancraps out with info~[ 117] Armature Created. Floating point exception and back to the shell prompt.
But i2detect -y 1 shows 73 again.

This is infinitely repeatable. Does this mean a Kceptor is bad? If so I think I've narrowed it down to 1 of 3 that were connected when this died.

daylanKifky

NakedRabbit

It seems like the KCeptors are interfering. But if they were working before it's probably the new cables.

Let me explain how the multiplexer works in order to help you troubleshoot it.
It has a number of gates that can be opened or closed with the same bus that is used to read the KCs . At first start they are all closed, so no matter what you connect downstream it cannot interfere with the bus. When you run the notochord it sequentially opens one of this gates at the time, if a device is causing troubles the notochord won't be able to continue managing the multiplexer, so it will abort execution.
After that the multiplexer still has the "problematic" gate opened, so it might not be visible with i2cdetect.

NakedRabbit

This makes total sense. I wish there was a fast way to test my cables other than just making new ones and swapping them out one at a time... but I guess that's what I will do!

daylanKifky

NakedRabbit
We built an arduino tester when we were crimping a lot of cables for the betatesting program

here's the code in case you want to have some fun
https://gitlab.com/-/snippets/1927036

But perhaps just testing continuity with a tester on each cable (making sure it is not shorting other cables) would be a better way to go for you. Perhaps inserting the cable into unsoldered RJ11 connectors will help you expose the contacts

NakedRabbit

I am not actually in the habit of keeping unsoldered RJ12 connectors lying around, believe it or not!

But yes, thank you so much for sending this. I had found a few similar projects along the way, and will likely build one or the other of them once I can order these parts. I tried to scavenge them only to find that not everyone uses all six leads from an RJ12... I guess that makes them an RJ11 when you only use four?

Anyway, this tester should be a highly recommended part of anyone's kit, I think! More when I've built one...

daylanKifky

NakedRabbit I tried to scavenge them only to find that not everyone uses all six leads from an RJ12... I guess that makes them an RJ11 when you only use four?

When you use only 4 of the RJ11 or RJ12 you have a "6P4C", we use the "6P6C" version of the connector. The ethernet cables are "8P8C" and so on..
I still haven't found a real difference btw RJ11 and RJ12

NakedRabbit

More from the fascinating world of bad data!

I found a crappy cable in record time, but I thought I would share this output. The procedure was like so:

Start with the Hub and one Kceptor.
Start up, run i2detect -y 1
Verify the 73 and the Hub is working.
Start Notochord
Control C and run i2detect -y 1 again.
Shut down, keep adding Kceptors, repeat.

The bad cable makes i2detect run REALLY SLOW and shows no Hub when it finally ends. BUT... the other configurations, after running notochord, show this output!

i2cdetect -y 1
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:          -- -- -- -- -- -- -- -- -- -- -- -- -- 
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- 1e 1f 
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
50: 50 51 -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
60: -- -- -- -- -- -- -- -- -- -- 6a 6b -- -- -- -- 
70: -- -- -- 73 -- -- -- --

What fresh hell is THIS? Should I be concerned?

daylanKifky

It looks like a correct output to me if you have 2 KCeptors connected in one of the branches.

When you run i2cdetect before the notochord all the gates of the Hub are closed, so you only see its address (0x73). As part of the notochord reading procedure the gates of the Hub will be opened, exposing the downstream i2c devices. Each KCeptor has 3 devices:

EEPROM (0x51)
Acel + gyro (0x6b)
Mag (0x1e)

(the IMU components are exposed as 2 separate devices even if they come in a single physical package)

you are seeing the addresses of one KC with translation value of 0 (they remain as the original ones) and another with translation value of 1 (the Least Significant Bit of the address is flipped)

NakedRabbit

daylanKifky I just never saw any of it before, because I always ran the command BEFORE Notochord. So I freaked out!

Anyway, you may be glad to know that with a corrected cable everything is working just fine and I should be posting new captures soon.

Everyone may wish to know that
Cannot set subAdress to slave device
means you have plugged in a Kceptor the wrong way around! So when you get that message FIRST try flipping the Kceptor you probably plugged in upside down because it's the "base" and it confused you.

duncan006

NakedRabbit Regarding the "subAdress to slave device" error - I get this frequently when all of my KCs are connected properly. I usually just keep trying to run the command, and after 3-4 tries it works. Data collection still works perfectly once it starts. Thinking that there might be issues with my cables and the error pops up whenever there's an incomplete connection.

NakedRabbit

duncan006 I did not test thoroughly, but I did fix the bum cable and then got this error because the Kceptor was in backwards. So it may be a bad cable error, too, but I seem to have fixed the bad cables! Waiting on parts to build that cable tester, but I can proceed with captures anyway now, that is, when I can find time. Semester is starting up...

« Previous Page