Skookumjim

Inevitably Lego are much more motivated to sell a model that will never be broken up… driven by commercial incentives…..so they can sell another …. and another …meantime they are very happy to pick the brains of their customers!

It is hard to comprehend why Lego created 2 different apps rather than a single all encompassing one.

Thanks I know very little about python… how do I make this work with Thonny IDE python? thx

I have had two hubs happily communicating using the recent Lego message protocol … and am thinking of creating such messages from raspberry pi’s build hat. Thus far python for the buildhat appears not to offer such an option. Am wondering whether I am missing something?

Thank you... as for pictures I wasnt having any success loading them

For those who might be interested .....I have for a while had the idea of building a remote controlled vehicle complete with working gearbox. The result is a fairly compact rear wheel drive Roadster. https://www.dropbox.com/s/zxlk0l52hstrrj8/IMG_9898.jpg?dl=0 The model uses colour sensors as always on headlights https://www.dropbox.com/s/wz9kaikcuttvh5q/IMG_9899.JPG?dl=0 The gear box concept was thoroughly tested before the main construction https://www.dropbox.com/s/2y5qix7787nt1wx/IMG_9876.JPG?dl=0 https://www.dropbox.com/s/eaf4h0e5d0yf86j/IMG_9878.mov?dl=0 The vehicle was rear wheel drive only to leave room for direct steering https://www.dropbox.com/s/cfvsmzb1isvg9zg/IMG_9900.jpg?dl=0 Rear differential is absent diff lock in the interests of space https://www.dropbox.com/s/4gpfiwdcpr8w4dw/FullSizeRender.JPG?dl=0 The final model is powered by a large spike prime motor with medium motors for gear shift and steering, Control is by streamed drag and drop coding via bluetooth. Gear shift is sequential up and down. The vehicle is initialised by a steering calibration... and if necessary a reset of the gear sequence. Once initialised it will always start moving in first gear. Gear shift and steering are slider controlled.

Sadly not..... and you are not alone in wanting to use Scratch.( I am avoiding python at the mo... not sure I have the patience to learn yet another programming language.. especially one where I dont have access to decent documentation )

a couple of quick images of the robot arm ... https://www.dropbox.com/s/dcbc2n7crg0fk8q/Photo on 15-02-2021 at 20.29.jpg?dl=0 https://www.dropbox.com/s/kjjhqybhrnw5a6x/Photo on 15-02-2021 at 20.20 %232.jpg?dl=0

So... inspired by the opening photographs in this thread I have built such a large robot arm using Spike Prime motors... will post a photo once I have a decent one to share... meantime a few learnings for those who might be interested (given that this is the most complicated technic model I have attempted to build from scratch I might be teaching granny to suck eggs!) 1 Spike Prime motors need to be geared down to move weighty loads... the highest gearing I have is 15:1. Much is 5:1 2 Every precaution needs to be taken to eliminate gear slip... the higher the load, the greater the risk. In extreme cases that may lead to opposing wheels driving a turntable. Lots of trial and error here! 3 The through holes on the large motors are very helpful in building up gearing 4 The hub is best placed off a moving arm ... avoids undue torque loading 5 A single hub is barely enough.... 6 DOF plus some sort of action at the business end requires more than 6 ports... 6 short cable lengths are limiting 7 some head bending gearing calcs are needed to figure out are what speeds different motors are to run simultaneously to eliminate gearing interference between different limbs of the robot... for example without this a “wrist” rotation will cause the “hand” to move. 8 I still havent found a truly satisfactory solution for the business end... at present it just fires rubber bullets... and probably wont until it is possible to increase the number of ports and lengthen at least 1 cable 9 Much easier to play with code when cable connected... No dropping out of bluetooth that way. I havent delved into python but for the moment am happy enough with tge drag and drop software.

Sadly the documentation is so awful that would be hard to discern.

Not at all a dumb question! Lego segmented the market into Educational and Home... Spike Prime and Robot Inventor. Each has its own firmware ..and software.....both firmwares run on exactly the same physical hub. Each offers facilities that the other doesn't. For example Spike Prime enables graph plotting while Robot Inventor enables remote control. Robot Inventor does not give access to acceleration data, Spike Prime does. I bought 2 Robot Inventor sets and changed the firmware in one hub to Spike Prime.... hence being able to access acceleration data. (buying a discounted second RI was far more cost effective than buying a Spike Prime hub!)

Well done, ...an inspirational project. My very first attempts with Robot Inventor was to make a very simple robot arm... https://www.dropbox.com/s/cv5cr4liu08afcr/IMG_9828.mov?dl=0 I have to say that the ungeared results were not very encouraging in that the motors proved not to up to be up to the job... both in the context of holding position under load or moving precisely... a much larger geared solution seems more promising.

I have for a while wondered about using robotic components to automate/control the Lego Rough Terrain Crane ... this has now happened using the Mindstorms Robot Inventor hub with 5 medium stepper motors and a distance sensor ....while keeping the original power functions large motor to avoid further destruction of the original model. One motor switches turntable rotation, another switches the drive from turntable to jib while a third switches power to the original motor. Two further motors switch the six way gear selector for hook and jib. the distance sensor is used to limit turntable rotation to accommodate the relatively short cable lengths. The resulting construction works well.... the crane can both remote controlled and programmed. https://www.dropbox.com/sh/82vqyjvd2zledp0/AAA736uPmlzo9hL-sIWdGS8la?dl=0

Thats how I got consistent results when static... unfortunately it only works when there is no acceleration (other than gravity).

After making various minor refinements to the code I have at last reproduced consistent results when the robot is at rest however it seems impossible to take this any further as the robot does not return angular measurements to a sufficient degree of accuracy.... eg roll angles are reported only as integers. This means that it is impossible to accurately remove the influence of gravity.