Toastie

I believe this is less of a tendency but rather mostly the case. In the world of so-called developed countries. Partly at least. Let's make that "hopefully". (Well, there are many, many countries in this world, where kids do generate income - for the family. But in most cases they are not that much into LEGO. More into food and the like) I look at the XY+ number solely from the money perspective. As @JintaiZ has outlined. I believe that there is no set that needs to be 18+ - building skill wise. None. Best Thorsten

Uhmm - yes. See here: And here is a detail: Best Thorsten P.S.: The sensors I am using just "snap in" between the rails after very little filing at the short ends. Their PCB is then almost level with the sleepers. Can show details, if you wish.

Did you try out one of these (or the like, TCRT5000 based): https://eckstein-shop.de/TCRT5000-IR-Barrier-Line-Track-sensor-Infrared-Reflective-Photoelectric-Switch ? @GianCann also used them without the additional electronics, I believe. With the additional electronics as shown in the link you can dim down the sensitivity to about 2 cm or even less. The only downside is very bright (sun) light as they sometimes falsely detect that as reflected IR. I am using four of those without any glitch so far. They also point upward, 2 cm range, so that hardly anything other than a train is detected. Best Thorsten

Ahh - this is about money. Yes I am getting it now. Thanks for clarifying! Regards, Thorsten

@JintaiZ the link to the 19 sets is https://0.0.0.19 - any chance to point to the 19 sets? Also, with regard to your 4 poll entries: Does 18+ mean $$$, 16+ mean $$? Or are there other criteria to decide? Best Thorsten

Hi @jpx, I do like it very much, it is really recognizable - and what I find particularly intriguing is that it is an electric vehicle - very nicely blending into the conventional Speed Champions car series. And even more than that: A fuel station that is not providing conventional fuel but electricity. Wonderful. Thank you for sharing! All the best, Thorsten

@Venderwel I guess this is very nicely explained by @Lowa on their website. Also, what kind of sensors/actuators are you planning on using? I bet you said that somewhere here - but this thread is becoming long. And it is getting like a moving target as there are so many options and pathways to follow. I believe what @DGoSec is pointing to is also very powerful. However, there should be a well-thought-out way of how to accomplish your goals. I remember that the degree of complexity will be high - at least too high for me. In this case I'd decide first: Control from a desktop/laptop with maybe even 2 screens? Then the number of trains, switch points, other things to control comes into play. And then: Will it be all LEGO? All based on PUp or mixed, e.g. PUp and PF, PUp and EV3/NXT, Spike or not. This all counts in. All wireless, or both? WiFi, BLE, BT? Or all? The ESP32 nodeMCUs talk it all ... With nControl you can customize your layout using LEGO as well as other hardware, including your own home-brews. Distributed intelligence, as @DGoSec is mentioning (one RPi controlling/managing numerous Arduinos for example (or ESP32s ore ESP8266s). What I like most though is to have the layout as integral part. (I am happy to share any code I have. Thing is the Laptop all that stuff is on, is waiting to be picked up by Dell. I dumped as half glass of wine over it. It went dead and then began to develop bad hot electronics smell accompanied by some smoke. A quick inspection indeed showed burnt electronics ... I am now on my old laptop) Also @Lowa was very responsive when I began fiddling with nControl. I bet you can ask them specific questions and will get very helpful replies. All the best Thorsten

I believe this is a message type rather than a command, isn't it? 05/00/MessageType/ and then it becomes specific to the type. 0E is not documented - as a good bunch of other things. At least not in chapter 3.3 "Message Types" (Hub and port related). The LWP3.0 document was outdated the day it was introduced as it is always with evolving software/firmware - when not updating the document. Which hasn't been done. As far as I can tell also the "new" motors (e.g., PUp L) are not in the device list etc etc. Best Thorsten

So n -> infinity, but sum over F(n) does not? We should also count in the first and second law of thermodynamics, I suggest. Otherwise, a great number of folks in the graves will stand up tonight and get us nightmares. Best Thorsten

If you guys see fit, I would also like to participate. My contributions would be more on the non-LEGO-electronics/programming-for-LEGO-stuff-side though. May well be that this is not appropriate! Best Thorsten

I fully agree on that. The tile based programming is a blast. While you build your track layout you are getting already programming functionality for each tile if you wish. Custom controllers can be seamlessly integrated. It is fantastic! Best Thorsten

@Venderwel As we are discussing Arduino+train related ideas, questions, solutions in your very thread (and let me know if this is not OK!) ... another thought: Coming from the LEGO PBrick world (RCX, NXT, EV3), all of these allowed "parallel" processing. Let's put it this way: You can start multiple tasks at any time. This is extremely powerful when running microcontrollers taking care of more complex tasks. The Arduino IDE does not per se allow you to do that. Thus, as with all "mainloop forever" programming, diverting away from the main loop needs to return control to this loop after branching off. I found that rather challenging as the LEGO PBricks simply allow you to startup several tasks and all you have to do is synchronizing then using state variables/functions. There are solutions to that "challenge" out there (i.e., quasi parallel processing) for Arduino. I never tried them but rather like the idea of coping with a single forever loop, and branching off to "local loops" eventually returning control to the main loop. Maybe others have other experiences! If so please share. Best, Thorsten

Class one. They use it in the generic distance sensors (HomeDepot etc etc.). There is another variety that goes up to 4 m. Wait: You mean terminal session, right? As in: Arnold S. is sitting in front of a DEC VT100 terminal hooked up to a PDP11 and watches the numbers (in mm) coming up, correct? UART = Serial??? The video suggests that you can do RX/TX or I2C. Is that so? It would be convenient! I will order a couple of these right away. Again: Thanks for sharing! Best Thorsten

WOW - this is really nice. This is really really nice as its eliminates so many obstacles - ambient light issues, fluorescent light issues (overtones etc.), LED light issues (same thing, they sometimes behave as were their main task to securely terminate any radio traffic within a range of meters ). Any chance to explain what the sentence above means in laymen's terms? Let us assume an Arduino or ESP ... and now what? WAIT Found this: Man. That is so cool. Thanks for sharing!!! Best Thorsten

I was surprised myself. It all looked good on breadboard. Putting it into a box ... the display needs an offset from the PCB, the LEDs a different one, the keys as well. And then you need power, and so on and so forth. In the end though there is a dedicated BLE LWP client - resembling a remote control - for only one specific scenario and one specific PUp hub. No smart device, no screwing up on a touch screen ... just bold old school buttons, a nifty display (that one is fun!) - and - well - some soldering. The whole thing including sensors clocks in with 30€ - which is not that bad. Thanks for your kind words! Best Thorsten

BTW - had to migrate to my old Dell Precision M4700 because I dumped some white wine on my Dell 7530 ... cat1 (brother, Romeo) was chasing cat2 (sister, Giulietta) like crazy, I exploded from my chair, so did the white wine, all over the keyboard, a blink later it went dead and a moment later there was a weird sound accompanied by bad smell ... How-ever ... installed all the updated Arduino stuff along with ESP32 etc etc board managers: Compilation for ESP dev board goes much faster, upload is smoother and faster as well. It is all a matter of tens of seconds. Best Thorsten

@Lok24 Thanks a lot!!! Best Thorsten

If you are running Windows, it tells you the device address when you search for new devices upon "pairing". Best Thorsten

Very nice!!! Now, I have a question for you, @GianCann and @Lok24: The Legoino library does not (yet - Cornelius will work on this he said though) support the LWP "StartSpeed" sub command (0x07/0x08) of the output command 0x81. The 2I/O hub supports that - as well as it allows defining "profiles". As I will not have access to my VB6 programs for some time, where I used already the LWP StartSpeed (Speed, MaxPower, UseProfile) command with MaxPower 100(%) and UserProfile = 0 (no profile), I can't further investigate this right now. The PID controlled speed setting works >really< nice. You set speed to 5% and the hub will control the PUp L-motor to do exactly that. The Crocodile and any other PUp L- or the like motor (but not the train and M-motor) propelled train can be speed-controlled in a very nice fashion. What I like most about this mode is that trains don't slow down in curves and can be reliably operated at very low speeds. Question is: Once I have defined the profiles in the hub, lets say "slow acceleration" as UserProfile 0 and "fast acceleration" as UserProfile 1 do these stay in the hub's memory or do I need to define them every time I turn on the hub? Thanks in advance! All the best, Thorsten

David, this is ingenious. You guys are simply beyond belief. Thank you very much for sharing! Best regards, Thorsten

Dear All, the Crocodile (#10277) made me change my mind: Before knowing about the set, “no more trains” due to “no more space” on my layout was directing me to other LEGO related activities – mostly concerned with improving things on the layout. Which is – hmmm – nice but … So 10277 was announced and it was 2 minutes after it appeared on the German S@H website that I ordered it. It arrived 2 days later and was built the very evening. Folks on EB and elsewhere reported way earlier on improvements – I copied that and added my own ideas. So the Croc was there, now it needed an appropriate display – with no space on the layout … Solution: Mount some track to the wall (https://www.eurobricks.com/forum/index.php?/forums/topic/179240-mod-10277-and-on-and-on-another-crocodile-mod-%E2%80%A6/). Used my cell phone to make it go back and forth, thought about automation. And then Cornelius Munz’ Legoino software, which allows connecting to and control PoweredUp (PUp) servers (my understanding is: currently the 2I/O and the Boost hub) got me all excited. The hardware platform supported is the ESP32 line of devices. Several solutions have been already presented here on EB in the Mindstorms forum and elsewhere, sorry for not providing references here. My take on learning that ESP32 boards can connect and control PUp hubs was: They cost less than 10 € a piece, have ample of memory and – coming from the “3(+) inputs/3(+) outputs” world of LEGO intelligent bricks (RCX, SCOUT, NXT, EV3) as well as PUp (4 Control+/6 Spike) – there are almost “uncountable” I/O pins on these boards. Make it 20+, depending on the board. In conclusion: One dedicated ESP32 board for one single PUp hub is hardly affecting my LEGO budget … and no cell phone or tablet device is required at all. And here we go. The idea is: The Crocodile goes back and forth on elevated track mounted to the sloped ceiling of my room. See above link. The endpoints are defined using sensors, otherwise timing errors may add up – and a crash at about 1.5 m height may result in severe damage … There should be a defined acceleration and deceleration phase – and not just full blast ahead and full stop at the distant and close terminal. One possible solution is: 4 sensors are detecting the position of the Croc: Endpoint right, endpoint left, deceleration points in between. This is what I have implemented in terms of a stretch of track consisting of curved and straight tracks to show the Croc’s abilities, and a C/C++ program using a jOYiT ESP32 nodeMCU (with 30 pin GPIO exposure), four line-tracking TCRT5000 based sensors from keyes; looking upward from the track sleepers, the Arduino IDE, the ESP32 libraries/programmers for the IDE, Cornelius’ Legoino libraries to access the 2I/O hub of the Croc, a small 128x64 OLED display from jOYiT to show the status and what is happening, the Adafruit libraries for the display, and four push buttons: Go left, go right, start/stop, emergency. Solution/workflow: Power-up ESP32. Wait for Croc’s 2I/O hub to be turned on. When not at “initial” Start/Stop position (i.e. at right sensor), use the Left/Right buttons to locate the Start/Stop position; pressing the buttons move the Crocodile at low speed as long as they are pressed. When the Start/Stop position is reached (i.e., the right detector fires), both buttons are disabled and only the Start/Stop button is enabled – the Emergency Stop button remains always enabled. Press Start/Stop once: Make one return trip. Press twice: Do that indefinitely. The button “surface” shown on the display lets you know the mode: Open circle around Start/Stop: Loop forever; inverse colors (white background/black letters): Loop only once. Emergency button: Full stop (issued 4 times to be sure) and return control to Left/Right manual control buttons until Start/Stop position is reached again. The OLED display further always shows the battery level and the BLE signal strength. That’s it. Here are a couple of photographs (video may follow – but I guess you guys are getting the idea from the images). Crocodile and Controller … it says “Turn on Crocodile” and scans the 2.4GHz radio signals in the room – when pushing the PUp hub’s on/off button, Legoino connects to the hub with the correct ID. The controller’s front panel. Left to right: 128x64 OLED display using I2C communication using only 2 GPIOs of the ESP32 board!), button “Go left”, button “Go right”, button “Emergency”, button “Start/Stop”. The LEDs below the buttons, left to right: “PWM applied when going left”, “PWM applied when going right”, “Emergency (or attention)”, “Running”. The brightness of the left/right LEDs are controlled by GPIOs configured for PWM mode. Top left: Display shows “Locate Start Position”, this means Crocodile’s right rail guard is not aligned with the right stop sensor. Pressing the button "Left" or "Right" slowly move the Crocodile. Top right: Rail guard aligned with the left stop sensor: The display changes to “Start/Stop”. The red “ramp” is for safety reasons only; so far not used once. Upon letting the Crocodile moving onto the ramp at full speed, it slides up and the driving wheel lose contact with the rails. Bottom left: Pressing "Start/Stop" fires the run sequence: Accelerate to max speed with given time intervals, when the left "slow down sensor" fires, decelerate to minimum speed and then stop when the left stop sensor fires. Wait for two seconds, accelerate and do the same thing with the right sensors. Stop at right stop sensor when Start/Stop button is pressed only once, repeat the sequence indefinitely when pressed twice. Bottom right: The LEDs brightness as well as the display values show the current PWM power applied to the motor. Close-up of the sensors used (top) and the Croc's rail guard triggering the sensor. Couple of images showing the brick-built case. Bottom right: I glued a 2x2 tile onto the ESP32 – this secures its position when assembled. Some soldering and mounting details. The sensors need 3 wires: 3.3V, ground, and signal. There is an 8 wire cable hiding behind the track: An USB power supply delivers 5V/GND to the ESP’s "Vin" pin. The ESP in turn delivers 3.3V/GND to the sensors. 4 wires are used for the 4 sensor signal lines. TO-DO: The acceleration and deceleration phases are programmed as a “ramping” routine with defined power step size (5% PWM) and dwell time per step (300 ms). Minimum "moving" power is 25% PWM as the Croc stalls otherwise. Maximum power is 80% PWM. This is OK but not “cool”. Cool would be to program the 2I/O hub upon startup with acceleration and deceleration profiles. The firmware/LWP3.0 protocol allows to do that – but this feature is currently not implemented in Legoino. Secondly, using the LPW “speed” instead of “power” LPW commands would invoke the PID controlled motor operation. I did that already with my VB6 code – works beautifully well: At speed “5” the Croc negotiates the curves and straights at almost constant – well – speed. This is not possible with “power 5” – it just does not move at all. This works of course only with PUp motors with internal rotation sensor – the PUp L-motor in the Croc features that. But again: This is not implemented in Legoino yet. Will be available at some time in the future though! Happy to share code, but this is a (very) “tailored” project. Best wishes, Thorsten.

Yes. It does nothing than counting nanoseconds On the other hand: When your code does not become longer and more complex, nothing is wrong with that. However, when there are a lot of things going on (just imagine you want to detect an asynchronously operated push button, e.g. "BREAK") and many delays are implemented, things may become unpredictable at some point. Best Thorsten

Absolutely! I also like the "last_time = millis()" and "if (millis() < (last_time + wait_time)) {do something else}" approach ... Best Thorsten

That is the way to go. There may be multiple triggers when the train passes the sensor. What I do is branch away from the detection loop when it initially fires - and only return when required or some time has elapsed (not wait/delay, as this stalls the program). Best Thorsten

Yes. And about its functionality: Here is another video explaining it - he does the 1 cm detection approach and "makes" the IR light visible Best Thorsten