LEGO Powerfunctions example for Arduino

[kaaaeeesss]

Dear all,

I'd like to write a concise example for an LEGO Power functions Irsender.

What I achieved already:

• I evaluated several recent and old ir libraries for Arduino out there and on github. IRMP was the one that showed up results easily.
• I prepared two Arduino Uno boards: one (A) as a receiver, and (B) as sender. Both circuits are very simple, using transmitter or led only.
• I adapted slightly the OneProtocol.ino example, e.g. uncommented:

#define F_INTERRUPTS                     20000   // interrupts per second, 50us, min: 10000, max: 20000, typ: 15000
#define IRMP_SUPPORT_LEGO_PROTOCOL       1       

• I can capture ir signals from a LEGO ir-remote-control (8885) now. Important From a distance of ca. 1m(!) the receiver works and prints lines like these - on channel 4, blue forward:

P=LEGO A=0x0 C=0x310
P=LEGO A=0x0 C=0xF15
P=LEGO A=0x0 C=0xB11

EDIT: Deleted my first approach for irsender sample code

• With examples AllProtocols for receiver and SendAllProtocols for sender both boards communicate with each other. But with default setting IRSND_IR_FREQUENCY 40000 the LEGO protocol is not executed.
• In SendAllProtocols the ir frequency has to be increased to 40.000. Otherwise the the enabled LEGO protocol is ignored!

#define IRSND_IR_FREQUENCY          40000
//#include <irsndSelectAllProtocols.h>
#define IRSND_SUPPORT_LEGO_PROTOCOL             1

Could anybody give me an advice ...

• how to ensure, that LEGO protocol is used only for sending and receiving,
• what lines of codes can be avoided, when only one target board is wanted - or the other way: how to use IRPM library to write own code in a concise way,
• where the parameters for channel and commands could be set precisely?

Thanks

[ArminJo]

IRData IRSendData;
IRSendData.protocol = FAST;

???

What is the output of ReceiveDemo example, for the code sent above?

[kaaaeeesss]

???

@ArminJo Oh, ... I'm so sorry. In this first approach I used the IRremote lib, because there are explicit functions like sendLegoPowerFunctions. Now I know where I am ...

Meanwhile, I connected two arduinos via LEGO protocol successfully, wrote the last paragraphs anew, made the questions I have more clear.

[ArminJo]

No problem with IRremote, but you should use the latest version.

where the parameters for channel and commands could be set precisely?

I think for Lego sending IRremote suits better than IRMP!

what lines of codes can be avoided, when only one target board is wanted - or the other way: how to use IRPM library to write own code in a concise way,

Do you mean something like the IRMP OneProtocol or IRremote SimpleRecever example?

[kaaaeeesss]

Well, an adjusted OneProtocol was my first successful attempt which has shown that something is happening. But it is the receiver, and this arduino receiver is needed only to evaluate an arduino sender. Lego protocol seems to be little bit wobblier than others, so I first need a testing environment. My real Lego Receiver was silent until now, because I couldn't estimate that somethings happening at all. The receiver side is solved. Now: The Sender side is solved with SendAllProtocols.

So I took a look at TinySender and SimpleSender now. I will play around with SimpleSender, because I think I can understand it now a little bit. The next step will be to speak to arduino reciever and than I hope the LEGO receiver does 'something'.

BTW: The goal of this enterprise is to speak with an Lego model via IR from an arduino and e.g. to stear motors. This approach has the advantage that you can talk in a nondestructive way to your construction - AND you test your construction simply with the LEGO IR remote before you can add an 'intelligence' by an arduino. Another way to talk with LEGO motors is using a motor shield, but this means deeper structural changes (sometimes).

[kaaaeeesss]

This evening brought success:

1. I adapted SimpleSender a little bit, more or less adding these two lines:

#define IRSND_IR_FREQUENCY          40000
#define IRSND_PROTOCOL_NAMES        1

2. The LegoSender is sending something like:

Protocol=LEGO  Address=0x0 Command=0x10 Repeats=1

which is

static uint8_t sAddress = 0;
static uint8_t sCommand = 16;
static uint8_t sRepeats = 1;

This is also what i captured from the LEGO IR Remote. The LED in the LEGO Receiver is blinking now. That means it's recognizing a signal.

I captured furthermore commands like 0x310, 0xB12, 0x354, 0x398, 0xB18. This means that sCommand has the type int instead of uint8_t, e.g.

sCommand = 2072;

sends a command 0x818, which is blue forward on Channel 1.

And voila: The wheels are turning!

[kaaaeeesss]

I took a closer look on the codes and analyzed them, what they could mean according to the LEGO Power Functions v1.20.

The sCommand (as int) is actually a series of bits as groups of 4 bits, which are called a "nibble".
So, the int 2072 encoded as 0x818 is some crude representation of 1000 0001 1000.

This reads in natural language:

On channel 1 of a Power Functions receiver in Combo direct mode move backwards on output B.

As far as I can see, my ir receiver from LEGO set 42095 understands only the very simple Combo direct mode with commands move forward, move backward and float.

In this case it's a good starting point to use the numbers for Channel 1:

1. 2065 : move forward (red)
2. 2066 : move backwards (red)
3. 2068 : move forward (blue)
4. 2072 : move backward (blue)

[kaaaeeesss]

I can prepare a gist now and post it later ...

[kaaaeeesss]

ich switch mal kurz auf deutsch: ja, vielen dank. ja, bin ich auch drüber drübergestolpert. und es gibt ja auch noch ältere libraries, die sich dem thema gewidmet haben. Aber leider ist das lego- und auch das ir-thema für sich schon sehr sperrig. so ein einstiegstutorial zu einer standard-fernbedienung von sony geht tatsächlich genauso wie's dasteht.
Bei LEGO hab ich erstmal den Pfad verfolgt, welche Library überhaupt etwas verständliches von sich gibt.

Ich würde es also im Ganzen eher als ein Nachvollziehen als ein Neu-Erfinden sehen.

Denn jetzt kann ich auch dein *hpp da drüben besser verstehen.
Allerdings fehlt(e) mir eine Beispiel-Anwendung als Sketch, ich hatte - glaub ich -das hpp in der installierten library nicht gefunden, jetzt hätte ich die frage und hoffnung, dass doch mehr geht als combo direct mode. und dann ist ja immer noch so, dass man die spezifikation genauer kennen muss, um das hpp auf das eigene modell anwenden zu können.

im gegensatz, das charmante an der "lösung" hier ist: es sind nur zwei anpassungen und vier zahlen. damit geht's schon los.

[ArminJo]

Ein kurzes und gut dokumentiertes Beispiel von dir könnte man noch in der Library aufnehmen, oder bei discussions show + tell reinstellen.

[kaaaeeesss]

Ich habe das Beispiel-Sketch als gist erstellt.

Es handelt sich um ein Fahrzeug. Der rote Output regelt einen Servo als Lenkung - deswegen turnLeft() und turnright(). Der blaue Output regelt den Motor - deswegen moveForward() und moveBackward().

Im Loop werden der Reihe nach alle IRCommands durchgetestet.

Eigentlich ist dieser Ansatz ja ein bisschen schwammig, weil durch die ints der Aufbau der IR-Befehls verschleiert wird. @ArminJo Meinst du, ich soll das weiterverfolgen? Ein Show + Tell finde ich eine gute Idee, aber vielleicht reicht auch einfach diese Diskussion hier.

Im echten Modell zeigten sich zwei neue Herausforderungen:

1. Wenn das Modell liegt (Reifen in der Luft, damit es nicht davonfährt), scheinen Lichtquellen (z.B. Monitor, Lampe) die Übertragung zu stören. Deswegen hatte ich einige Versuche mit sehr seltsamem Verhalten, und war mir nicht sicher ob es am Infrarot (delay, Dauer der Ausfürhung usw.) selbst liegt. Gibt es das? (Wenn ich das Modell aufrichte, funktioniert es - also der Code - wie erwartet).
2. In dieser Version kann ich nicht um die Ecke fahren! Weil nur ein Output bedient werden kann. Ich brauche eine Lösung im Combo PWM Mode, S. 10.

Ich überlege, ob ich es nicht ab jetzt "richtig" machen sollte und mich mit deinem Lego-Modul in irRemote beschäftigen sollte.

[ArminJo]

Das Lego Protokoll ist sehr störanfällig, das habe ich auch bei meinem Unit Test gemerkt.
Für IRMP reicht sicher die Diskussion.
Ansonsten würde ich IRremote nehmen, da gibt es nicht so viele "magic numbers".

[kaaaeeesss]

Ich bin noch dran ... :D
Bevor ich rüber zu IRremote wechsle, wollte ich noch folgende Anmerkungen loswerden:

• Es gibt ein paar Videos und Erläuterungen zu den mindestens zwei verschiedenen Lego IrReceivern. In diese ist unterschiedlich viel Magie eingebaut - als Schutz vor Überhitzung der Motoren -, so dass da einiges mehr an Delay usw. sich ereignen kann als bei einem einfachen Programmwechsel an einem Fernseher.
• Der Befehl und die Umsetzung in diesem Beispiel stammt aus einem Set für einen Stunt Racer (42095). Das Verhalten könnte man dem entsprechend als sportliche und spritzige Fahrweise bezeichnen. Tatsächlich fährt mein Model bei nur einer Wiederholung etwa einen Meter und ziemlich ruppig.
• Den Befehl für float - also Bremsen durch Loslassen - brauche ich hier nicht, bzw. konnte ich keine Auswirkung beobachten.
• Aus den beiden vorhergehenden Punkten ergibt sich also, dass diese Art der Steuerung für eine feine Steuerung für Fahrzeuge nur bedingt geeignet ist. Ein Fahrzeug sollte ja - falls notwendig - sofort stoppen, sonst geht es über die Klippe, den Tisch, die Treppe, gegen die Wand.

Andererseits könnte man noch mit kleineren Übersetzungen experimentieren. Oder andere Anwendungsfälle finden, z.B. das Öffnen von Türen, die Steuerung der Lego-Servos funktioniert prima.

[kaaaeeesss]

Zum vorläufigen Abschluss habe ich das gist etwas angepasst:

• Den Namen payload in Funktion und Variable zu nibble23 geändert, weil die "magischen Zahlen" nur die "nibbles" 2 und 3 setzen, nicht die ganze Payload.
• Die "magischen Zahlen" für die anderen Kanäle ergänzt.