LEGO Python Alternatives: SPIKE2 vs SPIKE3 vs Pybricks

When it comes to running Python on LEGO SPIKE or MINDSTORMS hubs, you’ve got options: SPIKE 3, SPIKE2, MINDSTORMS, and Pybricks. Although all these options give you access to Python on your hub, they differ significantly. It’s important to weigh the pros and cons of each before diving into your next project.

SPIKE 3: The Incomplete LEGO Python Contender

SPIKE 3 is a relatively new option but comes with its set of drawbacks. While it attempts to offer Python support, the API remains incomplete. Furthermore, SPIKE 3 is quite picky on which sensors it allows to be connected. In our SerialTalk and PUPRemote special features of the sensor ports to get our LMS-ESP32 board connected. In SPIKE3 these features are no longer available. It is LEGO’s default option for yellow SPIKE hubs, but we find it very limiting.

While the SPIKE2 firmware could also be flashed on the blue MINDSTORMS hub, SPIKE3 only supports the yellow SPIKE hub.

Download the latest SPIKE software and connect the hub to flash this firmware.

SPIKE2 and MINDSTORMS Python API: Reliable Twins

Both SPIKE2 and MINDSTORMS function similarly at the Python level. They feature fully developed and well-documented APIs that stick to all LEGO standards. The difference lies in their desktop apps. SPIKE2 and MINDSTORMS both get a thumbs-up for their robust and standard-compliant features, and we wholeheartedly support them.

The LEGO SPIKE2 app is hard to get, but you can still download the LEGO MINDSTORMS app. It happily flashes the firmware on both the yellow and the teal hubs. You can’t downgrade from SPIKE 3 through LEGO software, however. If you want that, you need to first install Pybricks and then install SPIKE2/MINDSTORMS.

Pybricks: The Clear Winner for LEGO Python

When it comes to stability, speed, memory management, and API beauty, Pybricks takes the cake. It’s the most reliable firmware option to run Python on your LEGO hubs. However, Pybricks comes with one drawback: it doesn’t support UART.

LPF2 protocol: the alternative to UART for Pybricks

We’ve found a way around the UART limit by using the official LEGO communication protocol for sending data. We wrote a handy library to use that protocol: PUPRemote. It allows for efficient communication and offers the flexibility and compatibility needed for a wide range of projects.

The LPF2 (Lego Power Functions version 2) protocol (in Pybricks it is called Lego Powered Up UART Protocol, PUP for short) is a lightweight protocol that allows each Lego sensor to advertise its capabilities to the hub. A generic LPF2 sensor supports multiple modes of operation and defines for each mode the type and size of data that is exchanged with the hub. For each mode, the units (e.g. cm, inch, etc.) and the allowed range is defined.  For example, the SPIKE Ultrasonic Distance sensor has as its first mode, a single 16-bit value with the SI unit CM and a range of maximum 250cm.
For getting our LMS-ESP32 board to work with PyBricks, we basically emulate an LPF2 sensor using the PUPRemote library and use raw LPF2 commands to read and write the different modes.

Warning: LEGO does not properly implement its own protocol on all firmwares

We encountered some peculiarities regarding the compatibility with the LPF2 protocol across the different Python versions on the Lego hubs.

SPIKE3 does not support raw LPF2 commands. Only original Lego sensors are recognized (where all modes are checked). This limits the use of LPF2 significantly.

SPIKE2 can cope with proprietary sensor specifications. It only supports writing data to the sensor when the type is set to Bytes. Because the data specification for a mode is the same for two directions, this only allows for Bytes. Although according to the LPF2 specifications arrays of up to 32 Bytes are supported, the SPIKE2/MINDSTORMS only reads the first 8 bytes. The remaining bytes are somehow discarded. Reading 8 Words (total of 16 Bytes) works fine without this limitation, but then, no data can be written to the sensor (because it only accepts Bytes). So, two-way communication with an LPF2 sensor is limited to 8 Bytes.

PyBricks seems to be very flexible regarding the LPF2 communication. In the Beta release of ByPricks, the switching between modes is not correctly implemented. In the Beta release, you only can write data to a mode, when you first read at least once from that mode. This limitation is not present in the normal release of Pybricks, so be aware of that.  Another issue arises when sending more than 16 Bytes to the hub while reading data from the sensor. Although the data packets are seen to be correctly present on the serial lines of the sensor, somehow the data sent gets corrupted. Therefore, we had to limit the data exchange to 16 bytes.

BluePad32 LPF2 support

Where the PUPremote library is a Python-based library, we also added LPF2 support to the BluePad32 project. Because of the limitations we discussed earlier in this post, we only support PyBricks with the BluePad32 LPF2 firmware. When you want to use the BluePad32 with the original SPIKE2 or MINDSTORMS Python, we advise you to use the UartRemote version of BluePad32). These different versions of BluePad32 can be flashed on the LMS-ESP32 board from our firmware web page. SPIKE3 is not supported by BluePad32.

Conclusion

While SPIKE 3, SPIKE2, and MINDSTORMS each offer unique features, Pybricks stands out as the best option for running Python on LEGO SPIKE or MINDSTORMS hubs. It not only offers an excellent API but also solves its only major drawback—lack of UART support—via PUPRemote.

Of course, a big advantage of PyBricks is that it also runs on the Technic hub and many other Lego hubs. Now, the LMS-ESP32 board can also be used with the (much more affordable options) other hubs using the PUPRemote library.

We give you a little insight in how we support the communications with our LMS-ESP32 board for the different Python versions available for the Lego hubs.

Happy building, and don’t forget to choose the firmware that suits your project needs the best!