Glaysche

This was published on Rebrickable a few days ago: https://rebrickable.com/mocs/MOC-256856/3DKiwi/solar-system-orrery/#details

You may be able to use my robotic arm as a model although what you would do would be simpler. If you look at the Rebrickable page, you can download the Python code called Robot_mk5_software_v1.zip. There are seven Python files in there for the 7 different hubs used in the robotic arm and remote control. Before you start, I would suggest looking at the getting started section for PyBricks: https://pybricks.com/learn/ If you look at remote_1.py, here it is in its entirety: # Remote 1: A1 & A2 from pybricks.hubs import EssentialHub from pybricks.pupdevices import Motor from pybricks.parameters import Port from pybricks.tools import wait hub = EssentialHub(broadcast_channel=3) A1 = Motor(Port.A) A1.reset_angle() A2 = Motor(Port.B) A2.reset_angle() while True: a1_angle = A1.angle() a2_angle = A2.angle() hub.ble.broadcast((a1_angle, a2_angle)) # print((a1_angle, a2_angle)) wait(50) The important things to note: "broadcast_channel=3" passed into the EssentialHub. This says which channel you are broadcasting on over Bluetooth. This needs to match the receiver side. 'A1' and 'A2' stand for axis 1 and axis 2. These are the motors I am using as angle sensors. The hub.ble.broadcast(...) actually sends out the positions of the motors. I am doing that in a tight loop with a 50ms pause In my code, the hubs on the robot are much more complicated because of the calibration routines. Look at 'shoulder_v5.py'. There are a couple of interesting bits: async def process_remote(self) -> None: while True: received = self.hub.ble.observe(3) if received is not None: a1, a2 = received self.a1.track_target(a1) self.a2.track_target(a2) await wait(50) This reads data from Blutooth with the self.hub.ble.observe(3) -- note it is the same channel we are sending over above. You can see the code for 'track_target()' elsewhere in the file. It calls the 'track_target()' method on the motor after doing some math. This tells the motor to go to that position as fast as it can. Another important bit is that you need to tell the hub to listen to channel 3 in this example: self.hub = PrimeHub(broadcast_channel=1, observe_channels=[2, 3, 7]) In this example, it is listening on channels 2, 3, and 7. In my robotic arm, the hubs talk to each other quite a bit.

I guess our categorization or terminology is different, then. The firmware that really matters is the base level firmware that allows you to install new firmware anytime you want. Lego did a good job there, too. This is what allows PyBricks to work. In fact, Lego also built a way to update firmware over Bluetooth that you can see when you use the Control+ app with a brand new hub. With this as a basis, Lego could have improved the firmware over time, filling in functionality they didn't ship with at first. That effectively turns the firmware into software. This updatable firmware is code that needs to be maintained and improved by a software team as all the software improves. If Lego had wanted to offer an Xbox-controller-without-smart-device mode, they could have shipped it at any time with a simple upgrade to the software running on the hub.

My thesis in my first message was that PoweredUp hardware is really good and TLG completely failed at writing software. The hardware team chose to use BLE for communication which is a great decision expressly because it is an industry standard. This made it possible to talk to other devices using that same industry standard. They could have tried to build some proprietary radio communication system, for example, which would have been a disaster. The Lego hardware team that designed PoweredUp, in my opinion, really thought things through and built something general purpose, standards based, and extensible. The software team failed to deliver.

Just a correction here. When used with PyBricks where the hubs talk directly to each other with no smart device involved, there is basically zero lag. If you try to use it with the PoweredUp app through the smart device, there is quite a bit of lag. The hardware supports this use case quite well. In my original message, I forgot to mention using an xbox controller. The hardware obviously supports that as well.

This is divisive statement in this forum: the PoweredUp ecosystem is really good hardware. The motors, sensors, hubs, lights, and remote can all plug together and communicate over Bluetooth. The motors typically have pretty good rotation sensors and have enough mechanical power to be useful. The hubs have a very useful IMU. The sensors work as advertised. You can build amazing things with the PoweredUp hardware, including remote controls. That's right, you can build your own remote control, shaped any way you want that has proportional inputs and talks directly to the vehicle or robot or whatever you want. (See my 6 axis remote for a kind of ridiculous example). They built general purpose hardware that can be composed together to build whatever you want. From a hardware point of view, it is the true spirit of Lego. However, TLG completely and utterly failed on the software side. They built multiple incompatible and incomplete software systems that could not unlock even 10% of the hardware's potential. Their software requires the smart device. The hardware does not. PyBricks built a software ecosystem that does work across all the PoweredUp hardware. It's not perfect by any stretch of the imagination but it is an existence proof that it is possible. You can tie all this great hardware together and build some really neat contraptions including pretty great remote control cars with physical remotes. It's all there. It's all possible. I think the most likely scenario is that TLG has decided good software is too hard to build and it would rather just cancel it all and abandon the hardware they have built without it ever seeing its potential. If I had to guess, they've probably missed almost every deadline on the software schedule and had to continually cut scope until what they were shipping was basically useless to anyone building a MOC with PoweredUp. They probably had high ambitions for PoweredUp but simply failed to deliver. It turns out, writing good software with a high quality UX is actually really hard to do well. All of this is super disappointing. I exited my dark age about when PoweredUp was first shipped and I thought it was amazing with so much potential. Now, after seeing failure after failure with software, I have very little hope left that TLG will produce any suitable electronics going forward.

Here is version five of the robotic arm and remote control: It is a bit more compact, lighter weight, and uses fewer parts than version 4. Because of the lower weight and more specifically the lower moment of inertia of the moveable portion of the arm, I was able to use a faster gearing to get things to move faster. Axis 2 and 3 are the two highest stress axes and those both move faster now. By moving 2 motors out into the wrist, I no longer need to pass three functions through a turntable and no longer need the 3d printed part. I now have only one axis going through the turntable. The gear trains became significantly shorter and simpler. You can compare with previous pictures I posted in this thread of the previous versions. It's dense and compact but really simple now. The LBG 16t gear in the middle is connected directly to the large linear motor that's in the elbow. This drives axis 5. The two small angular motors drive axis 6 and the gripper. The only part I really don't like about this configuration is that there is no nice place to put the 2 port Spike Essential hub. I attached it to the side of the wrist because that's the only place that doesn't interfere with the movement. It looks a bit ugly there, though. It's quite unfortunate that Lego is discontinuing the Spike Essential and Spike Prime education lines of products (and the Mindstorms line earlier) with no suitable substitute. The hardware is really great. Lego is not a software company and they failed so spectacularly on the software side that I think they decided to kill the whole concept of programable bricks. PyBricks, while not perfect, is much more capable than any software Lego has ever produced. PyBricks unleashed the potential of this hardware just in time for Lego to cancel it. The parts needed to build this robotic arm are quite expensive so I don't expect many, if any other people build this. I published it in the hopes that people will be inspired to build their own MOCs using some of these ideas. It has been a lot of fun for me over the years. Basically every time a new structural piece was released over the last few years, I would try to figure out if it would help me make a better robotic arm. There were several parts that inspired almost complete redesigns. That's super fun. So I plan to put this project down until the next revolutionary part comes out or inspiration comes in some other form.

I have now finished and published the 5th revision of the robotic arm on Rebrickable (as always free of charge): https://rebrickable.com/mocs/MOC-253928/glaysche/6-axis-robotic-arm-mk5/#details This is the first version I've designed that is 100% pure Lego with no 3d printed parts. Not only that, it ended up being more compact, lighter, and faster than all previous versions. There is a good amount of detail on the Rebrickable page. I will post more details later in this thread.

I have a version working that does not use the 3d printed part. This built off the prototype I showed earlier but I was able to make it more compact and work pretty well. It ended up lighter and more compact than my latest version that uses the 3d printed part. Because of this, I was able to change the gearing to make many axes faster. Here is a quick video showing it work: This is a bit uglier than my previous one. The colors are just the parts I have available (still can't get black 9L flipflop beams on PaB) and I didn't swap out the blue 3L pins for the black ones. There really is no good place to put the Essential hub. I put it on the side as close to the turntable as I could to minimize the total torque required to move the arm around. You can't put it on the top or bottom of the wrist because it interferes with the movement of axis 5. I won't be able to make a Studio model and publish this to Rebrickable for a few weeks at least but I do intend to put up a refined version of this as a new 5th revision robot arm when I get time.

This is very cool. This reminds me of the old school mechanical calculators: https://en.wikipedia.org/wiki/Mechanical_calculator Needless to say, if this were released as a Lego Ideas set, it would be day-one purchase for me.

Yeah, with the gearing down, the positioning seems quite accurate. This model has gear ratios in the range of 7 to 25 for the different axes. With those ratios, you can position within a fraction of a degree theoretically. Some of them have low enough backlash to actually see that in practice.

I actually do use the IMU of the hub on the humerus in the initial calibration. I broadcast the tilt to the hub in the shoulder and use that signal to quickly point the arm straight up. I later use the touch sensor on the base to get an exact calibration of that axis. Using the IMU like this has been helpful. My goal with the calibration routine is to be able to start in any position and get to a known state. Oh, the 6 axis remote control uses the absolute position on the angular motors to come up instantly calibrated. I agree. Doing robotics has been much more fun than the shelf queens. I do usually end up building many technic sets but always take them back apart to use the parts to build something more interesting. I don't have nearly enough shelves to actually keep them assembled, anyway!

I put together a prototype of the wrist and elbow that doesn’t use the 3d printed part. In total, I think it is a bit shorter and lighter weight than the version using the 3d printed part. The gear trains have less backlash. The wrist is only 2L longer than the previous one. I think I have an idea that will shrink it by 1L. The elbow is 3L shorter and has a better geometry. I ran out of time tonight so I haven’t updated the code and tried it out yet. i was able to fit the small angular motors somewhat well. It’s unfortunate they stick out like that. There is no obvious place to attach the Spike Essential hub. I put it in a temporary spot I can use for testing. It needs to be on the wrist somewhere to the left of the middle turntable in this picture.

@thomas92, continuing the conversation from the older thread. I was just thinking that it might be possible to split up the motors and hubs differently to eliminate the 3d printed part. If I put a 6 port hub on the humerus, it can connect to the motors for axes 3 (2 motors), 4, 5, and the sensor for axis 4. That’s a total of 5 ports. Then I could put 2 motors and a Spike Essential hub on the wrist. Those two motors would control axis 6 and the gripper. I might be able to use the small angular motor for those—they need lower mechanical power than the other axes. Even the Spike Essential hub is pretty bulky but maybe this could be made to work. Instead of transferring 3 functions through the turntable, only one function would go through, eliminating the need for the 3d printed part. Could be a good solution.

I have not seriously looked into this. The reason is a bit ironic. My day job is a software developer and if I'm going to write software, I'd rather do it at work. For my hobby, the mechanical part of it is so much more fun. I built the 6 axis remote control so I could easily exercise all the mechanics without spending too much time writing Python. If I ever want to incorporate the robotic arm into something bigger (like a GBC module perhaps?), I would probably sit down and actually write that code. Oh, I just realized you replied to my old thread. I much more recently posted a new thread with my newest version of the robotic arm: Any conversation should probably move to that thread.