Gloves (16 bones)

Nina

daylanKifky
3dviewer.net

Thanks for your quick reply, with the connectors we are still deciding, once we select I would post an update - ok, so finally on the sensor board the ID mentioned to be specified by 4 fixed resistors (black ones on the top left, accordingly to the table) - then for usability ID value could be marked on the bottom left white area by hand - aren't we missing something?

—-
my genious friend assisting me with the assembly explained technical details:

In our version of PCB, we add four resistor in divider to set ID (two upper and two lower in series), that allow use 1% E24 row resistors.
We change package of LTC4316 (DFN10), M24C02 (SC70-5), capacitors, resistors and led (0402) to minimaze PCB area. We want to use passive components in package 0201, but have some problems to buy they on our dilers.
Input/output jack is truhole pins on PCB. In this hole can be mouted fluoroplastic wires or PBD1.27 (PLLD1.27 with wire).
FFC/FPV of miniature jack, like a FH, have a sufficiently large width and don't fit into the concept.
FFC flat ribbon cable also has excess width, and small steep of pins dont't guarantee current load. The small distance between the boards also does not allow the use of a flat cable, not only due to mechanical stress, but also non-standard lengths (which will need to be ordered additionally, which is inappropriate for a single project).
PCB input/output jack traced in mirror, that can be use A-B sample cable and transfer signal in two directions.

daylanKifky

Nina then for usability ID value could be marked on the bottom left white area by hand - aren't we missing something?

Will the resistors be soldered by hand? if that's the case then it makes sense to label the KC by hand (I suppose you friend is aware that soldering 60x0201 components is a time consuming process)

I see you are taking into consideration a couple of options regarding the connectors. Let me know how it turns out.

Nina PCB input/output jack traced in mirror, that can be use A-B sample cable and transfer signal in two directions.

Good idea, don't know what was I thinking when I arranged them this way. Here's a comment about that

daylanKifky

Nina We change package of LTC4316 (DFN10), M24C02 (SC70-5), capacitors, resistors and led (0402) to minimaze PCB area.

Oh, by the way.. I assume that the SC70-5 package of the memory has no configurable i2c address pins. The EEPROM address on all the K-Ceptors on the system should be the same. The current public K-Ceptor's EEPROM has an address of 0x51

IGD

daylanKifky
For soldering 100 chips, I spend less than 45 minutes. It not a problem. At this moment, it is a prototype in a single copy, and all 45+ pcb's can be mounted by my hand for a one-two days with long and many coffeebreaks)

About jack and connectoin. I traced DIL 2x3 universal thuhole vias. On PCB it is side A and side B. Jack mirrored by horizontal. PCB can be connected together only side A to side B, and cable looks like a parallel trail with independent direction. In SIL config, this problem don't be actual, because no cross-x data transfer.
On the side of HUB, cabel have two modifications: HUB-TO-SIDE_A to right arm and HUB-TO-SIDE_B to left, for example.

IGD

daylanKifky
Hellow. Can you say, why EEPROM have adress pins A2A1A0 config like b'001'? Why we can't use b'000' (0x50)? Other I2C device on the bus have different adresses.

Nina

daylanKifky
Hi. We hope to get a response from you.

so generally the most important questions currently are:

can we use EEPROM address 0x50 on our mini k-ceptor schemes assemblies instead of using 0x51?
what changes to the software we need to do after extending system with higher amount of our mini-kceptors?(eg. after adding gloves)
a) do we need to rebuild RPi program?
b) do we need to rebuild Blender plugin?
c) are there any of other guidelines?

daylanKifky

Hi,

My apologies for the delay on the response. I didn't see @IGD's question before.

IGD why EEPROM have adress pins A2A1A0 config like b'001'? Why we can't use b'000' (0x50)? Other I2C device on the bus have different adresses.

The EEPROM is affected by the address translator, which applies an XOR to all the addresses after it.

Having (for example) an EEPROM with address 0x50 on a KCeptor with translation value of 1 would clash with an EEPROM with address of 0x51 on a KCeptor with a translation value of 0.
The bottom line is: it doesn't really matter which address you choose for the EEPROMs as long as it is consistent on all the KCeptors you wear. If all the K-Ceptors you use are modified ones, you will need to set the new address by changing the value on the file EEPROM.h:58 before compiling notochord.

If you want more detailed information on how the system works you will find plenty on this document.

b) do we need to rebuild Blender plugin?

You won't have to rebuild the add-on, but you have to provide an Armature that matches the new distribution of the K-Ceptors.
You will also have to provide an XML to match the Armature as well
(The idea is to automatize the process of creating the XML from the armature in the future, but for the time being you have to write it down manually 🙂)

I you can use the default_biped.blend file and the default_biped.xml as starting points. On the chapter §2.1.2.1 of the pdf you will find information on how the XML should be structured. The "Name" property of each KCeptor tag on the XML should match the corresponding bone on the Blender armature.

IGD

daylanKifky Having (for example) an EEPROM with address 0x50 on a KCeptor with translation value of 1 would clash with an EEPROM with address of 0x51 on a KCeptor with a translation value of 0.
The bottom line is: it doesn't really matter which address you choose for the EEPROMs as long as it is consistent on all the KCeptors you wear. If all the K-Ceptors you use are modified ones, you will need to set the new address by changing the value on the file EEPROM.h:58 before compiling notochord.

Ok, thanks! We will use our version of Kceptor PCB with EE adress 0x50 and modify config file. This question based on the possibility to change the address in "notochord". I am mostly a hardware engineer and a microcontroller programmer. Peripheral interfaces are not a problem for me, I understand how your development works, questions arise only at the border of high-level programming.

fguilini

daylanKifky The idea is to automatize the process of creating the XML from the armature in the future, but for the time being you have to write it down manually

Hi,

I have experience with python and blender plugins (including exporting) and would love to contribute to this project by creating that concept.

Should I

fork the existing blender plugin and extending it
fork the existing blender plugin and create a separate plugin in the same repo
create a separate repo

daylanKifky

Great!
I can tell that you have a high degree of expertise on the subject, but since this is a pubic forum the verbose answers might help clarify other people problems 😉

daylanKifky

@IGD @Nina
By the way, once you test your design it would be great if you can share it so others might use it as well

Nina

daylanKifky
Yes, of course we will share this.

IGD

daylanKifky
There is a question about the ENABLE signal of your KCeptor board. On the hub board, this signal is permanently connected to power and has no control. For what purpose is the ENABLE signal of LTC4316 output from the sensor to the hub?

valor

daylanKifky & Nina
For connecting the finger Kceptor from the Hand HUB i'd suggest the QWIIC connectors which is a miniature 4 wire 1mm pitch JST-connector.
It's already used for I2C on some Sparkfun modules. The wires could be purchased ready crimped.
Here's a size comparision to a Modular Jack

daylanKifky

The ENABLE line is used to control the reset of the LTC4316 from the master without resetting the IMUs.

Keep in mind that this is a beta release. We published the same prototypical version that we use for development and testing. Some functionalities like this one are for debugging/testing purposes.

You can just leave it tied to VCC.

AxonSpark

Just popping in this thread to cheer on all you hardware geniuses! 😁 Can't wait for the finger sensors add-on!

AxonSpark

@IGD & @Nina,

Just wanted to check in to see how your progress on adding finger K-Ceptors is going.

Thanks!

valor

daylanKifky
Can't we just use raspi3's and raspi4's extra I2C busses?
As far as I know, both I2C-0 and I2C-1 busses are available for general use.

daylanKifky

Hi @fguilini and welcome to the forum!
I'm happy to know you want to contribute to the addon development.
We are currently working on the new node-based version of the addon, and were planning to implement this feature in the release after this one (v1.1.0).
Since you are willing to take care of that we might be able to include it in the upcoming release which would be great!
The idea is to create a node based section to represent the way sensors are connected between each other (which might differ from the way the bones are related in the armature hierarchy), and obtain the XML from that. Do you fell you can take care of it?
Write me to bruno at chordata dot cc so we can better organize the work

ComradeZoned

daylanKifky Asking here as there is not enough information ready yet on the wiki.

Can trackers/bones theoretically follow a branched hierarchy despite being on the same r-arm/r-hand bus?
For example, using the existing r-hand bus, I would attach trackers for individual fingers to the same bus, preferably without multiplexing.

I do understand there is a performance hit when attaching more devices to the same bus. I am thinking of a similar solution to @Nina but with six total trackers per hand (at a cost of lower tracking accuracy).
[Worse case scenario, more hubs could theoretically be created specifically for the hands using the relatively inexpensive Pi Zero W]

Thank you,
Thomas

daylanKifky

ComradeZoned For example, using the existing r-hand bus, I would attach trackers for individual fingers to the same bus, preferably without multiplexing.

Yes you can do it. The LTC4316 on the KCeptors allows you to configure the i2c address with up to 127 different values. This number is in practice more limited, since it is applied as an XOR to the real addresses of the devices in the KC: Accel + Gyro ( 0x6b ), Mag (0x1b) and EEPROM (0x51).
That's why in the current KCs only the lowermost 4 bit of this translation address are exposed. Leaving you the possibility to attach up to 16 different KCs on the same branch. If you need more you would have to tweak the hardware and carefully choose the values.

There's no performance hit, is just that you will have to limit the sampling rate to allow the 400kHz bus to read all the sensors in the hierarchy. In fact adding multiplexers results in a small overhead, since each open/close of the gates is an i2c write.

ComradeZoned [Worse case scenario, more hubs could theoretically be created specifically for the hands using the relatively inexpensive Pi Zero W]

The Hubs can work without a dedicated raspberry, they can be controlled from the central one.

Let me know if I answered your questions

« Previous Page