Project: Programs to allow interactions between old Lego Control Interfaces (RCX, Lego Interface B, others?)

[Wapata]

11 hours ago, Toastie said:

These are metallic switches, right? On the bottom?

Sorry but i don't think so.... i won't try to break a rare component if it work but the rectangle you see in the botom of the lego pin is grey... by reflection. Rhe rubber part pass trough it to touch the two metal plates.

But... I do have some pictures of my grey one dismounted for reparation :

To be clear : the resistor thing is a great idea but the rubber conductive part such a bad one it should ruin the effet.

By the way : the "identification" is quite easy in theory : resistors in parallel so the ohm result of the 3 buttons pushed should be 1/r1 + 1/r2 + 1/r3 and so on for every situation... But the rubber part make soooo much ohm differences that it could not work great. I mean... now with Blockly we have the ability to see in live the input values... and see that it not at all a "full on / full off" device, but the value increase with the pression. 

 

EDIT : new page so i'm adding the other picture i'm proud of :

Edited Sunday at 06:14 AM by Wapata
adding previous picture

[Bliss]

In the latest Lego Blockly app version, I added support for the WeDo 1.0 hub.  Power Function Motors will fit but slower since it's USB 5v...  and PF motors are 9v I think.
There are a TILT sensor and a Distance Sensor with WeDo 1.0 kit...
It works in windows, Linux should work, not garanteed for Mac OS X, I would be very surprised for Android with OTG.
It is using WebHID API...
I might add support for  the WeDo 2.0 BLE eventually, which I believe has PowerUp devices...

Edited Sunday at 06:51 AM by Bliss

[Wapata]

[Toastie]

2 hours ago, Wapata said:

But the rubber part make soooo much ohm differences that it could not work great

I totally agree, this is unfortunate. I had hoped for a true metallic switch ... 

Well, nevertheless, thank you so much for the very nice photographs!

Best
Thorsten

1 hour ago, Bliss said:

I might add support for  the WeDo 2.0 BLE eventually, which I believe has PowerUp devices...

Phew, now it is getting ever more complex.

These are rather modern devices and the current LEGO apps should (still) do it, right? LEGO support is supposed to fade out (as per other threads here), people are already rather frustrated about that, but I personally am much more interested in getting the vintage (i.e. pre-NXT) LEGO controllers into modern world. 

With the BLE connectivity and the LWP3.0 protocol published some years ago, things really go crazy. I have implemented BLE/LWP3.0 connectivity in VB6 (some years ago n!software gave me their 2016 VB6 BLE stack for free). But then we are leaving vintage territory entirely?

Best
Thorsten  

[Wapata]

I'm an early follower of the topic but even me need a manual.

Could we make a wiki one so everyone that know what he do can write down stuff, practical examples with attached program and screenshot?

In the example section I will put programs to test input and output of devices I own for instance.

[Bliss]

Do 

17 hours ago, Toastie said:

But then we are leaving vintage territory entirely?

No, it's a reunion!

We can now make projects where we the vintage is mixed with the newer devices...

I can use a Touch sensor on int.A to activate a motor on WeDo usb hub.

The WeDo 1.0 is almost vintage by the way.  I found after many searches a python support for it and it was not easy to make it work because, I installed the pyUsb library but it was not enough as the USB driver for WeDo 1.0 is not following latest USB requirements.
Windows reconizes it as a HID device.   So I had to install libUsb 1.0 separately as a patch to make it work in python...

The goals of Lego Blockly web app:

• Allow MULTIPLE  vintage or retired devices to be programmed in a same environment and be used in a same program.
• I do support old smart PBricks like RCX/CM and maybe I will support recent Smart brick but mostly for the messaging capability to be able to interact with those.
  Because one of the main goal here, is to provide an intuitive programming environment for PASSIVE or BRAINLESS lego devices like Int.A, Int.B, WeDo and even Boost!

I know some other platforms like Scratch or Snap! might support the WeDo 2.0 and Boost (not sure though), but those are not supporting vintage.

 

17 hours ago, Toastie said:

Phew, now it is getting ever more complex.

Not at all, it is the same set of basic instructions, loop, task, If, variables, wait, etc... for all devices.
You don't own or don't need a particular device in your project? Just don't use it.  I would not call it more complex.
 

17 hours ago, Wapata said:

I'm an early follower of the topic but even me need a manual.

There is a small Readme file if you follow the Source link but it is very basic and incomplete.

I will probably document it more eventually.

For the moment, I use Eurobricks to explain and answer questions.  (I have a feeling that you, GUYS in this thread, are the only users/helpers/testers for this project ;-) )

For learning blockly, You can find many tutorials and videos.  The best is to try it, test it...

This web site is fun to learn for example:  https://blockly.games/?lang=en

Lego Blockly has some custom blocks that might need more explanations and testing though, like the tasks, one shots, etc... and concept like Blocking inline programming vs multi tasks and non blocking programming.
Which I explained a bit in previous lost posts :-)

I'm in my coding phase at the moment, but will try to document more one day :-)

EDIT:  If you hover your mouse on some blocks, there might be tool tips!!!

Edited Monday at 02:20 AM by Bliss

[Wapata]

8 minutes ago, Bliss said:

(I have a feeling that you are the only users/helpers/testers for this project ;-) )

Of course no  without you and at least 3 other people here I won't be able to make anything. So no. 

That said, it's purely a chance factor a interface-B was offered to me last month, and I've got my CyberMaster 15 days ago. I've only finished to make a win98 computer inside my Linux laptop right now, to make the models and program them.

...

.. and I have a second CyberMaster (without tower) since yesterday to continue using Blockly 

And I'm divorced and starting my 40 crisis, that's why I've looked for CyberMaster at first and why I've some time before and after work to try your new stuff.

That said, without a manual, a new coming reader will be afraid to read the whole topic. And your are not alone to write it the day you want to ! Isn't some wiki stuff inside GitHub for that purpose by the way ?

[Bliss]

6 minutes ago, Wapata said:

Of course no  without you and at least 3 other people here I won't be able to make anything. So no.

Sorry, I edited, I did not mean only you, I meant all the folks following this thread :-)

Yes there is a wiki section in the Github that I do not master yet and as I said, I'm more focus in the coding for now.
I would like eventually to have a HELP link in the footer bar...
If some of you want to contribute to documentation, feel free to raise your hand :-) 

[Wapata]

8 hours ago, Wapata said:

But the rubber part make soooo much ohm differences that it could not work great

It .. it ... It work flawlessly 

And finally it's super logic: the resistor "short" the button. So the red button look like it's 12ohms inactivated and "0ohm" pressed.

[Toastie]

30 minutes ago, Wapata said:

And finally it's super logic: the resistor "short" the button. So the red button look like it's 12ohms inactivated and "0ohm" pressed.

That's crazy - is it really close to zero Ohm when pressed? That is hard to accomplish with these rubber type switches ... but well, so be it.

Here is a website that talks about the Cybermaster switches (this particular webpage seems to be from around 2003/4 according to the pictures uploaded to Brickshelf, the site was not updated after 2006 I believe)

http://www.teamhassenplug.org/robots/fullcontact/ scroll down to "How it works".

Thanks for sharing!
Best
Thorsten

 

 

[AJB2K3]

@Bliss As you have now noticed, the Wedo 1.0 is not a USB Serial device but a HID device which overrides the need for a driver and so you need the lower lever python to control it.

The tilt sensor is not a true analogue device, it will only return 4 different values.

As to the Switches, they are all "Analogue" as you have said. they all will return a variable result.

Now for identification you have to be careful as if you connect multiple in parallel the initial non pressed reading value goes up because resistors in parallel have a reduced value.

Half the value of R1 + half the value of R2 and so on even for the grey buttons

 

[Toastie]

6 hours ago, Bliss said:

Because one of the main goal here, is to provide an intuitive programming environment for PASSIVE or BRAINLESS lego devices like Int.A, Int.B, WeDo and even Boost!

Ahh - I am a slow learner!

I looked up Boost and WeDo 1.0/2.0 - and they are in fact brainless! May they be called modern incarnations of interfaces A/B? So in fact, that makes a lot of sense!!!

When it comes to the PUp hubs (City, Technic, Move, Inventor, Prime, and Essential), PyBricks is using their own firmware on the hubs, and then they do Python or Block coding. Will you be looking into that as well? I personally like the LEGO Blockly block much more than the PyBricks blocks, but that is just me. I never used Python. 

Wow, what a totally cool project you have going here @Bliss!!!

EDIT: As said, I am sometimes really slow. In the beginning, I thought: Cool, IntB in modern world. Then came the RCX, and I was puzzled, as it has its own brain. What I missed was: Simply employing the RCX as sensor/actuator - which I initially found disrespectful  as it >has< a brain - to interact with e.g., IntA's outputs using the same UI is absolutely novel. I grew up and thus was confined to this "1:1 computer program-interface world" - which is now turned upside down. Particularly because one "language" is used for all. And more importantly: With powerful new features. The non-blocking elements are just one breathtaking feature!    

Well, I am all excited about the true vintage stuff - but as you said, just don't use what you don't want to!

All the best
Thorsten

 

Edited Sunday at 08:18 PM by Toastie

[Mr Hobbles]

This is such a cool thread to find, a really cool project you're working on @Bliss! Kind of an alternative to the https://code.legoeducation.com/ canvas but for supporting as many devices as possible. I've been working on my own project in a similar vein, but based around reviving Logo, not doing visual/block programming (but I won't talk about it in this thread, this is about your project!). It's great to see a revival of old hardware - I think there's been a great effort lately with regards to bringing back obsolete devices.

Also, I just learned about Cybermaster. :) I mean, I knew about it previously, about 20 years ago, but it skipped my mind, and I completely forgot about it. Such a cool device, and a big improvement over the IR communication of the tower<>RCX. But, a different usecase I suppose.
 

Quote

I looked up Boost and WeDo 1.0/2.0 - and they are in fact brainless! May they be called modern incarnations of interfaces A/B? So in fact, that makes a lot of sense!!!

@Toastie Yes, exactly this. :) The WeDo 1.0, WeDo 2.0, Powered UP, Control+, SPIKE Essential, and even SPIKE Prime (after the firmware update that enabled LWP3) can also be considered Interface's, since they have no brain, and use computer control.

Though, I consider the Raspberry Pi BuildHAT to be the true official Interface C. :D https://www.raspberrypi.com/news/raspberry-pi-build-hat-lego-education/

[Wapata]

14 hours ago, Toastie said:

was puzzled, as it has its own brain

I think I will use that to program stuff into the brick but use the sensor "telemetry" to interact with other stuff. 

9 minutes ago, Mr Hobbles said:

big improvement over the IR communication

Well... If two meters is an improvement. The range is not good... But the communication is a two way communication.

[Mr Hobbles]

13 minutes ago, Wapata said:

Well... If two meters is an improvement. The range is not good... But the communication is a two way communication.

Ah, I was expecting it to be longer than that!

Well RCX has two way communication (IR sensor readings, command replies, etc), but I assume latency via RF is a lot better than IR latency... or at least, I'd hope so...

[Bliss]

2 hours ago, Mr Hobbles said:

I've been working on my own project in a similar vein, but based around reviving Logo, not doing visual/block programming (but I won't talk about it in this thread, this is about your project!).

I think you should talk about your project here.
Or if you make or have another thread about it, please let us know (give the link here) as I and many others would be interested!

The Blockly project takes a lot of place here these days, but before that, it was python modules, C# project EXE etc...  And there is another thread for Using Interface B with micropython on ESP32 etc...

The thread here is more general about any software that would allow to program the retired (and maybe eventually, the more recent bricks...) I/O bricks (Brainless) on modern computers.

I'm glad you found the thread and looking forward to hear about your project(s) about Logo!

Edited Monday at 12:05 PM by Bliss

[Toastie]

10 hours ago, Mr Hobbles said:

Powered UP, Control+, SPIKE Essential, and even SPIKE Prime (after the firmware update that enabled LWP3) can also be considered Interface's, since they have no brain, and use computer control.

But wait:

• PoweredUp (PUp) is a LEGO hardware series using the BLE based LWP3.0 protocol for data transport
• Control+ is an app for PUp
• SPIKE Essential and SPIKE Prime are hardware hubs within the PUp hardware series

Is that correct?

The hardware hubs within the PoweredUp hardware series are the

• City hub (2 PUp ports)
• Technic hub (4 PUp ports) along with tilt sensor
• Move hub (2 PUp ports) along with tilt sensor and 2 built in motors w/ tacho
• Robot Inventor hub (6 PUp ports) and other things?
• SPIKE Prime hub (6 PUp ports) and other things?
• SPIKE Essential hub (2 PUp ports) and other things? 

(other things may be light, tilt, sound etc.) Correct?

I just want to get the nomenclature into the clear ...

In reference to the PyBricks website, all the PUp hubs have RAM, ranging from 16k (Boost) to 320k (Prime/Inventor) for storage of programs, data, etc. I also assumed that when these hubs are flashed with the PyBricks compatible firmware, they are programmed using the PyBricks UI/software and then operate autonomously? I.e., have a brain? Is that not so?

Man, this is getting so confusing.

All the best
Thorsten

 

Edited Monday at 07:07 PM by Toastie

[Mr Hobbles]

47 minutes ago, Toastie said:

But wait:

• PoweredUp (PUp) is a LEGO hardware series using the BLE based LWP3.0 protocol for data transport
• Control+ is an app for PUp
• SPIKE Essential and SPIKE Prime are hardware hubs within the PUp hardware series

Is that correct?

* Powered UP, Control+, and SPIKE are LEGO product ranges
* Powered UP, Control+, and SPIKE are also the names of apps of those respective product ranges
* The hardware family for all this is most commonly known by the community as Powered UP, however LEGO calls it LEGO Power Functions 2.0
* The hubs all speak LEGO Wireless Protocol 3.0 (except the WeDo 2.0 hub, which speaks it's own dialect

LEGO made it confusing for sure. You may be over thinking it though. It's just all one big homogeneous blob of devices. :D

47 minutes ago, Toastie said:

In reference to the PyBricks website, all the PUp hubs have RAM, ranging from 16k (Boost) to 320k (Prime/Inventor) for storage of programs, data, etc. I also assumed that when these hubs are flashed with the PyBricks compatible firmware, they are programmed using the PyBricks UI/software and then operate autonomously? I.e., have a brain? Is that not so?

Yes, this is very true, Pybricks muddied the water by giving all those previous interfaces a "brain". But, as LEGO intended them, they are dumb interface devices, using a computer (a phone or tablet with an app) to interface with motors or sensors.

But really, any microcontroller with a bit of storage is a brain with the right firmware!

7 hours ago, Bliss said:

I think you should talk about your project here.
Or if you make or have another thread about it, please let us know (give the link here) as I and many others would be interested!

The Blockly project takes a lot of place here these days, but before that, it was python modules, C# project EXE etc...  And there is another thread for Using Interface B with micropython on ESP32 etc...

The thread here is more general about any software that would allow to program the retired (and maybe eventually, the more recent bricks...) I/O bricks (Brainless) on modern computers.

I'm glad you found the thread and looking forward to hear about your project(s) about Logo!

Well, if that's so and you don't mind, I've been working on BrickLogo - https://github.com/openbrickproject/BrickLogo/

It's an attempt to bring LEGO/Logo (LEGO TC Logo/LEGO DACTA Control Lab Logo) kicking and screaming onto modern computers, and supporting LEGO hardware both new and old, but with all the fun of Logo! And hopefully it's familiar to those who've played with Logo for those devices in the past.

You can either type directly into the REPL and execute line by line (similarly to the original), or write .logo files in your IDE of choice (ie. VS Code) and execute them through the bricklogo CLI.

It's compatible with Control Lab, RCX, WeDo 1.0, WeDo 2.0, Powered UP/Control+/SPIKE, Education Science, and the Raspberry Pi Build HAT.

It's built in Rust and intended to be a single compiled binary/exe that you can run in the command line or terminal without any dependencies needing installed. Windows, macOS, or Linux (Raspberry Pi). https://github.com/openbrickproject/BrickLogo/releases

There's some docs here - a small tutorial, a language reference guide, and a start at some info on some of the more advanced parts - networking, using multiple devices/hubs/interfaces, executing scripts, etc.

https://github.com/openbrickproject/BrickLogo/tree/main/docs

Maybe we can take inspiration from each other for Blockly and BrickLogo!

Edited Monday at 07:54 PM by Mr Hobbles

[Toastie]

2 minutes ago, Mr Hobbles said:

But really, any microcontroller is a brain with the right firmware!

That is absolutely true!

It also depends of course on the brain size before calling it a brain (oh my, that does not make any sense :D)

What I mean is the flexible part of the "brain". The Scout PBrick for example has only 396 bytes of free RAM, but a rather large size of ROM with built-in routines. Which can be (very) favorably used for programming, i.e., making efficient use of the available RAM. The ControlCenter MC can store some 50 programmable steps in addition to delays, which is, for 3 on/off limited outputs and no inputs, quite the range.

12 minutes ago, Mr Hobbles said:

You may be over thinking it though

Yes, that's me. PChemist here. Always trying to get messy chemistry "organized" ... 

14 minutes ago, Mr Hobbles said:

But, as LEGO intended them, they are dumb interface devices, using a computer (a phone or tablet with an app) to interface with motors or sensors.

Ahh - now it all makes sense. So it was PyBricks causing my confusion. Thank you very much for making that go away!

Wrapping-up:

• In the beginning there was the word (we need to start somewhere)
• Then Interface A came to existence. It is a passive output driver, and passive sensor data provider. It needs an external computer to close the sensor actuator loop. 
• Control Center I (II) appeared, representing a programmable system (time and outputs on/off) using the built-in keys. No computer required, nor possible.   
• Interface B followed, which is a passive output driver, and an active sensor/status data provider. It requires an external computer to close the sensor actuator loop.
• Code Pilot came to existence: As Control Center, it is programmable, but using LEGO's optical VLL communication protocol. Has a sensor, reacting to light changes. It can record time and output, and react to light changes. 
• And then everything changed with the introduction of the "original" Mindstorms PBricks: CM (RF data transport), RCX, Scout (IR data transport), Spybots (VLL data transport): They are supposed to be programmed and then operate autonomously. Diverse external and internal (Scout, Spybot) sensors available. All operating within the 9V power system. 
• At the same time, MicroScouts surfaced, which are VLL devices, having a light sensor and a built-in motor. They are essentially an addition to the PBricks, particularly the Scout and Sypbots as these natively speak VLL. But can also be programmed and operate autonomously.
• What followed was the NXT and EV3 Mindstorms PBricks (BL links), another line of true PBricks.
• And then we reenter the dumb device era, call it WeDo, PUp, as I understood, see above.

With taking the risk of overthinking again (as said, I am really good at this) - does that sound OK?

All I want to accomplish is creating some sort of "frame" for me (and probably for @Bliss beautiful LEGO Blockly approach).

In the >original< LEGO universe, as I understood what you were talking about, @Mr Hobbles, in this line-up of LEGO "interfaces", the "true" PBricks, CM, RCX, Scout, Spybot, NXT, EV3, were meant to be on their own after programming. Whereas "everything else" is talking to an external computer to operate appropriately.

Is that sort of reasonable?

All the best
Thorsten

 

 

 

11 hours ago, Wapata said:

Well... If two meters is an improvement. The range is not good... But the communication is a two way communication.

Hehe - that is why I made my own RF2IR stuff, back in 2011 

https://www.eurobricks.com/forum/index.php?/forums/topic/62616-extending-ir-range-with-rf

10+ meters! No line of sight.

Best 
Thorsten

 

[Bliss]

5 hours ago, Mr Hobbles said:

Maybe we can take inspiration from each other for Blockly and BrickLogo!

Wow, that quite a project!
And great documentation.  Looks very professional! 
And lots of great features like mutli-devices support, Tasks support, Some kind of intercommunication between different instances of LogoBlock running on diff computer on the network...  Etc... 

I will certainly look into your code for the other protocols I did not implement yet and I might find some ideas too like your documentation structure...

I don't know much about logo, but that reminds me of this LogoBlocks I found while I was searching the net for info about RCX etc and it seemed cool:
https://web.media.mit.edu/~calla/Worshops/LogoBlocks/LogoBlocks-Ref-EN.htm

But this seems an abandonned project...

 

[AJB2K3]

@Mr Hobbles PF2 was lego's internal name, the range was branded as PoweredUp! hence why the community refers to it that way.
I gave up on my blockly version as @Bliss is making a better version.

[Mr Hobbles]

4 hours ago, AJB2K3 said:

@Mr Hobbles PF2 was lego's internal name, the range was branded as PoweredUp! hence why the community refers to it that way.
I gave up on my blockly version as @Bliss is making a better version.

Yes, from a product perspective, the range is branded as Powered Up, but the devices are officially called LPF2 (and Powered UP as a product range name was introduced later!) You can see LEGO using the terminology in various places. I remember when Lego changed it, we were discussing it in the thread in the train forum on here back in 2017 and there was lots of confusion lol.

https://assets.education.lego.com/v3/assets/blt293eea581807678a/blt23df304b05e587b2/5f8801ba721f8178f2e5e626/techspecs_technicforcesensor.pdf?locale=en-us
https://education.lego.com/en-us/product-resources/wedo-2/troubleshooting/faqs/

But I digress!

@Bliss Thanks for the kind words. I wanted to try to make docs as clear as possible, as not many people remember Logo I'm sure. :D

I intentionally kept networking simple - replicated global variables. So you can set a variable based on sensor readings on one machine, and waituntil it becomes a certain value on another machine. I'm trying to keep it as OG Logo-like as possible. But it also means you can build other clients, ie. browser applications with websockets, and read/write those variables, to build UI's etc - it is quite a simple JSON based protocol.

It would be awesome if Blockly could interact with the outside world too! MQTT publishes or something? Or allow websocket client connections to a server? You could even have Blockly and BrickLogo talking to each other. 



 

[Bliss]

5 hours ago, Mr Hobbles said:

It would be awesome if Blockly could interact with the outside world too! MQTT publishes or something?

I wanted to implement MQTT and there is still trace of it in my code but I put it aside for now since my project is an installable web app working with https server side (using the github pages as you can see) and this requires a more secure MQTT setup...

Using https means more security and it requests using TLS with MQTT and max security with MQTT which most people did not setup at their homes as it involves certicates etc... 
It's feasible but in my book, it's not simple enough and one of my goal is to keep it as simple and intuitive as possible which is already not obvious to achieve...

 

Edited yesterday at 03:34 PM by Bliss

[Mr Hobbles]

2 hours ago, Bliss said:

I wanted to implement MQTT and there is still trace of it in my code but I put it aside for now since my project is an installable web app working with https server side (using the github pages as you can see) and this requires a more secure MQTT setup...

Using https means more security and it requests using TLS with MQTT and max security with MQTT which most people did not setup at their homes as it involves certicates etc... 
It's feasible but in my book, it's not simple enough and one of my goal is to keep it as simple and intuitive as possible which is already not obvious to achieve...

 

Yep definitely, MQTT is a complex beast, and running into a browser means you're limited to websockets or HTTP fetch. That's the reason I chose websockets for BrickLogo's pipe between nodes, as browsers can join too. I haven't bothered with wss (yet) - I figure most people are gonna run locally rather than over the internet, and wss setup comes with headaches for end users (certificates, needing to launch HTML files from a server instead of from disk, etc).

End user friendliness definitely the end goal. Though, its nice to have some more complex functionality for those who need it!

Great project, I look forward to playing with it more. :)

[Toastie]

@Bliss

My Unos, Nanos, and Megas resurfaced :D

Quick question, as things in this thread are progressing with a pace close to light speed ...

Is this list for the usage of an Arduino Uno (clone ) along with your Github Uno sketch for IntA control still correct?

• Target: Arduino Uno (with regard to pin usage)
• Baud rate USB computer <-> USB Uno = 19200 (for programming)
• Data connection USB computer <-> Uno: USB2TTL adapter on pin 0/1 of Uno (or does this now go through Uno's USB connector directly?), Baud rate again 19200
• Uno pins 3,5,6,9,10,11,A0,A1 to IntA connectors 6,8,10,12,14,16,18,20  

Thank you very much in advance!
Thorsten