b . (I had to move around the handles so it's one female and one male handle per side, rather than two males / two females on a side. Because this way the motors are distributed in a better way, as can be seen in the youtube link below. It's getting... pretty tight in there. There's a mouse encoder strapped on the motor along with reduction gear for the yellow gears that will move the cubes around. In other words, I'll know with a very high resolution how far I've pushed another cube.

And then it's a question about "Well... how will everything get its energy?". My teacher proposed using Qi, which is like a wireless charger, I did not like that idea because it would be too inefficient and make every cube pretty expensive. So I'm "forced" to use some kind of slip contacts.

Here's one solution, I know the colors are horrible and that the male handle flashes in the video, but I'm not a director or a film producer.

I realized afterwards that when there's 3 cubes arranged so there's two on the ground and the third cube resting on top. Then the cube on top can move from one cube to the next. So in other words the slip contact / handle connector have to give VDD and GND during the entire movement, or else the motors die. So therefor I have a minimum width of the contacts. But the communication contacts will short an entire row. Like if the 3rd cube that rests on the 2 other cubes, as in the scenario, then if it's half between the two cubes, then I'll short the communication pins horizontally. That is not acceptable, so I've made the 2 pins in the middle of the handle shorter, meaning that if the 3rd cube above is half way through it's movement, then there's no way of talking to that cube. However, if communication is needed then it's possible to put a fourth cube on the side, and a 5th below that one, moving a quarter and keeping the communication between the 2 below and the 3rd. I don't know how much you, the reader understood of that I just said, but I don't have time to make an animation of that. Just pointing out future "problems" that can be solved in numerous ways.

Either way, I modified the cube so it matches what I said. So I removed a couple of contacts on the female handle and made a chassi. In the center of the cube there's a 24x24x24mm cube (dark blue in picture below) which is hollow, in there I will place circuit boards stacked on each other. It will be custom made circuit boards containing the processor and 18 full bridges. It will... be tight... I might have to put some PISO shift registers in there for the sensors that measure end points of the handles. It won't look pretty, not pretty at all. The encoders will have to be wired directly to the atmega onto the interrupt pins.

And that brings me to the next part which is how is ONE atmega supposed to communicate with 6 other cubes (neighbors)?. There's only one TX/RX port, and I am not going to use a multiplexer on that channel, I have to think of something clever. And there's no clock pin. So I'll have to implement a protocol in software that can work with codes that looks a little bit like Manchester code.

And that can be done with a circuit that I came up with like this below. It's just the right side that I need to communicate through 1 wire:

• 10k
• 330nf
• XOR
• 10k
• 100nf

The left hand side of the circuit is just to simulate data being sent.

So in other words, the communication will not be the fastest, the reason for why I'm not using anything more "normal" is because I need to solve the communication in software which is slow. So I'm sadly fine with using a slow solution like the circuit above.

Oh well, another problem that I came across was what you see in the first video in this project log. It shows how a male handle is gripping a female handle. If the cube with the female handle is stationary and the cube with the male handle is floating in air, then the cube will follow the female handle trying to let go. So when the cube thinks that "Oh, it's okay to pull in my male handle now", it will only grip harder and not do anything and break. The problem can be seen in the picture below.

The left side is a cube only holding onto the handles, if the male handle wouldn't be there the left cube would fall down.

A solution to that problem is to insert some skeleton/chassi shield in the female handle, so when the female handle goes back, the male handle gets blocked and stays, so it later can be retracted into its own cube.

So next on my agenda will have to be to remake the female handle, insert some blocking pieces, like bars or something. And then it's time to continue with the skeleton/chassi that holds all the motors. Then it's time for testprinting.