Lego-Fischertechnik.

[fotoopa]

Connection Lego and Fischertechnik.
By combining both systems we can enjoy their advantages. The data and command exchange occurs on 2 levels. There is a serial duplex connection via the hubE and the DE0-Nano_Soc board. On the other hand, the data lines of the other hubs are also read by the board. The latter can thereby process data in real time and without interaction of the running software. This data can mainly be used by the TXT Controller to display the results on the PC screen. Motor speed, position, sensor color information, distance information and pressure can all be read out. From the Lego side there is no need to write a program. The DE0 board simply listens in real time.
The DE0 board responds very quickly ( only a few usec). The connection is via 115200 baud but can be much faster if needed. I now need to work out some protocols to build a large application.

Lego-Fischertechnik by Frans, on Flickr

Frans

[MasterOfGizmo]

You don't need anything between the TXT and the LEGO controllers for this. The TXT is able to directly interface to bascially all the LEGO controllers, either via USB (e.g. to the Spike Hubs) or via Bluetooth (to the Technic and City Hubs). And also all older LEGO controllers like the Boost, WeDo 2.0 or WeDo 1.0 can be connected directly.

See e.g. this:
https://www.youtube.com/watch?v=Y1m1k-_eHNk

The current LEGO UART protocol is documented at several places like this one:
https://github.com/pybricks/technical-i ... 268dd268ba

What protocols are you going to analyze? IMHO everything is already documented.

[MasterOfGizmo]

Btw: All six hub ports use the uart protocol with tx on pin 5 and Rx on pin 6. The Lego hub cannot use pin 6 as an output as shown in your drawing.

Pins 5 and 6 can be used with simple pull-up/pulldown resistors on device side for device type identification. This is used in the very simple motors. All newer motors (especially those with encoders) and sensors use the uart protocol.

[fotoopa]

You don't need anything between the TXT and the LEGO controllers for this. The TXT is able to directly interface to bascially all the LEGO controllers, either via USB (e.g. to the Spike Hubs) or via Bluetooth (to the Technic and City Hubs). And also all older LEGO controllers like the Boost, WeDo 2.0 or WeDo 1.0 can be connected directly.

See e.g. this:
https://www.youtube.com/watch?v=Y1m1k-_eHNk

The current LEGO UART protocol is documented at several places like this one:
https://github.com/pybricks/technical-i ... 268dd268ba

What protocols are you going to analyze? IMHO everything is already documented.

Your indicated links mainly concern all older LEGO controllers. The protocol of the Mindstorms 51515 or the Spike inventor differs thoroughly with all older sets like: WeDo 2.0 or WeDo 1.0 . Lego's official documentation on this is still quite limited. Most of the information comes from reverse engineering that a few have done.
Philo's homepage: https://www.philohome.com/
https://github.com/maarten-pennings/Leg ... ms4/faq.md
https://docs.pybricks.com/en/latest/hubs/primehub.html

On my FPGA, I do not have direct access to Bluetooth, nor do I have the knowledge to implement it. However, I have a tremendous amount of I/O and that is exactly the point where the new Lego hub just has nothing. Everything is focused on their robot and its many applications such as line followers, color and distance sensing and built in a small space. Their flat cables are fixed length 25 cm, so extremely short. They do not yet provide extension cables and their connector is Lego property. You cannot connect any old version of sensor or motor into the hub. Now everything is also internally at 3V3 where before it was 5V. The motor PWM levels are the same though. The new motors do have an absolute encoder (of 360 degrees) with a relative position value next to it. This is also completely different than the old motors.

Lego and Fischertechnik, both have made innovations that have always appeared too early due to marketing. The product is not completely finished but we must look to the future with confidence. Software has been updated and is mostly still in beta phase. I expect it will be temporary. We have to accept this.

With my existing FPGA module, I want to make the two systems, FT and Lego, to work together. With the FPGA I have the ability to listen to all 6 hubs of lego and record the data without writing 1 letter of code on the Lego side. The delay in doing so is negligible. I can easily make trigger points for the scope. This is useful when running the software. You can measure all kinds of measurement delays. Also command like Bluetooth, serial, sensors etc. Bluetooth is used between the hub and the PC and also with the PS4 remote control. Soon I will be able to make a demo with Lego and FT where that PS4 is also used.

To use commands in either direction between FT and Lego I am going to use a serial line on hubE. For this I have already written all the code along both sides. I have already tested this and it works perfectly. There will be a small video of this soon though.

The TXT Controller is ideal for use as a GUI. All the software exists for this. Attaching the Lego side is not that difficult. Now I can put all the data values of the Lego hubs on the big PC screen. This is real time data. Vice versa you can also place buttons and sliders on the PC screen as commands for the Lego, also Led status.
As you can see there is a lot to measure. For this new Lego hub there is still a lot of updating to be done.
I believe in these new products and will try to use them. My dream now is to make a meaningful larger project that fully utilizes both systems.

Frans.

------ Added by Moderator Ralf (Translation by deepl)
Die von Ihnen angegebenen Links betreffen hauptsächlich alle älteren LEGO Controller. Das Protokoll des Mindstorms 51515 oder des Spike Inventors unterscheidet sich durchaus mit allen älteren Sets wie: WeDo 2.0 oder WeDo 1.0 . Die offizielle Dokumentation von Lego zu diesem Thema ist noch recht begrenzt. Die meisten Informationen stammen aus dem Reverse Engineering, das einige wenige durchgeführt haben.
Die Homepage von Philo: https://www.philohome.com/
https://github.com/maarten-pennings/Leg ... ms4/faq.md
https://docs.pybricks.com/en/latest/hubs/primehub.html

Auf meinem FPGA habe ich weder direkten Zugang zu Bluetooth, noch verfüge ich über das Wissen, um es zu implementieren. Allerdings habe ich eine enorme Menge an E/A, und das ist genau der Punkt, an dem der neue Lego-Hub einfach nichts hat. Alles ist auf den Roboter und seine vielen Anwendungen wie Linienverfolgung, Farb- und Entfernungsmessung ausgerichtet und auf kleinstem Raum untergebracht. Ihre Flachkabel haben eine feste Länge von 25 cm, sind also extrem kurz. Sie bieten noch keine Verlängerungskabel an und ihr Stecker ist Eigentum von Lego. Sie können keine alten Versionen von Sensoren oder Motoren an den Hub anschließen. Jetzt ist auch alles intern auf 3V3, wo vorher 5V waren. Die PWM-Pegel der Motoren sind jedoch die gleichen. Die neuen Motoren haben einen absoluten Encoder (von 360 Grad) mit einem relativen Positionswert daneben. Das ist auch völlig anders als bei den alten Motoren.

Lego und Fischertechnik, beide haben Innovationen gemacht, die aus Marketinggründen immer zu früh erschienen sind. Das Produkt ist noch nicht ganz fertig, aber wir dürfen zuversichtlich in die Zukunft blicken. Die Software wurde aktualisiert und befindet sich größtenteils noch in der Betaphase. Ich gehe davon aus, dass dies nur vorübergehend sein wird. Das müssen wir akzeptieren.

Mit meinem bestehenden FPGA-Modul möchte ich erreichen, dass die beiden Systeme, FT und Lego, zusammenarbeiten. Mit dem FPGA habe ich die Möglichkeit, alle 6 Hubs von Lego abzuhören und die Daten aufzuzeichnen, ohne einen Buchstaben Code auf der Lego-Seite zu schreiben. Die Verzögerung dabei ist vernachlässigbar. Ich kann leicht Triggerpunkte für das Oszilloskop erstellen. Das ist nützlich, wenn die Software läuft. Man kann alle Arten von Messverzögerungen messen. Auch Befehle wie Bluetooth, seriell, Sensoren usw. Bluetooth wird zwischen dem Hub und dem PC und auch mit der PS4-Fernbedienung verwendet. Bald werde ich eine Demo mit Lego und FT machen können, bei der auch die PS4 verwendet wird.

Um Befehle in beide Richtungen zwischen FT und Lego zu verwenden, werde ich eine serielle Leitung am hubE verwenden. Dafür habe ich bereits den gesamten Code auf beiden Seiten geschrieben. Ich habe dies bereits getestet und es funktioniert perfekt. Ein kleines Video davon wird es aber bald geben.

Der TXT Controller ist ideal für den Einsatz als GUI. Die gesamte Software dafür ist vorhanden. Das Anbringen der Legoseite ist nicht so schwierig. Jetzt kann ich alle Datenwerte der Lego-Hubs auf den großen PC-Bildschirm bringen. Das sind Echtzeitdaten. Umgekehrt kann man auch Knöpfe und Schieberegler auf dem PC-Bildschirm als Befehle für das Lego platzieren, auch Led-Status.
Wie Sie sehen können, gibt es eine Menge zu messen. Für diesen neuen Lego-Hub müssen noch viele Aktualisierungen vorgenommen werden.
Ich glaube an diese neuen Produkte und werde versuchen, sie zu nutzen. Mein Traum ist es nun, ein sinnvolles größeres Projekt zu machen, das beide Systeme voll ausnutzt.

[MasterOfGizmo]

The older boost controller and even the wedo2 as well as the current technic and city hubs use the same connectors and the sensors and actors are compatible with the spike and the 51515. I have all of them and mix them all the time. All devices using the same physical connectors are fully compatible with each other.

The cables and connectors are proprietary, that's true. But you can easily buy them in china. I am using these to e.g. connect LEGO sensors to arduinos.

The motors still run at 9v via pins 1 and 2. The logic part runs at 3.3v, that's true. But that already was the case with the boost and the wedo2.

You cannot do much with the sensors if you only listen to them. All the sensors support many "modes" like e.g. the color sensor that can either sense colors or ambient brightness or even distances and much more. The motors can e.g. sense speed, torque, angles and much more.

But the controller needs to configure these modes on the sensors. So if you don't run you own software on the Lego side you will not be able to use anything than the default modes which are sure useful but only give you access to a fraction of the possibilities. The Lego sensors sure are great

I am currently not home. When I am back I'll take a snapshot of my BrickDuino controller. It's basically a ftDuino for Lego. It has four of those china made Lego connectors and can fully access all motors and sensors from the wedo2.0 up to the current hubs.

It may actually be that the newer devices have some additional communication modes. I never checked that. But they are all backward compatible. I can even run the new motors on the old controllers using a PC under Python via Bluetooth. That's something the Lego software refuses to do.

[fotoopa]

You cannot do much with the sensors if you only listen to them. All the sensors support many "modes" like e.g. the color sensor that can either sense colors or ambient brightness or even distances and much more. The motors can e.g. sense speed, torque, angles and much more.

But the controller needs to configure these modes on the sensors. So if you don't run you own software on the Lego side you will not be able to use anything than the default modes which are sure useful but only give you access to a fraction of the possibilities. The Lego sensors sure are great

Here are a couple of screen shots of how I intercept the information on pin5 without modifying Lego's original modes.

Pico-scope lego hubA motor and readout via TXT by Frans, on Flickr

readout-color-sensor by Frans, on Flickr

The cables and connectors are proprietary, that's true. But you can easily buy them in china. I am using these to e.g. connect LEGO sensors to arduinos.
It may actually be that the newer devices have some additional communication modes. I never checked that. But they are all backward compatible.

I only have new devices and as far as I know the old ones can't just be plugged into the new hub. By the way, this is the reason why so many existing users are not satisfied.
Frans.

[MasterOfGizmo]

Please try to read e.g. a distance or raw RGB color information from the color sensor. This will imho only work if you change mode.

The old motors work on the new controllers. Actually the motors sold with e.g. the city hub in the batmobile IS one of the old wedo2.0 motors.

If the connectors fit then the devices can talk to each other. It's the Lego software on the smart device that sometimes doesn't support some of the mixed combinations. But if you run your own code on a PC or on a TXT to control the Lego Hub then you can mix all of them.

You should try one of the small Lego wedo2 0 motors on your 51515 ä. They will work on the 51515 but as they don't use the uart protocol your FPGA will not see anything.

Funny side note: There are resistor combinations for ID's for non-uart devices that were never used by any real Lego device. Still they work and if you build such a device yourself then the Lego controllers will recognize them.

Also all sensors support test and debug modes which seem to be for internal testing. But the Lego software hides these and you cannot use them with original Lego software. You can however if you control the Lego controller yourself via Bluetooth from a PC or use an Arduino to control the Lego sensor.

Really those Lego sensors are fun and you can do many things with them Lego never wanted you to do. But for that you need to send your own commands to them.

[fotoopa]

Please try to read e.g. a distance or raw RGB color information from the color sensor. This will imho only work if you change mode.

The old motors work on the new controllers. Actually the motors sold with e.g. the city hub in the batmobile IS one of the old wedo2.0 motors.

I have read those too and it works perfectly, more so you have a 10x higher resolution (mm versus cm) than their value on the Mindstorms status window. I don't have a direct screenshot of this right now.

If the connectors fit then the devices can talk to each other.

You can't connect them directly to the new hub because the connector doesn't fit.

Also all sensors support test and debug modes which seem to be for internal testing. But the Lego software hides these and you cannot use them with original Lego software. You can however if you control the Lego controller yourself via Bluetooth from a PC or use an Arduino to control the Lego sensor.

Really those Lego sensors are fun and you can do many things with them Lego never wanted you to do. But for that you need to send your own commands to them.

Their included Python program does allow you to access other modules. I was able to control their 3x3 color led matrix even though it is not included.

[MasterOfGizmo]

How do you change the sensor mode then? I know some sensors have something like a "report everything" mode which may be what the spike enables by default. But not all sensors support that.

The wedo2.0 uses the same connectors and its motors can be attached to the spike and the city hub. That's what the batmobile does The device in my video is a wedo2.0.

The wedo 1.0 had different connectors.

The ev3 had different connectors but a similar protocol. But not identical.

[fotoopa]

How do you change the sensor mode then? I know some sensors have something like a "report everything" mode which may be what the spike enables by default. But not all sensors support that.

See:
https://github.com/maarten-pennings/Leg ... inventor-1

The wedo2.0 uses the same connectors and its motors can be attached to the spike and the city hub

This is not the Mindstorms51515 or the Spike inventor.

[MasterOfGizmo]

So you do run Python program on the Lego to switch modes. I thought you wrote that no software on Lego side is needed. Ok then.

Imdeed, the City Hub is not the Spike Hub but they use a very similar hardware, the same connectors and connect to the same sensor and motor devices. The city hub can use WeDo2 motors and so can the spike.

[MasterOfGizmo]

The WeDo 2.0 motor being detected and used by the Spike:

spike.jpeg (40.43 KiB) 8496 mal betrachtet

Believe me, they are all compatible. I own them all

[MasterOfGizmo]

BTW: Do you want a nice Python IDE to run Python code on the Spike? Try https://github.com/harbaum/upide

[fotoopa]

The WeDo 2.0 motor being detected and used by the Spike:
Believe me, they are all compatible. I own them all

Surely a photo like this is convincing.
This means that this extension cable would fit on the Mindstorms 51515 hub : https://www.toypro.com/nl/product/7355/ ... 35cm/zwart
That one is in stock there. Still, those cables have a little locking tab that is not there on the new sensors and motors. I wonder how it goes then, or does it not interfere.

So you do run Python program on the Lego to switch modes. I thought you wrote that no software on Lego side is needed. Ok then.

In that case yes, it is an output. If you want to see something change you have to control it. For inputs like color sensor, distance sensor or pressure sensor and the new motors you see the results immediately after the powerup. You can run the motor manually and even then you will see the values change without programming anything.

BTW: Do you want a nice Python IDE to run Python code on the Spike? Try https://github.com/harbaum/upide

I see that you have to upgrade the hub again. I would rather not do that to be able to use the Mindstorms for now. Especially the grandkids can already use that.

Sorry for the later reply. I had to go to the hospital today for an injection in my eye (the 29th time). Then I am under anesthesia for a while and cannot work properly on the PC. Now it's starting to go back a bit.

Frans.

[MasterOfGizmo]

Hi Frans. Hope you eyes get better.

That is no extension cable. The WeDo2 and it's peripherals have the same connectors as the spike. It fits directly.

You don't need to upgrade or flash your hub for uPIDE. The spike and the 51515 are shipped by Lego with a standard Micro-Python firmware which will work with any Micro-Python ide out of the box. It would be cool if fischertechnik did similar. Using standard software components makes things much easier.

[fotoopa]

That is no extension cable. The WeDo2 and it's peripherals have the same connectors as the spike. It fits directly.

Yes I understand that. But my question was if these extension cables fit. I am looking to cut them and put a pcb in between to reach the connection points. I want to have pin5 available from each hub to send to the FPGA for listening in on the lines. I suspect that those indicated cables are not going to fit

I checked that uPIDE for a while but for now I don't understand how everything works. Looks way too difficult for me right now to start it up.

[MasterOfGizmo]

The cables you linked to are for a he NXT which In turn is the predecessor of the EV3. It will not work with the spike. You need power function 2 (pf2) cables and connectors. I only found them in china

But if you just want to get access to the signals you can mount a standard 6 pin flat cable connector onto the Lego cable. The Lego cables have standard 1.27mm spacing and these headers fit just fine.

uPIDE will just work without setting up anything. But if you are happy with the Lego software there's no reason to switch.

[MasterOfGizmo]

An image is worth a thousand words. So ...

This is a single BrickDuino, a ftDuino like device, but for Lego:

brickduino.jpg (24.73 KiB) 8348 mal betrachtet

Two of them:

brickduinos.jpeg (31.59 KiB) 8348 mal betrachtet

Some LEGO powered up / power functions 2 connectors from china:

pf2_cons.jpeg (31.02 KiB) 8348 mal betrachtet

A LEGO sensor with a standard 6 pin connector in the middle for quick access to the signals:

pf2_pfosten.jpeg (20.63 KiB) 8348 mal betrachtet

[fotoopa]

The cables you linked to are for a he NXT which In turn is the predecessor of the EV3. It will not work with the spike. You need power function 2 (pf2) cables and connectors. I only found them in china

But if you just want to get access to the signals you can mount a standard 6 pin flat cable connector onto the Lego cable. The Lego cables have standard 1.27mm spacing and these headers fit just fine.

Okay that's clear. I expected them to be NXT types and therefore not usable. I could also use the solution with the 6 pin standard on the flat cable but it can cause mounting problems if you want to build the original models. Therefore I have not yet modified any of the original motors or sensors supplied with the kit. The best solution is like your female conectors from china. But ordering something from china is not possible here. My wife would rather not have it. If I could buy it locally then it would not be a problem.

For the uPIDE, I'll see later. There are other Python solutions but they require a hub software update. You can always restore it but I'd rather wait. I still need to learn first the Python language sufficiently.
Thanks for the helpful clarification.

[MasterOfGizmo]

Your FPGA board is also manufactured in china ...