Glaysche

This looks very cool. I like this much better than full custom battery boxes like BuWizz. This stays compatible with PoweredUp but can offer recharge ability and higher voltage. Awesome work!

You can share screenshots of the program. It’s not as good as sharing the program itself but it would make reasonable for anyone to recreate the program.

Congratulations on hitting 10,000 supporters! I really hope this makes it through review and becomes a set. I will be first in line to buy it.

I hear this a lot on this forum. It costs a lot of money to design, manufacture, warehouse, and distribute a new part. While this is true, this it literally TLG’s core competency. Doing this well has been critical to them becoming the dominant player they are today. I would argue that this, above all other things, is what they are the best in the world at. I would argue that they are more efficient and better equipped to bring new injection molded plastic parts to market than any other company in the world. I think they need to continue to invest here to be able to maintain their market dominance. We shouldn’t make excuses for them. We should expect excellence and they can and should deliver.

Huh, I tried to post a few days ago and I am still waiting for the admins to approve my post. Maybe they don’t want new members in their group?

This is great! Thanks for investigating this. You suggest they are encoding the channel name as a CRC32. That's a bit unfortunate. Collisions are not that rare with that. Probably not the biggest problem, though. Doing all communications over BLE advertising broadcasts with limited packet sizes seems pretty limiting. This reminds me of when Doom multiplayer mode first shipped (I'm sure I'm dating myself here). It did all communication over broadcasts and took down our entire campus network. Probably not a big issue here but it's still not necessarily the best architecture. I wonder what TLG's roadmap is for this feature?

I just upgraded to the new Mindstorms app (10.2.0). It has a new help center but more interestingly, it has an experimental hub to hub communications. I tried a quick test. I made two trivial programs: I ran them on two hubs with a motor attached to port A on each. It worked. Moving the motor on one hub caused the other to move. It was a bit laggy but not really any worse than using the touch screen remote. It was annoying to do the programming. I needed to download the first program to one hub then turn that hub off to disconnect. I then attached to the second hub and downloaded the second program. Then you can run the program on both hubs and see it work. It would be very nice to be able to attach to two different hubs simultaneously. Maybe even if it's just one hub per tab or something. I have questions about the implementation. Since you don't specify a destination hub in a signal, I assume this is just a broadcast? I wonder how this scales to more hubs? If you had a classroom full of Mindstorms stations, would they all interfere with each other? I also wonder if the protocol is lossy. I assume it is if it's broadcast. Also, since the "when hub receives signal" and "Received .... value" blocks are separate, if you receive two signals before you read the value from the first one, I assume you lose the first value? That sounds challenging to make reliable. They say this is an experimental feature. I wonder how open they are to feedback? If one wanted to provide feedback to TLG, where would they send it? I have sent multiple questions in the past to the Mindstorms email on the Lego support page and never received any reply at all.

Doing a low level API first makes a whole lot of sense. Do you think the semantics will be closer to TCP (reliable stream of bytes) or perhaps reliable datagrams? The difference being whether you maintain framing. I’m not familiar with the higher level API for EV3. What I was imagining for a high level API would be something like RemoteMotor or RemoteSensor. It would have the same API as a local motor or sensor but with the communication layer in the middle. I guess this would look the most like the PoweredUp app programming model. Anyway, thanks again for all the great work.

Thanks for the update on v3.1 and v3.2. The changes planned for those releases sound very interesting. I am also very interested in hub to hub communication. This is my initial use case: I want to be able to make a physical remote out of PoweredUp components. I can then make a remote that is appropriate for the model being controlled. My prototype uses the PoweredUp app but that has the huge downside of requiring a smart phone in addition to the controller. I'm imagining with Pybricks, we will be able to eliminate that and make it simpler to use, possibly with better latency characteristics as well. Do you have an idea of what the API will be for hub to hub communications? I'm wondering if this use case will fit well with your proposed API. The next thing beyond this is more complicated models. Imagine making a physical controller for the Liebherr that has 7 channels and 2 hubs. The controller would need 2 hubs as well. Would that generalized use case also work with your planned API?

I made a Studio model for it and made it available for free on Rebrickable: https://rebrickable.com/mocs/MOC-85202/glaysche/gantry-robot-3-degrees-of-freedom/ I made some minor changes from the version pictured above. The holder for the top pulley for the chain is improved. I made a few minor structural improvements. Here's are some renders:

Yeah, it's a similar deal for me. My MOCs are both esoteric and expensive. I choose to make them free on Rebrickable because I would rather see more people getting value from my work than a few dollars in my bank account. This is truly just a hobby for me. If I tried to make it a business, I think it would be less fun. That being said, I have no problem with people charging for MOCs. I have purchased a couple myself.

You can buy the Spike Prime angular motors from the Lego Education web site at least in the US.

My videos are not very good. I posted a couple in this thread. I might be able to get a better video this weekend.

When does voting close?

This discussion about color coding has been going on for a very long time. Obviously there are many opinions. I think the color coding is good in sets. It does help making the assembly instructions more clear. That being said, I would like the freedom to make my MOCs in the colors I want. The request I would ask of TLG is for them to also offer the key parts in other colors on Bricks & Pieces. I think this would be the best of both worlds. They can get the sales and reduced support volume from easier to follow instructions and AFOLs would also get what they want. TLG would sell more parts from B&P. Win, win, win. The only downside from TLG's point of view is that they would need to stock more parts in their warehouses.

I updated the model on Rebrickable to V4. I finally figured out how to import the Spike Prime color sensor properly. I made a render of some of the most complicated gearing in the robotic arm: This takes the output from 4 motors and drives the turntable and the 3 functions through the turntable. Using the differentials and exact gear ratios, you can decouple the functions going through the turntable. If the turntable rotates 90 degrees, the three functions going through the turntable also rotate 90 degrees so the two wrist joints and the grabber don't move when this turntable rotates.

I bought the “Black Premium Versatile Plastic”. That’s the most expensive one. I wanted a black part and chose that one without any real research on my part. The part seems quite solid. It has a matte finish. It worked right out of the box with trimming, sanding, or touch up required. oh, I did update the Studio model on Rebrickable. The V3 model that is up there now has slightly improved structure, fixed collisions, and now includes the 3D printed part.

This worked perfectly! Thank you so much. I updated my model to include this part and uploaded to Rebrickable. https://rebrickable.com/mocs/MOC-84097/glaysche/six-degree-of-freedom-robotic-arm/#details

I have finally spent the time to make a 3D Studio model of this. The original model was made completely in real bricks through a trial and error process. I made the .io file and parts list available for free on Rebrickable: https://rebrickable.com/mocs/MOC-84097/glaysche/six-degree-of-freedom-robotic-arm/#details Here's a render: This was my first experience with Studio. It definitely presented some challenges but it was better than I was imagining given all the negative comments I have read on various forums. The biggest challenge for me were missing parts or parts with errors in them. There seemed to be fixes for all of these but it appears it takes many months for those fixes to get into the main release. My model definitely has some issues. There are several collisions -- mostly gears not meshed properly but also a couple others I haven't figured out yet. The 3D printed part from @efferman is not in this model yet. The part for the color sensor I found didn't render properly so I left it off the model. I intend to fix these when I figure them out. I'm missing the wire clips that are only attached to wires. I also didn't model the wires. I probably won't fix that unless it gets much easier to do in Studio. I used blue 3L pins and axle pins in the Studio model even though I used black ones in the real model. I thought that would make it clearer. If anyone plays with the 3D model, I would love to hear constructive criticism on how I can do a better job. I learned a couple things with this exercise. First, the model has over 4000 parts, almost 200 of which are gears. It uses 6 of the new differentials which were critical to decouple the function going through the turntables from the motion of the turntables. About half the parts used are pins. I tried to make the construction as solid as I could. Part of that was using every pin hole available. It may be considered overkill but every time I made the structure more rigid and solid, it worked better so I think it was good. Almost every part is functional. There are less than 200 parts on the robot dedicated solely to decoration (mostly the tiles and half pins they are attached to). I tried to make it look reasonably good by changing colors of the structural members themselves. In the process of building the Studio model, I came up with several ideas to improve the structure. Some are already incorporated in and some will require some testing before putting into the model. I don't think I will make step by step instructions for this model unless there is strong enough demand. The parts to build this including 2 Spike Prime hubs and 8 motors are quite expensive so I don't imagine many people will want to build this. I hope I'm wrong. I would love it if people took up the challenge.

Thank you very much! That would be amazing.

Is it possible to generate files for this part that can be imported into Stud.io? I built my 6 degree of freedom robotic arm using this part and I am now building a Studio version of it so I can share the design.

Yeah, I normally try to avoid 3D printed parts but I think there is a really compelling case here. The first reason is that it is a much better representation of the original. How the original produced the mechanical calculations is probably more interesting than the calculations themselves. The second reason is that you can’t simulate the original mechanism completely with pure lego. The slotted gears are interesting to see them work. There seemed to be other parts of the mechanism that I suspect would also be hard or impossible with pure lego. This second thing is what made your more advanced prototype you showed in the video so interesting to me.

This is very, very cool. Thank you for posting here. I had no idea we had decoded and have such an understanding of the original device. The last I read about it was a long time ago and it was still considered a mystery. I have now spent way too long reading about this. In the video you showed a more advanced antikythera mechanism. Are you planning to make instructions and Shapeways parts available for that as well?

Here's a simple example of the code blocks for a toggle switch: This tells the motor to hold at 0 until someone moves it 90 degrees. It will then hold the position at 85 degrees. Similar logic to go back to 0. This has the effect of allowing two distinct positions for the motor. You can compare the position of the motor with 45 to decide which position it is in. This could easily be used on the Zetros to control the diff lock.

I think you could configure a motor to act as a toggle switch. Basically hold position until it is moved a certain amount (say 60 degrees) and then move it to the new position and hold it there. With that, you could have a physical switch for diff locks on or off. I haven’t tried this yet but I’m sure I will when I get the Zetros. There are also force sensors available via Spike Prime you can use as buttons. I don’t think the PoweredUp app knows how to deal with those yet, however. It’s funny you should mention it is expensive. I thought the opposite. I have a lot of motors and hubs laying around from the various sets I’ve purchased. I don’t tend to leave them assembled so I have lots of parts for MOCs and experiments like this. It’s a great use for otherwise unused parts.