A LEGO relay

I needed a LEGO mechanism that could turn ON or OFF an electrical circuit using an independent power source. This power source could be a regular LEGO battery but could also be a different type. So a LEGO relay.

I remember seeing somewhere a few LEGO mechanisms with the same purpose, like moving the slider of a Power Functions battery box or rotating an axle inside of a Power Function switch… but could not find them.

So this is my own implementation.

I used a Power Functions switch. We can mechanical control the switch with a Technic axle inserted in two different ways – over the top or through it:

I decided to insert the axle through it. As the idea is using a MINDSTORMS to control the relay, I could have connected the axle directly to a motor and control the time or the angle. But I started with a Power Functions motor connected to a Power Functions battery and since the motor is too strong and fast I used a clutch gear to protect the switch when extreme position is reached.

The switch has 3 working positions where the neutral (middle) is the OFF position and both left and right extremes are ON both with opposite polarities. As I just wanted ON and OFF I needed to limit the motion to just half.

Perhaps not most the efficient mechanism or beautiful design but this works:

The cam gears were the first piece I found with the proper size – when the switch is off the cam gears touch the Technic grey brick so if the motor keeps rotating the clutch gear will slip and protect the switch axle.

The relay works with power Functions cables so regular LEGO batteries and devices can be used. But I used a 2.1 mm female jack with a pair of crocodile cables to connect an old LEGO electric plate to a 12V/1.5A wall power supply and a custom Power Functions cable with male headers soldered to it to connect to a kanthal wire.

I prefer to use kanthal wire instead of nichrome wire for several reasons: it has a higher electrical resistence and also a higher melting temperature… and it is also widely available now that vaping is a trend (I don’t smoke but could not find a single nichrome supplier here in Portugal but have several online vaping stores selling dozens of variants of kanthal wires). Metal strings used with guitars also work and are easy to find but electrical resistance is too low.

So I used a 20 cm piece of kanthal wire to make a coil with perhaps a dozen turns and test it several times:

Then connected the coil endpoints to 2 crimp pins and soldered it to the custom Power Functions wire (it’s not easy to solder kanthal wire so crimping is a better option)

And now I have a MINDSTORMS controlled ignitor. Great for hobby rockets or party candles:

Remember: don’t try to do this if you don’t fully understand it. Also keep in mind that although party sparkles aren’t dangerous per se igniting one near flammable products can start a fire. Always take safety measures.

Edit:

And the bash script for the sparkle ignitor’s video (ev3dev):

#!/usr/bin/env bash

MTRTIME=1000   # 1 second
MTRSPEEDON=-650
MTRSPEEDOFF=650
PAUSE=1 # MTRTIME / 1000

IGNITION=10 # ignition time in seconds

function Init {
    echo "Start"
    echo $MTRTIME > /sys/class/tacho-motor/motor0/time_sp
}

function SwitchON {
    echo $MTRSPEEDON > /sys/class/tacho-motor/motor0/speed_sp
    echo run-timed > /sys/class/tacho-motor/motor0/command
    sleep $PAUSE
}

function SwitchOFF {
    echo $MTRSPEEDOFF > /sys/class/tacho-motor/motor0/speed_sp
    echo run-timed > /sys/class/tacho-motor/motor0/command
    sleep $PAUSE
}

function SpeakCountdown {
    espeak -a 200 -g 12 -p 70 "Ten"
    espeak -a 200 -g 12 -p 70 "Nine"
    espeak -a 200 -g 12 -p 70 "Eight"
    espeak -a 200 -g 12 -p 70 "Seven"
    espeak -a 200 -g 12 -p 70 "Six"
    espeak -a 200 -g 12 -p 70 "Five"
    espeak -a 200 -g 12 -p 70 "Four"
    espeak -a 200 -g 12 -p 70 "Three"
    espeak -a 200 -g 12 -p 70 "Two"
    espeak -a 200 -g 12 -p 70 "One"
    espeak -a 200 -g 12 -p 70 "Zero"
}

function SpeakHB {
    espeak -a 200 -g 12 -p 70  "Happy birthday!"
}

function finish {
    SwitchOFF
    echo reset > /sys/class/tacho-motor/motor0/command
    echo "End"
}

trap finish EXIT

Init
SwitchOFF
SpeakCountdown
SwitchON
sleep $IGNITION
SpeakHB
SwitchOFF

 

Kittenbot Geek Servo

Found another RC motor that can be used with LEGO: the Kittenbot Geek Servo

It works very well with my Pololu Maestro board although I just can get a little less than 180º rotation instead of 270º as the title of the product at Bangood states (to be honestly I didn’t even noticed that title until now as I expect all RC servos to rotate 180º or, when modified, to rotate continuously).

I have a fixation with small LEGO motors and this one motor is smaller than the 4DBrix motor:

4DBrix Servo and Kittenbot Geek Servo motors

Both top studs and bottom reverse-studs connect to LEGO bricks but only bottom reverse-studs give a strong LEGO-like connection. The Technic-like holes work very well and the axle is also Technic compatible.

For monorail or train rail switches I still prefer the 4DBrix Servo because I can attach it directly to the 4DBrix monorail swicthes (of course) and to my Technic-based rail switches as drop-in replacements of Power Functions M or L motors (or even MINDSTORMS EV3 smaller servo). But for my LEGO Rock Concert cameras this little fellow might do a better job. It’s still bigger than the good old LEGO 9V micro-motor but it is already geared and Technic attachable so in the end it might even save more space and give bette results.

Each kit comes with 4 motors so the price is also quite good.

Sniffing the LEGO WeDo 2.0 Motion Sensor

Now that I have a working cable to intercept Powered Up signals I no longer need to cut a sensor cable to hijack it.

So let’s start with a simple sensor: the 45304 LEGO WeDo 2.0 Motion Sensor

Procedure:

  1. connect the male plug of the Powered Up Interception Cable to LEGO BOOST Move Hub (port C)
  2. connect a WeDo 2.0 Motion Sensor to the “female” plug of the Interception Cable
  3. connect the Bus Pirate to the “interception” 6-pin header
  4. connect the Bus Pirate to a USB port and set it up as a Transparent UART Bridge (115200 bps, 8N1, floating inputs)
  5. run jpnevulator to read traffic comming from the Bus Pirate
  6. turn of the LEGO BOOST Move Hub
  7. connect to it with gatttool
  8. enable notifications (‘char-write-req 0x0f 0100’)
  9. enable the Motion Sensor on port C (‘char-write-req 0x0e 0A004101000100000001’) in mode ‘0’
  10. watch, watch, watch

So everytime the measured distance change I get a notification in gatttool and a 3-byte message in jpnevulator. And it is simple:

00 => C0 00 3F
01 => C0 01 3E
02 => C0 02 3D
03 => C0 03 3C
04 => C0 04 3B
05 => C0 05 3A
06 => C0 06 39
07 => C0 07 38
08 => C0 08 37
09 => C0 09 36
0A => C0 0A 35

A start byte (‘C0’) plus the payload  plus and end byte (‘3F’ i.e. the complement of ‘C0’ minus the payload).

Great! Not even an initialization sequence!

So disconnect the Interception Cable male plug and replace the Bus Pirate with the FTDI Beefy 3 adapter, set ‘/dev/ttyUSB3’ to 115200 and raw mode and test several bash commands.

Not totally clear yet but this works:

 

#!/usr/bin/env bash

# sync
for i in {1..50000}
do
    echo -e -n "\x00" > /dev/ttyUSB3
done

for i in {1..50000}
do
    echo -e -n "\x02\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00" > /dev/ttyUSB3
done

(that ‘echo’ command is just a line)

Now the usual voodoo explanation:

The first byte sent is like a read command. I got success with ’02’, ’04’, ‘0F’, ’27’ and ‘FF’ and 3 different behaviors.

The remaining 15 bytes (’00’) are like the inital synchronization commands… I don’t think they are valuable data and sending a ‘break’ to the TX line for enough time would do the same… but I just can’t find a way to send a break.

So the 3 different behaviors:

  • ’02’ gets a lot of 3-byte messages from the Motion Sensor. Probably one message for each ’02’, I suspect 50 messages per second but need to check that. After a few minutes, it stops sending data.
  • ‘FF’ gets much less messages, about 1 per second. And the message is now 5-bytes long: ‘7B C1’ or ‘7B C2’ followed by the 3-byte message above (like ‘C0 00 3F’). And after a few minutes the sensor also stops sending data. So ‘7B C1’ or ‘7B C2’ are warnings from the Sensor stating that it expects something more.
  • Finally ’04’, ‘0F’ and ’27’ (and probably other values) make the Sensor behave in Mode 0 (i.e. just send data when distance changes). But it also expires after a while (I think sooner than other two modes) and the sensor sends a few ‘7B C1’ warnings followed by a read).

Now the interesting part is that if I keep moving something in front of the sensor it doesn’t “expire”. So it is probably some power saving definition, it would be nice if we could disable it.

So perhaps I’ve found a way to make my own sensor: if I can emulate the AutoID of the WeDo 2.0 Motion Sensor (device type ’23h’) I just need to send it short 3-byte messages (just 11 different values but that would be a start).

Powered Up interception cable

Fancy name 🙂

Arrived from holidays and had two small packets in the mail box:

  • One from David Lechner with 2 Powered Up-compatible male plugs with cables already attached (and 4 great ev3dev stickers!)
  • Other from Mouser Electronics with a few 1.27 mm headers I ordered to try to replicate Philippe “Philo” Hurbain idea to a pseudo female plug

So I finally made my own Powered Up extension cable with a third connector to sniff the communicares between the hub and a sensor or an interactive motor:

Philo hack works but it’s really tough to execute. My soldering skills aren’t great (my hands shake _a_lot_) and my vision is getting worse. But at my third attempt I got a working connection, not 100% tight but stable enough for my purposes.

Too bad I get back to work this week… I hope that spying the WeDo 2.0 tilt and motion sensors I can find something more about the protocol used on Powered Up sensors.

The end is near

Holidays end today.

And finally got something repeatable with the motor.

The motor talks at 115200 bps, 8N1.

It expects an Init command. And it asks for it (or at least it complains of something). But it also requires some sort of warm up procedure that requires sending to the motor a lot of ’00’ for a while. It seems like a long break before start communication but for some reason it doesn’t work if I use pyserial break command.

Python code here.

Tried to use it in EV3 running ev3dev but no success. 115200 might be to much for the Ev3… or it’s just my bad programming skills.

And this is the FTDI Beefy 3 adapter that I’m using:

To recap the wiring:

  • FTDI GND (black wire) to pin 3
  • FTDI 3V3 (red wire) to pin 4
  • FTDI TX(white/grey wire) to pin 5
  • FTDI RX (green wire) to pin 6

And a sample of the output:

Speed   : 00 (h) =  0 (d)
Position: 00   00   00   00 = 0  degrees
CRC     : 27 (h) =  39 (d)

Speed   : 11 (h) =  17 (d)
Position: 09   00   00   00 = 9  degrees
CRC     : 3F (h) =  63 (d)

Speed   : 1D (h) =  29 (d)
Position: 13   00   00   00 = 19  degrees
CRC     : 29 (h) =  41 (d)

Timeout -> Resync
Speed   : 04 (h) =  4 (d)
Position: 9D   00   00   00 = 157  degrees
CRC     : BE (h) =  190 (d)

Speed   : 00 (h) =  0 (d)
Position: 9D   00   00   00 = 157  degrees
CRC     : BA (h) =  186 (d)

The script is still far from perfect – I was rotating the motor half a turn clockwise and it lost communication in the middle… but at least it reconnected fast enough to preserve position.

Geek kit for holidays

Next holidays don’t forget:

  • USB soldering iron (great acquisition!) and decent thin solder wire
  • small base for the soldering iron, with flexible arms if possible
  • high current USB hub and a high current USB battery pack
  • jumper wires (F-F, M-F, M-M, several colors)
  • alligator wires (several colors)
  • a few female headers compatible with the jumper wires (6 pin were great for EV3 and Powered Up hacking)
  • multimeter
  • Bus Pirate and BitScope (but a decent Logic Analyzer with linux support would be great)
  • Ubertooth (but a more recent BLE sniffer with linux support would be great)
  • a decent small wire stripper (still to be found)
  • a few EV3 and Powered cables and plugs
  • an Arduino and a NodeMCU
  • a FTDI Beefy 3 breakout board (or 2!!!)
  • a kit of resistors, diodes, capacitors and LEDs
  • a small motor driver or H-Bridge breakout board (shame!!!)
  • a swiss army knife
  • of course some LEGO (at least one EV3 rover with wi-fi and BLE)
  • some ziplock bags
  • a good excuse

FTDI adapter working… sometimes

Gremlins once again.

BOOST Interactive Motor connected to the FTDI Beefy 3 adapter.

  • Wiring:
    • 6 = RX
    • 5 = TX
    • 4 = 3V3
    • 3 = GND

Just that, no pull up resistors or whatsoever.

When it works, it’s like with the Bus Pirate (including sometimes it just receiving

C0 00 3F

When it doesn’t work… I just get ’00’ after ’00’. Then I remove the 3V3 wire and/or use picocom instead of jpnevulator… and after endless tries it now works?!?

Also changed the FTDI Beefy to another USB port. But if that had any impact it wasn’t immediately.

You ought to love the scientific precision present in these posts 😀

If/when these results gets consistent… I just need an H-Bridge to control the motor and use the FTDI Beefy to read the encoder status. Why didn’t I put an H-Bridge on my holidays luggage?

Edit: found the Gremlin, doesn’t mean I understand it:

Procedure:

1. Connect the FTDI Beefy adapter to USB
2. Start picocom then exit (^A^Q)

 picocom -b 115200 /dev/ttyUSB3

3. Start jpnevulator

jpnevulator -i 10 --tty /dev/ttyUSB3 --read

4. Start adapted shell script and manually remove and reinsert power (3V3) while the Motor is receiving zeros:

#!/usr/bin/env bash

# send lots of 0's
for i in {1..50000}
do
    echo -e -n "\x00" > /dev/ttyUSB3
done

# send Init Sequence
echo -e -n "\x54\x22\x00\x10\x20\xB9" > /dev/ttyUSB3

# send Keep Alive's
for i in {1..50000}
do
    echo -e -n "\x02" > /dev/ttyUSB3
    sleep 0.1
done

So what is this Gremlin inside picocom doing?

From the man page:

Unless the –noinit option is given, it configures the device to the settings specified by the option-arguments (or to some default settings), and sets it to “raw” mode. If –noinit is given, the initialization and configuration is skipped; the device is just opened.

Looks like this “raw” mode is needed for jpnevulator to work. And exiting with ^A^Q  leaves the tty in that mode:

Quit the program *without* reseting the serial port, regardless of the “–noreset” option.

So what is this raw mode and how do I configure it without running picocom? Google points me to Configuring Linux’s serial port to raw mode by Alan C. Assis:

So stty has a ‘raw’ option and this is enough:

stty -F /dev/ttyUSB3 115200 raw

And it works. Yes, it really does!

That’s also the reason Bus Pirate was also working: I was using picocom to configure it.

Argh, so many nights with such a silly issue.

Progress at last

No luck yet with the FTDI cable. But at least I got it with the Bus Pirate!

So:

No LEGO Hub here, just my laptop, the Bus Pirate and the LEGO BOOST Interactive Motor.

Wiring from the Bus Pirate to the Motor:

      • GND -> Pin 3
      • 3V3  -> Pin 4
      • MOSI -> Pin 5
      • MISO -> Pin 6
  • Setup:

Connect the Bus Pirate to the USB port, should show up as ‘/dev/ttyUSB3’.

Access the Bus Pirate with a terminal program like picocom:

picocom -b 115200 /dev/ttyUSB3

Send this commands:

‘m’ to choose mode

‘3’ to choose UART

‘9’ to choose 115200 bps

‘1’ to choose 8 bits without parity (8N)

‘1’ to choose 1 stop bit (so 8N1)

‘1’ to choose receive polarity as Idle = 1 (usual TTL levels)

‘1’ to choose output type ‘Open Drain (H=Hi-Z, L=GND)’

Now that the Bus Pirate is in UART mode:

‘W’ to turn Power Supplies ON (3V3 and 5V pins)

‘P’ to turn Pullup resistors ON

(1) to put the Bus Pirate in ‘Transparent bridge’ mode

‘y’ to confirm

Now quit the terminal (thats Control+A+Q for picocom) and use a serial sniffer like jpnevulator:

jpnevulator -i 10 --tty /dev/ttyUSB3 --read

We should now receive continuous ’00’

Then send the AutoID sequence to the Motor and after that keep sending ’02’ every 100 ms:

#!/usr/bin/env bash

echo -e -n "\x54\x22\x00\x10\x20\xB9" > /dev/ttyUSB3

for i in {1..1000}
do
    echo -e -n "\x02" > /dev/ttyUSB3
    sleep 0.1
done

Sometimes this doesn’t work at first and we just receive a sequence of

C0 00 3F

But aborting the script and trying again will get us:

D8 00 00 00 00 00 00 00 00 27

and if we turn the axle by hand a bit (first clockwise then anticlockwise):

D8 00 01 00 00 00 00 00 00 26
D8 00 01 00 00 00 00 00 00 26
D8 00 02 00 00 00 00 00 00 25
D8 00 02 00 00 00 00 00 00 25
D8 00 02 00 00 00 00 00 00 25
D8 00 02 00 00 00 00 00 00 25
D8 00 03 00 00 00 00 00 00 24
D8 00 03 00 00 00 00 00 00 24
D8 00 04 00 00 00 00 00 00 23
D8 00 04 00 00 00 00 00 00 23
D8 00 04 00 00 00 00 00 00 23
D8 00 04 00 00 00 00 00 00 23
D8 00 04 00 00 00 00 00 00 23
D8 00 04 00 00 00 00 00 00 23
D8 00 04 00 00 00 00 00 00 23
D8 00 04 00 00 00 00 00 00 23
D8 00 04 00 00 00 00 00 00 23
D8 00 04 00 00 00 00 00 00 23
D8 00 04 00 00 00 00 00 00 23
D8 00 04 00 00 00 00 00 00 23
D8 00 04 00 00 00 00 00 00 23
D8 00 03 00 00 00 00 00 00 24
D8 00 03 00 00 00 00 00 00 24
D8 00 02 00 00 00 00 00 00 25
D8 FE 01 00 00 00 00 00 00 D8
D8 FE 01 00 00 00 00 00 00 D8
D8 00 01 00 00 00 00 00 00 26
D8 00 01 00 00 00 00 00 00 26

If  I stop sending this ’02’ every 100 ms the Motor stops sending the encoder status and returns to ’00’. It also looses it’s current state if I don’t restart the whole script soon enough (or just start ’02’ again).

The BitScope logic analyzer wasn’t a great help (except for the timings). I had much more success using the Bus Pirate in ‘Transparent Bridge’ mode to capture each wire of the motor.

Now the reason I cannot replicate this is the FTDI cable is probably the lack of pullup resistors since I’m using a Sparkfun Beefy 3 with an internal PSU that should give enough current to the 3V3 pin. But the Motor also has its own internal pullup and pulldown resistors so this shouldn’t be a problem. is still unknown. Reading the Bus Pirate documentation using the pull up resistors should make no difference because I would also need to manually tie the pull up voltage to 3V3… and I didn’t. Probably the Hi-Z (high impedance) state of the output pin has some importance.

Have to try the FTDI cable again.

Edit: although documentation states that the Bus Pirate pull up resistors also need a manual connection to 3V3… I only have readings when activating the pull ups. And I do have a BP 3.6 board. Go figure.

Edit #2: added “-n” to the test script to prevent sending a New Line (‘0Ah’)

Edit #3: turns out it has nothing to do with pull up resistors or Hi-Z modes… when using picocom to configure the Bus Pirate it changes ‘/dev/ttyUSB3’ to raw mode and leaves it on that mode when quitting… so I can now use jpnevulator to capture all messages from the motor.

 

Device 09

I have a 3V3 FTDI cable with me.

So:

FTDI RX -> BOOST Hub pin 6 (TX)
FTDI TX -> BOOST Hub Pin 5 (RX)
FTDI GND -> BOOST Hub Pin 3 (GND)

Just by connecting it to Port C I get a new device discovered:

0f 00 04 01 01 09 00 00 00 00 00 00 00 00 00

Device Type 09 is a new device. Don’t know what to do with it.

Adding resistors to try to emulate the BOOST Interactive Motor changes nothing.

Tried a few bash scripts to send the power up sequence of the motor… nothing changed. Perhaps bad timings?

Rewired pin 6 to CTS# instead of RX and enabled Handshaking:

stty -F /dev/ttyUSB3 crtscts 115200

Tried again without timings. Nothing changed.

So the only good new is that BOOST detects a UART device as a device of type ’09’ so future hacking will be possible… as soon as we understand it.

The power up sequence of the interactive motor

This is a typical sequence I get, after powering up the BOOST Hub with the motor already attached to port C:

57 lines of 10 ’00’ bytes

1 line containing the AutoID ’00 00 00 00 54 22 00 10 20 B9′

then the initial status of the encoder is sent (‘D8 00 FF FF FF FF 00 00 00 27’ or ‘D8 00 00 00 00 00 00 00 00 27′) repeating every 0.1 seconds (so each byte takes 10 ms if there is no pause between them).

Not sure about the timings of the AutoID message but the first 63 lines took 1.71126 seconds. This includes 5 encoder status messages so the power up sequence takes only 1.21 seconds and includes 574 ’00’ followed by ’54 22 00 10 20 B9′. If all 580 bytes were timed the same, that would be 2 ms between each.

Need to get back to the logic analyzer to be sure of the timings.