Video Wall

Xutos’ concert had several projection screens at the background so I want to have at least one small display in the background, above the drum player own stage.

Outdoors concerts sometimes have a videowall or a projection screen at each side of the stage so also want that.

First attempt of a videowall was with a NodeMCU (Arduino-like) and a small  ST7735S based 128×160 display:

It looks great for using as the right/left side displays but there’s not enough power for videos, justs static images (but the NodeMCU has enough internal memory to store a few images so some kind of presentation is possible).

The wiring is SPI so I could use just one NodeMCU to control several displays in parallel (using same Chip Select pin for all) or individually (NodeMCU has a few I/O pins).  I intend to return to this idea later on.

For a “few” more Euros I got a better display, a 2.4″ 320×240 PiTFT for the Raspberry Pi. It’s just a bit larger so it can still used as side displays.

I first tried it with a Raspberry Pi 2, installation is pretty forward:

Unfortunately the RPi is too big and to hide it with LEGO I needed a frame much bigger than the PiTFT. So I opted for a Raspberry Pi Zero W instead:

So the LEGO frame is now smaller and much lighter:

So I just need to repeat the process to have a pair of side displays for my Rock Concert stage.

For the drum player display I think this display is too small so perhaps I’ll try a 3.5″ PiTFT. I could also use a small Android tablet but then I will have problems controlling it – I don’t want to continuously stream video to the displays, I was thinking on using some kind of sensors so the public (real people) could control what to display on it, eventually also control a webcam to show different angles of the concert.

But that’s for another day.

Wireless charger for MINDSTORMS EV3

A few months ago I was discussing with Juan about his ideas for a charging station for mobile robots. He was already creating several prototypes but I remember suggesting a wireless circuit, an idea that kept bumping inside my mind until a few weeks ago when I found a very cheap (less than €2,5) Qi receiver at bangood:

Qi receivers for mobile phones supply only 5V through the USB plug but we can use a boost circuit to raise the voltage. This circuit advertises an output current of 1A, if true (we never know, do we?) doubling the voltage to 10 Volt would reduce the output current to 500 mA with an ideal boost circuit. There are no ideal circuits but at least 400 mA is expected, not great but enough to charge a LEGO robot so lets try…

The remain parts are simple:

Any breakout board is fine as long as it exposes the GND and 5V pins, I got one at a local store for less than €2

There are other models, even cheaper, but I also got this one from a local store and it works good: 2 input pins, 2 output pins and an adjustment potentiometer, that’s it!

– a power plug compatible with LEGO EV3 battery

I cannot suggest a proper plug because I’m not 100% sure of the size… I think it is a 1.7 mm jack like this from Amazon:

I simply cut a plug from a cheap wall charger I had around (not the LEGO one! :D)  so I didn’t even had to solder wires

– a couple of wires, preferably red and black

That’s it!

Assembling is very easy so I’m not even goig to draw a circuit:

  1. solder 2 wires to the microUSB breakout board +5V volt (or VBUS) and GND pins
  2. solder the other end of those 2 wires to the input pins of the boost circuit (GND to IN- and +5V/VBUS to IN+)
  3. solder other 2 wires to the output pins of the boost circuit (OUT+ and OUT-)
  4. solder the other end of thos 2 wires to the jack (OUT- to the outter metal part, OUT+ to the inner part)

Here a picture with all soldered:

Then you need a voltmeter to adjust the output voltage. Put the Qi receiver over a Qi emitter and assure it’s coupled (most of them give some kind of visual indication of the coupling state like a blue LED) and trim the potentiometer with a small screwdriver until you got 10.0 Volt (you can use higher or lower values but higher will mean less current available so more time to charge and lower might not be enough for the internal circuits of the EV3 battery to work properly).

In this video you can see the green LED of the EV3 battery blinking – that’s part because the Qi receiver wasn’t properly aligned with the Qi emitter,  part because both Qi components are low-end quality (the emitter is from a friend, it was a gift at an HP event) and finally part because the Qi emitter was being powered up from my laptop – after switching to a 3.1A wall adapter USB charger I got better performance, even a few millimeters of spacing.

Stage Lighting

So the stage size is settled, it will use 3×3 LEGO standard baseplates (32×32 studs each).

Now time to think about the lighting.

For the first version I wanted to be able to control each of the spotlights individually. To minimize wiring I decided to use a 1-wire bus (2 wires for power, 1 wire for data) and I found a 1-wire USB controller that worked very well with linux and (of course) with ev3dev.

I was very happy with the Ev3 1-wire network but not so happy with the way I wired it with my LEGO trusses. I tried to create a pluggable system that would allow me to easily extend the number of spots but never got a decent and discreet solution so I use only fixed size wires, soldered in a daisy-chain. It worked but “locked” my spotlights to the trusses permanently.

So for this new version I decided to use just one or two control channels and use common LEGO Power Function lights (well, at least for this year).

As for the trusses that support the spotlights I also decided to try non-Technic parts – I liked my previous design with only Technic parts but it was already noticeable that the spotlights were too heavy and the 32L axles were bending.

Since LEGO has a truss brick already, lets try it:

So 1 one channel is easy: each Power Functions Light assures 2 spotlights and I just need to daisy chain several of them. We can even make the lights blink with just a electro-mechanic controller like In this video:

Unfortunately it makes to0 much noise so I will have to use something purely electric.

Xutos’ 25th Anniversary concert was indoor (at ‘Pavilhão Atlântico’, currently named ‘Altisse Arena’) and the lights were suspended from the ceilling so there were no vertical trusses in front of the band. If I can’t  keep it realistic I can try a mix: keep the X-shaped stage used in that concert but use a dome truss similar to this model they used in several outdoor concerts in the last couple of years:

So I tried an arch with the LEGO trusses to see it stands hold:

Then I added the Power Functions lights but since the weight was too much I had to redesign it a bit, ending with a much larger arc:

It holds ‘per se’ but is not stable at all, tending to fall to the front or to the back. So a second or even a third arc was needed and also had to raise it a bit because when wife saw it she said the lights were too low and that would prevent people to see the stage. And since wife is always right…

This has been holding tight in our leaving room for the last 7 days (and we have 2 kids!) so I’ll might just reinforce the middle connections of the trusses that have Power Functions cable extensions.

This is already a 2-channel system so I can control half of the spotlights at any time. So it’s a proper time to finally add a MINDSTORMS EV3 to the project… and since I already got six small battery-powered active speakers I can also play a music:


The stage

The main part of the Rock Concert is the stage so it will set the scale of all the diorama.

In the first version, the stage had a few internal gears that allow my kids to move the minifigures of 4 of the 5 elements of the band with a stick at the backstage. I had the idea to animate all 5 but never got a solid way to move the arms of the drum player (“Kalu”) so I left him static and put “Zé Pedro” walking along the stage with his guitar (he is/was a bit wild at stage, once he even broke a leg jumping to a speaker) and the remain three just turning around on their places (“Tim” the bass player and main vocals, “João Cabeleira” the human statue that plays guitar and “Gui” with his saxophone).

A second version had 4 LEGO mini-motors instead of sticks and a LEGO MINDSTORMS EV3 controlling the motors… through a USB 8-relay board! It was one of my first experiments with ev3dev and I had no idea how to control those old motors so I used the relay board I had bought for the Raspberry Pi… it was also the first time I invoked bash scripts from python:

This new version will probably have a similar setup (without relays) but for now I’m just concerned with settling the dimensions.

As I had big bunch of red tiles from a LEGO 10 kg box I decided to make the X-shaped stage:

Yeah, ugly but that’s a start. A few more pieces from Bricklink and things started to get better:

So a few more bricks from Bricklink and lots of funny-blue tiles from the same 10 kg box and the main part of the stage is done:

I’ll increase size a bit more to left/right but the ‘X’ will stay this size.

Height is also good because it will allow me to put small speakers inside and probably a few other things if/when I decide what special effects I will have on stage.

Work in progress: LEGO Rock Concert

Got myself an anti-stress project: rebuild my LEGO Xutos&Pontapés rock concert.

About 30 years ago my cousin took me with him for a rock concert in the town next by: Xutos&Pontapés. I was a kid with almost no interest in music but Xutos had recently released their third LP and finally got some country-wide success, everybody were singing their singles so… why not?

I got hooked! Xutos were a great live band and after all those years they still are.

So my late teenage years as also my first adult years were strongly influenced by their energy. At college I made the first related site (pew! ugly!) and when I got married my tie had their ‘X’ stamped.

A remarkable concert I went to was the one that ended their 25th anniversary tour. The stage had a fabulous ‘X’ shape:

Xutos&Pontapés – XXV year tour

This photo was taken more or less from the same spot where I was.

So this is going to be my crazy project for the next months: a LEGO rock concert that pays tribute to the greatest portuguese rock band ever.

Of course, this isn’t a static LEGO project. Will try to use some of the gadgets and tricks I’ve been using those last 3 years since I joined PLUG.

From the first version I will certainly keep the animated minifigures and the stage lights (but the lights will be pure LEGO now… as much as I like the 1-wire lights concept, soldering and wiring was a mess and this is a purely for-fun project, no need for more stress).

So MINDSTORMS EV3 running ev3dev is expected, probably with one of the new Power Functions 2 devices. And of course at least one Raspberry Pi and a NodeMCU or other Arduino-like board. And webcams, displays, sound speakers, perhaps some special effects… we’ll see.

Site certificate

Been lazy lately.

Things got weird with oldest kid and all family is under stress. Perhaps even burnout. So programming and other things that require focus are getting delayed, mostly on purpose.

But today I finally took the chance to add a free certificate to my web server. So this blog is now encrypted. Let’s hope I didn’t brake anything…

Decoding RCX IR command protocol

After showing LIRC controlling different LEGO IR protocol devices, Alexandre Campos suggested that a real LEGO Universal IR Controller should also control the MINDSTORMS RCX and Scout pBricks.

Very well, let’s do it.

I have a 9738 RCX Remote Control Unit:

This remote can control the 3 motors of the RCX (or the two motors and the LED of the Scout) and also start/stop programs stored in the pBrick memory. Unlike the other LEGO IR remotes, it’s not possible to choose a channel so the remote will control all pBricks in range.

I captured all motor control signals with Arduino rawRecv and replicated them with rawSend and it worked very well so I thought it will be easy to convert the signal to LIRC format like I did with Spybotics.


Turns out the RCX signals are huge. For instance the “A Forward” key generate a 100 byte signal:

#define RAW_DATA_LEN 100
uint16_t rawData[RAW_DATA_LEN]={
 390, 442, 386, 442, 386, 442, 386, 442, 
 386, 858, 382, 4170, 3710, 850, 802, 438, 
 806, 438, 346, 1722, 386, 446, 382, 858, 
 386, 442, 806, 850, 3706, 850, 346, 4206, 
 1626, 450, 2042, 442, 346, 1310, 346, 1722, 
 350, 482, 806, 434, 382, 862, 346, 894, 
 350, 478, 350, 478, 386, 446, 766, 474, 
 1190, 466, 382, 446, 382, 446, 382, 446, 
 350, 530, 298, 894, 346, 4210, 3670, 882, 
 774, 474, 766, 474, 346, 1726, 346, 530, 
 298, 894, 346, 518, 734, 886, 3762, 794, 
 318, 4238, 1642, 430, 2062, 422, 318, 1338, 
 294, 1774, 350, 1000};

Assuming a 417 µs bit lenght (2400 bps) I just copy these 100 values into a spreadsheet like LibreOffice Calc and  use ROUND(x/417) to get the toggling sequence:


The whole sequence represents a 221 bit long signal, that’s really long!

Since transmission starts with a start bit ‘0’ those first 14 numbers represent this sequence:


Does it makes any sense?

The RCX messages always start with a “55 FF 00” header, followed by a payload where each data byte is followed by it’s complement. At the end, a checksum is sent, also followed by it’s complement.

For a “A Fwd” command (“D2 00 08”) the payload is:

D2 2D 00 FF 08 F7

(where 2D, FF and F7 are the complements of D2 00 08, i.e. FF-D2 = 2D, FF-00=FF and FF-08=F7)

And the checksum is “DA 25”

D2 + 00 + 08 = DA
FF - DA = 25

So the complete message is 11 byte long:

55 FF 00 D2 2D 00 FF 08 F7 DA 25

Each one of these bytes is sent in reverse order, with a start bit, an odd parity bit and a stop bit so with 3 extra bits for each we get a 121 bit long signal, much less than the 221 bits I captured.

So what should I had captured?

Let’s see just the header in binary notation:

55 FF 00 = 01010101 11111111 00000000

reverting each byte:

10101010 11111111 00000000

adding odd parity bit:

101010101 111111111 000000001

adding a start and a stop bit:

01010101011 01111111111 00000000011

Now if we re-group everything:

0 1 0 1 0 1 0 1 0 11 0 1111111111 000000000 11

Now we count how many times each bit occurs before “toggling”:

1 1 1 1 1 1 1 1 2 1 10 9 2

Thats quite familiar… let’s see those first 14 values of my captured sequence again:


Well, just one extra ‘1’ at the beginning, can’t be just a coincidence.

Analyzing the whole toggling sequence, I see two occurrences of the header. So I probably captured two repeated “A Fwd” signals, but the Arduino rawRecv sketch stopped capturing at the 100th sample.

So let’s ignore everything from the second header to the end:

#define RAW_DATA_LEN 58
uint16_t rawData[RAW_DATA_LEN]={
 390, 442, 386, 442, 386, 442, 386, 442, 
 386, 858, 382, 4170, 3710, 850, 802, 438, 
 806, 438, 346, 1722, 386, 446, 382, 858, 
 386, 442, 806, 850, 3706, 850, 346, 4206, 
 1626, 450, 2042, 442, 346, 1310, 346, 1722, 
 350, 482, 806, 434, 382, 862, 346, 894, 
 350, 478, 350, 478, 386, 446, 766, 474, 
 1190, 466};

Using this signal with rawSend works so my guess was correct.

I made a python script that calculates the complete signal and also it’s LIRC value from the toggling sequence and it gives a 121 bit long string as expected:


Unfortunately using “0xaadff80325eb4c01bff082ef4b6a91” on a LIRC configuration file doesn’t work and my syslog shows:

lircd-0.9.4d[8847]: Info: Using remote: LEGO_RCX.
lircd-0.9.4d[8847]: Error: error in configfile line 10:
lircd-0.9.4d[8847]: Error: "0xaadff80325eb4c01bff082ef4b6a91": must be a valid (__u64) number
lircd-0.9.4d[8847]: Error: reading of file '/usr/local/etc/lirc/lircd.conf.d/LEGO_RCX.conf' failed

Must be an unsigned 64 bit long value?! Dang!

Searched a lot trying to find a way to use longer values in the LIRC file but all I could find was a workaround, mostly used by air conditioner owners: instead of using hexadecimal codes LIRC also accepts “raw_codes”

The first number indicates the duration of the first pulse in microseconds. The second number indicates the duration of the space which follows it. Pulse and space durations alternate for as long as is necessary. The last duration should represent a pulse.

Turns out this is more or less the same as the rawSend output I got before, except for the last value that it is a gap. So I removed the last value (‘466’) and defined a one-size-fits-all gap (‘2138’, the larger last value I got from all rawRecv captures).

begin remote
   name LEGO_RCX
   flags RAW_CODES
   frequency 38000
   gap 2138

   begin raw_codes

      name A_FWD

          390 442 386 442 386 442 386 442 
          386 858 382 4170 3710 850 802 438 
          806 438 346 1722 386 446 382 858 
          386 442 806 850 3706 850 346 4206 
          1626 450 2042 442 346 1310 346 1722 
          350 482 806 434 382 862 346 894 
          350 478 350 478 386 446 766 474 

And it works!

So now I have three LIRC configuration files:

With these 3 files and ANY supported LIRC transmitter I can now control every single IR device ever made by LEGO – even MINDSTORMS EV3 with IR distance sensor since it understands Power Functions IR signals.

Decoding old LEGO infrared protocol

This started most as a curious thing and now I realize it went crazy. But I learned a lot so perhaps other may benefit of it.

On my quest to control all LEGO MINDSTORMS models ever sold from a single “gateway” I started a few weeks ago my work with the Spybotics:

This little fellow has 2 motors and a touch sensor inside, can talk IR and also reacts to VLL. So it’s kind of a Micro Scout on steroids. And, with a little of good will, we can call it the ancestor of the LEGO BOOST, among the Cybermaster.

The Spybotics was programmed with a serial-to-optical cable. I still don’t have one so I tried to program it with a RCX USB IR Tower using NQC (there are some reports that the USB version of the IR Tower can “speak” at 38 and 76 kHz and the later is needed for the Spybotics). But no success yet.

The Spybotics also reacts to a IR Remote Control:

The protocol allows 3 different channels and it’s also possible to send commands to all 3 channels simultaneouslys so I decided to get more information about the protocol.

Turns out that this IR protocol was implemented by LEGO a few years before the Power Functions IR protocol but it never gained momentum and it was quickly abandoned. But a few interesting systems used this protocol:

The last one surprised me as I have two of these, after a very lucky finding 4 years ago on our summer holidays – our kids love them and we use them at our LUG events with great success among young visitors:

So I picked up my Manas, Spybotics and DUPLO commands… and yes, they are interchangeable!

It would be great if I could control my kids DUPLO Dozer from the computer, side-by-side with the Spybotics and the Manas.

So let’s find more details about this pre-Power Functions IR protocol.

The best I could find were references to a Rob Doucette document where he gathered info collected from several Lugnet posts (mainly contributed by John Barnes). One of those references is Philo’s site, where he shows how he used is RCX to control the RC Nitro Flash).

Unfortunatelly the original document location no longer exists:


but thanks to the Internet Archive Wayback Machine I managed to retrieve the document from a May 2008 snapshot.

The low level details are resumed in 2 sentences:

“The transmitters transmit short messages of two bytes encoded as 8 bit + odd parity. The transmissions use 76kHz modulated IR at a baud rate of 4800, 25% duty cycle.”

Each message contains 4 nibbles (4-bit digits):

Channel + Orange + Yellow + Checkdigit

Channel can be 4/5/6/7 (meaning all, #1, #2 or #3)

Orange and Yellow can be 0/7/8/F (no button, forward button, reverse button and stop or immediate off)

And Checkdigit = 10h – (Channel + Orange + Yellow) AND Fh

The space between each message is different according to the channel used (simillar to PF IR protocol):

Ch. 1 – 19.6 Hz
Ch. 2 – 14.8 Hz
Ch. 3 – 11.6 Hz
‘All’ – 19.6 Hz

The document also has a NQC program demonstrating how to use the RCX to control 3 Manas units (each on its channel)

I tried to replicate the commands with an Arduino and an IR LED but all my attempts failed miserably. After getting tired of it, I decided to analyze the signal, but since I don’t own a scope or a logic analyzer I had to use the only tools I have: an Arduino, a Raspberry Pi, a laptop and Google.

So to “sniff” the IR signal I used an Arduino Uno with a TSOP4856 as an IR decoder and a IR LED for testing my signals back. The setup is pretty much the same as this Adafruit lession:

The TSOP signal is connected to Arduino pin 2 and the IR LEDs are connected to Arduino pin 3 (that’s right, two LED’s in serial, no resistors… might use a transistor later).

The TSOP module has a filter better suited for 56 kHz carrier – not quite the 76 kHz I wanted but it was the higher carrier I could found – just for the record, an IR photodiode and a 1M resistor also works, both devices can detect the 76 kHz signal at short distances.

So I installed cyborg5’s IRLib2 Arduino library on my laptop and tried the rawRecv sketch available on the examples folder. Pressing the Yellow Forward button on the Manas command I got this:

Ready to receive IR signals
Do a cut-and-paste of the following lines into the 
designated location in rawSend.ino

#define RAW_DATA_LEN 12
uint16_t rawData[RAW_DATA_LEN]={
 1082, 206, 154, 238, 178, 590, 594, 238, 
 178, 658, 178, 1000};

So I passed those last lines into the rawSend sketch and changed the carrier frequency to 76:


… and each time I sent a key to the Arduino serial terminal my Manas yellow motor rotated forward.


I tried to find some meaning to those values but I was totally lost. Tried to use another skech (Analyze) but the results made no sense… I captured all keys combinations and they worked but I wanted to know the meaning.

So I used the same TSOP4856 on my Raspberry Pi and installed LIRC, so I can use “mode2” command to record a signal. Recent stretch-based versions of Raspbian have some quirks but following this method I had success.

$ mode2 -d /dev/lirc0
space 16777215
pulse 1085
space 179
pulse 239
space 174
pulse 239
space 534
pulse 651
space 175
pulse 190
space 644
pulse 190
space 46681
pulse 1090
space 156
pulse 260
space 183
pulse 235
space 526
pulse 658
space 173
pulse 241
space 576
pulse 259
space 1518
pulse 69
space 45041
pulse 1090
space 156
pulse 211
space 225
pulse 190
space 579
pulse 607
space 226
pulse 189
space 643
pulse 195
space 46689
pulse 1090
space 176
pulse 242
space 175
pulse 241
space 495
pulse 676
space 175
pulse 242
space 572
pulse 274
space 46589
pulse 1041
space 210
pulse 204
space 210
pulse 207
space 578
pulse 607
space 207
pulse 224
space 610
pulse 220
space 46642
pulse 1041
space 214
pulse 200
space 227
pulse 190
space 566
pulse 604
space 230
pulse 187
space 661
pulse 172
space 46683
pulse 1038
space 211
pulse 206
space 210
pulse 206
space 561
pulse 207
space 417
pulse 207
space 210
pulse 1042
space 46445
pulse 1038
space 209
pulse 217
space 201
pulse 204
space 584
pulse 173
space 434
pulse 190
space 227
pulse 1027
space 921
pulse 159
space 45364
pulse 1038
space 213
pulse 201
space 230
pulse 187
space 578
pulse 190
space 437
pulse 187
space 230
pulse 1021

I installed IrScrutinizer on my laptop, imported the above result (“Import signal”) and got a nice signal in the “Scrutinize signal” pane:

A zoom of the first block from the left shows a clear sign:

But how does this relates to “50 74” that, according to the protocol definition, is the 2-byte representation for “Yellow Forward on Channel #1”?

Well, after a few head aches, I got it.

First, I realize that I made a stupid beginner error: like many serial codes, the bits are sent in revere order (least significant bit of each byte first, more significant bit last).

Then I understood the rawRecv format: each value represents the time duration of a continuous mark or space before it “toggles”.

I also got confused with the bits representation (that 25% duty cycle still confuses me). But if I assume a single bit duration to be near 208 µs (for a 4800 bit per second rate), ‘zero’ as the start bit and ‘one’ as the stop bit  I can translate this:

uint16_t rawData[12]={
 1082, 206, 154, 238, 178, 590, 594, 238, 
 178, 658, 178, 1000};

5 zeros (1082) = start bit + 0000
1 one (206)
1 zero (154)
1 one (238)
1 zero (178)
3 ones (590) = odd parity bit + stop bit + pause
3 zeros (594) = start bit + 00
1 one (238)
1 zero (178)
3 ones (658)
1 zero (178)
2 or more ones (1000) that must include odd parity bit, stop bit and pause

The last value (1000 µs) is an arbitrary value used by the sketch author to end the signal.



start=0 | 0000 1010 | odd=1 | stop=1


start=0 | 0010 1110 | odd=1 | stop=1

The odd parity bits are correct, that’s a good start.

Reverting the order of the data bits, we have:

0101 = 5 | 0000 = 0 | 0111 = 7 | 0100 = 4  => 5074


So the precision isn’t pretty (I got bits with just 154 µs and others with 238 µs when they all should be 208 µs long) but that doesn’t really matter – I can now recreate all signals with theory-perfect values and test if it works.

So I wrote a python script to generate all combinations for all channels and also a RemoteControl sketch –  just an extended ‘rawSend’ sketch that sends different signals according to the keys received from the serial port.

This is a sample of the output of my python script:

Command: Ch1_OrangeNop_YellowFwd
 Msg: 00000101011100010111011
 Size: 12
 Signal: 1040, 208, 208, 208, 208, 624, 624, 208, 208, 624, 208, 624

And it works!

The serial port can be used directly so we can use our keyboard (in linux, just use screen to connect to the Arduino serial port, i.e. ‘screen /dev/ttyACM0′) or we can write our own programs to automate it.

And yes, we can connect the Arduino to our MINDSTORMS EV3 and use ev3dev to control our old LEGO IR devices 🙂

Even better: we can use the same approach to generate a LIRC configuration file so we don’t even need an Arduino – any IR transmitter supported by LIRC will work… including my FTDI IR emitter. That means we can use the same emitter to control all LEGO IR devices,  Power Functions and pre-Power Functions:

(Power Functions LIRC configuration file based on excellent work of Conor Cary and Diomidis Spinellis)

I created a github project for this, you can get the LIRC configuration (or just the generator there).


LEGO Interface A – the Python Turtle

In 1987 LEGO released several Activity Cards with examples to be used with the Interface A. One particular Activity Card, the 9700b8, proposed a robotic turtle that could be used to draw lines like the Logo Turtle (in fact, Interface A was used used with a LEGO variant of the Logo language) or even a lne follower!

I don’t have the exactly parts to build a 9700b8 robotic turtle but  have enough TECHNIC bricks already available at that time so created my own robotic turtle… the Python Turtle 🙂

I think Dr. Seymour Papert would like this turtle.

Source available here.