Skookumjim

A small project has been to try to use the Spike Prime acceleration data and Newton’s Laws of Motion to calculate distance moved by a vehicle. The upshot of working through this has been: . that the Lego documentation is woefully lacking. ..it is not at all clear what the units are although given the the z acceleration is of the order of 989 I imagine that to be gravity in cm/s/s. . even though the hub is at rest it reports small accelerations on x and y. . applying the code ... integrating acceleration over time... the results are inconsistent even at standstill.... more so under movement. It is possible that there is a coding error but unlikely (famous last words!) So.... any ideas gratefully received! Thanks

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.

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?

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

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.

I have read all sorts of complaints about Robot Inventor and by inference Spike Prime. Some are valid (eg poor documentation)... some are less so (eg colour scheme). One thing seems clear is that the hardware is well thought out (yes there are issues with cables). Now in robotics three elements stand out as being super important: being able to use multiple motors (motors are basic building blocks), multiple sensors plus having the computational brain (and software) to hold it all together. Unfortunately Lego only provide 6 ports on each hub and have 2 versions of software both of which initially appear limiting. Whereas wireless Inter-hub communication could be very helpful enabling models to use multiple hubs and access both software platforms this is not something that Lego have explicitly provided at the moment. There is however a very simple and seemingly reliable work around available immediately that could help in cases where high speed comms and high data volumes are less important. This is to use optical communication. The idea which I have tested is to use the distance sensor to signal light flashes to the colour sensor. The number of flashes in a fixed time frame thus delivers information from Transmitter to Receiver. As expected using downloaded compiled code speeds the process up though not massively. This process could be 2 way, could enable daisy chaining of hubs and could be expanded to longer instructions (again high speed not being a limitation). On the downside the process sacrifices at least one port on each of a pair of hubs (if the requirement is for one way communication between the pair). The sensors need to be carefully and firmly positioned for reliability although there is no other requirement for any connection between them. In this context a model containing the one hub could “launch” the second. As SP and RI software can be easily swapped on any hub the user has the choice of using SP/SP or SP/RI or RI/RI platforms. Unfortunately size limitations prevent me from uploading images of the set up and demo code at the moment.

Having passed over EV3 as being long in the tooth I was eager to buy Robot Inventor oblivious of the existence of Spike Prime. As of now I am really regretting not knowing about Spike Prime which appears to more of a toolkit that a toybox and by now has some useful 3rd party contributions. Having reported various frustrating manual and software issues to Lego I now find that the word block descriptions appear to have been taken down (they are still there on Spike Prime). I am minded to load the Spike Prime Firmware onto my RI microprocessor and forget Robot Inventor altogether. Does anyone know whether this is feasible? I guess that it will be as I cant imagine Lego having different chipsets in these boxes.

I am slowly learning more about the two apps. The documenttion is dreadful. It beggars belief that they dont both have the same underlying functionality (or if they do it is hidden!). It is indeed very frustrating that one has functions that the other doesnt. As of yet I havent tried to switch to Spike Prime as the remote control available in Robot Inventor has more play potential. (I found a non interactive line drawing robot and similarly a robot arm didnt keep my interest once they were working. Sadly Robot Inventor lacks several of the features of Spike Prime such as graphs and "more sensors". What I did discover is that a bit of Spike Prime Scratch code (not python) can be exported to Robot Inventor successfully simply by changing the file name from .llsp to .lms Whether this trick will unlock a bit of hidden code on the Inventor remains to be seen ..if it does you can run the force sensor. I have also exported balancing robot python code from Spike Prime having to make a very small number of changes to make it run on Inventor.... this approach may also help you. It is also possible that the Scratch code might magically appear if a force sensor is attached to the Inventor brick? As of yet I have not tried to switch firmware.

... also the RI project page puts user projects at the bottom of the page below all the built in code listings...having to scroll down every time is very annoying.

Thanks from memory.... I found the printed manual next to useless... the modes of operation of the microprocessor were totally opaque .. and there is at least one that I cant fathom. There were omissions in the python write up (such as conversions from Scratch). There is no way to save code as there is in Spike Prime. It is not possible to print out word block descriptions or python help pages. I still cant figure out exactly how to create and use bespoke Scratch blocks. I had my ipad freeze up a few times using Scratch. Moving some code from my desktop to the ipad caused the loss of all previous models that I had written. i have had some weird coding issues with Scratch... a perfectly good change to a lengthy bit of code can cause the physical model to behave strangely.. dismantle bits of code and reassemble as was and suddenly it works (that probably is also true of Spike Prime). In contrast I am impressed by the geometry/connectivity of the hardware although I have found the medium motors underpowered for a simple robot arm.. they seem to be built for speed not torque and have been difficult to position slowly and accurately under load. The third comment relates to people who have built interesting models and published the code such as a balancing robot or the Swirlbot.