Minimized Powered Up hub

[Jan Johansen]

My son and I, are building a short wheelbase train, so we needed to get creative when it comes to space. We removed the battery tray and "converted" the hub to use lithium polymer and lithium ion batteries. We uploaded the bottom case to Thingiverse if anyone is interested. The hub does take up 1 brick and 1 plate in height now. The biggest thing is we can now separate the battery and the hub.

The hub/motors run so much better on lithium batteries. Much less sluggish in inclines and so on. The train we are building is not the one in the pictures, it just for testing 😄  

Thing: https://www.thingiverse.com/thing:6262436

Edited October 12, 2023 by Jan Johansen

[Toastie]

This is a very nice solution!

Did you see this pinned topic?

I am not sure about the different power sources you guys are using, but getting rid of that battery compartment really cuts the size of the hub down to the brain.

As said: very nice!!! And welcome to EB - this is a wonderful place to be, share, learn!

Best wishes,
Thorsten

 

[Jan Johansen]

20 minutes ago, Toastie said:

Did you see this pinned topic?

 

No, i did'nt see it until now. We are on the same track it looks like. I really like the design of that tram 😍
 

20 minutes ago, Toastie said:

I am not sure about the different power sources you guys are using, but getting rid of that battery compartment really cuts the size of the hub down to the brain.

We are using lithuim battery without any battery protection from our rc cars/drones/planes. With 2S 3000mAh lithuim ion's we get around 2-3 times the amount of running time as well. We have also designed a battery cutoff with a TL431 and a n-channel MOSFET(for the tech heads here 😄) that cut off the battery at around 6.2V to save our batteries. Will post a schematic here when its all done. 
 

20 minutes ago, Toastie said:

As said: very nice!!! And welcome to EB - this is a wonderful place to be, share, learn!

Thank you, Thorsten!

Edited October 12, 2023 by Jan Johansen

[Toastie]

8 minutes ago, Jan Johansen said:

Will post a schematic here when its all done. 

And add that to the pinned topic as well. This is a major improvement, as far as I am concerned!

Best,
Thorsten

[Jan Johansen]

18 minutes ago, Toastie said:

And add that to the pinned topic as well. This is a major improvement, as far as I am concerned!

Best,
Thorsten

No problem, will post a schematic and board there when its done.

Edited October 12, 2023 by Jan Johansen

[UltraViolet]

  I was planning on creating this exact solution myself for my own purposes, but I didn't have the time to get very far with it up until now.  You've just saved me a ton of trouble by doing the design work for me!  I was originally going to machine down the stock casing and glue in a plate as a functional new bottom, but having your 3D model available to print will save me from permanently altering my stock casings.

  In my plot, I was going to build my own battery source, most likely based on 18650 lithium cell(s) and a voltage boost board, but the key thing is that once you've separated the original battery housing, now your battery can be just about anything.  Capacity and dimensions can be customized to the needs of a particular build.  Flat pouch lithium might suit the situation better than a cylindrical cell, or vice versa.  You can also use just about any battery chemistry.  I have a pile of JST RCY 2-pin connectors at my disposal which I was planning to try using for my application.  I was also considering mounting the connector inside the shallow base of the hub rather than having the wire pigtail out of it, but a pigtail might turn out to be more practical in terms of build flexibility.  Alternatively I could have multiple openings in the base so the connector could be presented on any of the four faces, sorta like the approach Circuit Cubes took with the multiple connectors (three) on their cubit motors.

  I noticed you didn't include anti-studs on the bottom of your base design.  This would be the only addition I'd like to see, if possible.  I know tolerances for clutch can be a royal pain though.  I have two of the Keybrick One battery modules, and the anti-stud clutch on them is barely useable (otherwise, they are a great product).  My skills in 3D CAD are non-existent, so unfortunately I can't add the anti-studs myself.  I will nonetheless look into getting one of these parts printed through a professional service like Shapeways, as my 3D printer at home is too crude to produce good enough results for this.

  

[Jan Johansen]

3 hours ago, UltraViolet said:

  I was planning on creating this exact solution myself for my own purposes, but I didn't have the time to get very far with it up until now.  You've just saved me a ton of trouble by doing the design work for me!  I was originally going to machine down the stock casing and glue in a plate as a functional new bottom, but having your 3D model available to print will save me from permanently altering my stock casings.

  In my plot, I was going to build my own battery source, most likely based on 18650 lithium cell(s) and a voltage boost board, but the key thing is that once you've separated the original battery housing, now your battery can be just about anything.  Capacity and dimensions can be customized to the needs of a particular build.  Flat pouch lithium might suit the situation better than a cylindrical cell, or vice versa.  You can also use just about any battery chemistry.  I have a pile of JST RCY 2-pin connectors at my disposal which I was planning to try using for my application.  I was also considering mounting the connector inside the shallow base of the hub rather than having the wire pigtail out of it, but a pigtail might turn out to be more practical in terms of build flexibility.  Alternatively I could have multiple openings in the base so the connector could be presented on any of the four faces, sorta like the approach Circuit Cubes took with the multiple connectors (three) on their cubit motors.

  I noticed you didn't include anti-studs on the bottom of your base design.  This would be the only addition I'd like to see, if possible.  I know tolerances for clutch can be a royal pain though.  I have two of the Keybrick One battery modules, and the anti-stud clutch on them is barely useable (otherwise, they are a great product).  My skills in 3D CAD are non-existent, so unfortunately I can't add the anti-studs myself.  I will nonetheless look into getting one of these parts printed through a professional service like Shapeways, as my 3D printer at home is too crude to produce good enough results for this.

  

Yeah, exactly what we will do. Flat pouch lipo's in the trains with space constraints and 18650's in the one's with enough space. 

I was thinking the same about the connector in the base, but there is no way to get a connector in the housing without making it 1 plate higher. The same with the studs. The male studs from a mating brick will hit the screws, as seen in the image with section analysis below. So i'm just using flat tiles under and sandwich the hub between bricks. 
If you want to i can make a revision with studs that are one plate higher? 

There might be a revision with some connectors in the near future, as we want to get some UART/I2C out in a custom built firmware for it. We are using Pybricks for now, but there is no way to get UART working on the Powered up hub, even in the beta version.  

 

[UltraViolet]

  I had gone back and forth in my mind about increasing the thickness.  There is just enough space in between the motor ports to fit a 2-pin JST RCY connector if the stock upper housing is 'nibbled' into a bit and the connector is aligned vertically.  I'm undecided about it.  As to the screw heads, I realize the height issue interfering, and while some of the anti-studs would be compromised even on a version one plate thicker, even the stock battery base has two points on it like that, and LEGO even omitted most of the middle row of tubes (that was a terrible design choice on their part which has been really annoying, as it has caused me build compromises, and the clutch is not always ideal depending on placement).  Overall, it would be great to have the option of a version of the base with complete anti-studs.

  Anything you are planning with firmware and other modifications is greatly appreciated.  The prior PyBricks code project that had been posted on this forum, which allowed standalone use of the hub with a remote (no mobile device) and acceleration/deceleration profiles useful for trains, showed a lot of promise, but somewhat stagnated.  This would have been super-useful for me, but just as I finally got it working, PyBricks changed the frequency of the motor drive pulse rate much higher, which seems to have crippled the torque of the motors and made them unusably prone to stalling or not even starting in my trials.  If you could solve this problem, I'd be ever grateful.  While I can interpret the program code enough to understand how a finished program is working, and tinker with it a bit, I'm not versed enough in this stuff to be recompiling the source libraries.

  Your efforts are appreciated no matter what you choose to come up with.

[Jan Johansen]

23 hours ago, UltraViolet said:

  I had gone back and forth in my mind about increasing the thickness.  There is just enough space in between the motor ports to fit a 2-pin JST RCY connector if the stock upper housing is 'nibbled' into a bit and the connector is aligned vertically.  I'm undecided about it.  As to the screw heads, I realize the height issue interfering, and while some of the anti-studs would be compromised even on a version one plate thicker, even the stock battery base has two points on it like that, and LEGO even omitted most of the middle row of tubes (that was a terrible design choice on their part which has been really annoying, as it has caused me build compromises, and the clutch is not always ideal depending on placement).  Overall, it would be great to have the option of a version of the base with complete anti-studs.

I uploaded two versions with bottom holes now. My 3d printer is pretty dialed in, so tolerances should be okay. There is 1 version with 5.10mm holes which makes for a tight fit and there is 1 version with 5.20mm which is a bit more loose-fitting. More like original Lego, but they wear out over time. So 5.10mm does hold up better. 

 

23 hours ago, UltraViolet said:

  Anything you are planning with firmware and other modifications is greatly appreciated.  The prior PyBricks code project that had been posted on this forum, which allowed standalone use of the hub with a remote (no mobile device) and acceleration/deceleration profiles useful for trains, showed a lot of promise, but somewhat stagnated.  This would have been super-useful for me, but just as I finally got it working, PyBricks changed the frequency of the motor drive pulse rate much higher, which seems to have crippled the torque of the motors and made them unusably prone to stalling or not even starting in my trials.  If you could solve this problem, I'd be ever grateful.  While I can interpret the program code enough to understand how a finished program is working, and tinker with it a bit, I'm not versed enough in this stuff to be recompiling the source libraries. Your efforts are appreciated no matter what you choose to come up with.

Yeah, i have tried that code as well and could not get it to work. I have just written a basic python script so we can use the control as well. Nothing fancy, but a bit better feel that the original Lego feel when it come's to speed control. 20 steps forward/backward and you dont have to release the buttons to control the speed. We are on the way to drop Pybrics and just program the STM32F030 microcontroller with C instead.

 

 

 

Edited October 14, 2023 by Jan Johansen

[Toastie]

4 hours ago, UltraViolet said:

PyBricks changed the frequency of the motor drive pulse rate much higher, which seems to have crippled the torque of the motors and made them unusably prone to stalling or not even starting in my trials.

I take it that you are using PUp train motors for your engines, is that right?

I am asking, because PUp motors having the "tacho" function (it is just a - fancy - rotation sensor; there are some LEGO motors having this feature, even with rather low footprint), allow you to use the "speed" rather than "power" command. I know, has been discussed over and over again, but I can tell from experience that the moment you use that feature, the whole world changes. Particularly when using the acc/dec profiles of your choice: the trains closely and swiftly adjust the necessary motor power to maintain or arrive at the speed you wish or the profile asks for. This is bolted into the LEGO wireless PUp protocol and runs flawlessly when using e.g. an ESP32 device as control unit (the remote/s and hub/s connect to).

And for sure, if you have to redesign from PUp train to PUp M/L motor, it means the hell of a redesign - and may be unacceptable. But again: It is worth a try; after redesign LEGO trains almost behave as true trains do. No speed loss in curves, no issues with load. Provided of course that your motor does not max out at 100% power; at this point, no speed regulation is possible. But that again is a design issue.

Best regards,
Thorsten 

47 minutes ago, Jan Johansen said:

We are on the way to drop Pybrics and just program the STM32F030 microcontroller with C instead.

Which is totally cool!!!

However, the original firmware running on the hubs is really nicely designed. TLG's smart device apps are - sorry to say - not my cup of tea and are buggy and shaky, but when you use an ESP32 as your central device and use (e.g.) Legoino libraries within the Arduino IDE, you can code in C++ from dusk to dawn. And man, you can do crazy stuff.

Best,
Thorsten 

Edited October 13, 2023 by Toastie

[Jan Johansen]

1 hour ago, Toastie said:

Which is totally cool!!!

However, the original firmware running on the hubs is really nicely designed. TLG's smart device apps are - sorry to say - not my cup of tea and are buggy and shaky, but when you use an ESP32 as your central device and use (e.g.) Legoino libraries within the Arduino IDE, you can code in C++ from dusk to dawn. And man, you can do crazy stuff.

Yeah, there is nothing wrong with the original firmware. We just want some more options for our builds. We are not using the Lego Android software and don't want to use any other device than the remote to control them, but we want network connectivity between our trains, some more IO/UART/I2C onboard and a main ESP32 that is controlling the track switches, lights and so on. Pybricks would have been just fine, but without any IO/UART it's too limited for now.  

[Toastie]

1 hour ago, Jan Johansen said:

but without any IO/UART

This sounds very exciting!

I don't get the "without any IO/UART" bit (I am old, a boomer, grown up in 8bit world) - IO is related to the hub ports, right? Physically, there are two (City hub) or four (Technic hub, or six, duh - with the Spike whatever hub). So I/O is there and nicely supported by the LEGO firmware (forget any outside Android crap). So, what do you mean by UART? In the olden days, this would be an Universal Asynchronous Receiver Transmitter, which is BLE by default, the wireless access to the hub. As far as I understand, LEGO hubs do have IO/UART heavily supported by their firmware factory installed. 

What am I missing?

Best,
Thorsten 

[Jan Johansen]

8 minutes ago, Toastie said:

This sounds very exciting!

I don't get the "without any IO/UART" bit (I am old, a boomer, grown up in 8bit world) - IO is related to the hub ports, right? Physically, there are two (City hub) or four (Technic hub, or six, duh - with the Spike whatever hub). So I/O is there and nicely supported by the LEGO firmware (forget any outside Android crap). So, what do you mean by UART? In the olden days, this would be an Universal Asynchronous Receiver Transmitter, which is BLE by default, the wireless access to the hub. As far as I understand, LEGO hubs do have IO/UART heavily supported by their firmware factory installed. 

What am I missing?

It's not really just the hub ports, but what we do with them. There are a lot of IO's on the STM32F030, and they are mappable. So if I want to talk to another device over UART/USART, I2C, SPI or so, I can easily do that in C. The STM32F030 is capable of 6 USART connections. So we are talking about sensors and other small things we want to do. Like blinking leds, color and distance sensor, RFID and stuff like that. 

[Toastie]

14 minutes ago, Jan Johansen said:

There are a lot of IO's on the STM32F030, and they are mappable.

Ah, I see. That means invasive changes to the hub/s right? Adding ports = hardware additions. Now I get it. Well, this is going to be very interesting.

All the best,
Thorsten

[Jan Johansen]

14 minutes ago, Toastie said:

Ah, I see. That means invasive changes to the hub/s right? Adding ports = hardware additions. Now I get it. Well, this is going to be very interesting.

All the best,
Thorsten

Not really invasive changes, just re-using some of the port pins on the hubs for other purposes. No physical alterations...

[Jan Johansen]

19 hours ago, UltraViolet said:

There is just enough space in between the motor ports to fit a 2-pin JST RCY connector if the stock upper housing is 'nibbled' into a bit and the connector is aligned vertically. 

I made a new revision with a JST RCY male plug under the HUB ports. It's not 100% there yet as the connector is a bit too close to the PCB, but I managed to remove(0,5mm) off some plastic standoffs/throughole clip on the HUB connectors just above the JST connector to get the lid to close. Will try to fix this issue later, as I still got 1 HUB to modify. 

Edited October 14, 2023 by Jan Johansen