That’s a good question - I feel that the ezb v4 with the upgraded communication board is still superior to any other controller. I don’t think they could do much to make it any better. At least without putting Linux on it and competing with Raspberry Pi

Arduinos, esp32, and pis are all the same as they were ten years ago - albeit pis have higher clock speeds since pis run operating systems. As for micros, their usability and feature set depend on the controlling software (i.e., ARC).

That’s probably why the ezrobot controller has proven longevity: the Synthiam software keeps growing and adding more features that extend the lifetime of micros, such as the ezb v4.

Plus, with the new ARC coming out in a few months, that old hardware will get new life. Because the new ARC runs on anything, including Pi’s, those Ezbs v4s will be extra useful. Especially in USB mode!

Hello DJ_Sures,

It's great to hear your insights on the EZ-B v4 and its longevity in the robotics community. The EZ-B v4's continued relevance is indeed a testament to its robust design and the versatility provided by Synthiam ARC's software enhancements. The upcoming ARC release sounds exciting and promising for breathing new life into existing hardware.

Regarding the potential development of an EZ-B v5, it's understandable that with the current capabilities of the EZ-B v4 and the advancements in Synthiam's software, there may not be an immediate need for a new version. However, the robotics and maker community always looks forward to innovations that can further expand the possibilities of robot building and programming.

If there are any updates or plans for new hardware like an EZ-B v5, it would be great to hear about them from Synthiam or EZ-Robot Inc. directly. Until then, it's reassuring to know that the EZ-B v4, along with Synthiam ARC, continues to be a powerful combination for robot enthusiasts.

Thank you for sharing your thoughts, and we're all excited to see what the future holds for Synthiam and the world of robotics.

The EZ-B v4 is my favorite board. However, it is expensive. The IO-Tiny is a close second but the speakers snap within a few months and again, I love the EZ-B v4.

The convenience of the ezb v4 is where it shines for sure. You don’t have to worry about a firmware. It’s WiFi or usb enabled. It streams video AND audio with zero latency. I think the most convenient part of the v4 are the 3 pin servo connectors. And up to 24 servos. So you just gotta plug a servo in and it just works. No messing around with firmwares and programming and shields and wiring and soldering and and and :)

Having an ezb with a builtin arm cpu thags could run the new ARC in the robot is a neat idea but not cost effective. Mostly because there’s already many Linux based sbc’s out there that are competing with each other - such as the pi. So I think it’s fine that ezrobot doesn’t make a new ezb that competes in that area. Because if someone wants an embedded computer in the robot, there’s plenty of options that compliment the ezb v4

i rarely use ardunio ezbs - I think mostly because there’s no video, no audio and most importantly, no servo connections without bulky shields.

@Winter I'm sorry to hear about the IoTiny speaker wires breaking. They are a thin gauge. I will see if there's something I can do on the manufacturing side to make them less brittle. I can suggest you that you can place a dab of hot glue or silicone on the wires before they break to help with longevity. They can be soldered back on if they do break, you just need to scrape away the black silicone in order to access the speaker pads.

Thank you for choosing our robot controllers, we really appreciate the kind words!

Hey Jer late Happy New year! Just want to say I absolutely love the EZ Tiny ,I will be buying more of them this year. the one I had really lasted a good long time even with abuse of connecting too much voltage and short circuits. Well designed for sure! They are so convenient in that small size to fit in any robot or even projects in the dash board of my classic sports car! Now with 3 operations in hospital done to my knee and foot, I have a compact 3 wheel disability scooter that lets me boot around inside shopping malls and grocery stores since the balance for my walking is completely gone.( I walk just like a slow robot now LOL!)Anyway I will even add the EZ Tiny to that scooter for various functions such as a killer stereo system with my entire library of music and a great lighting show for night times! Auto drive and make it like a mini Tesla car. So many possibility with it. Hope you guys keep making these for many more years!

Roborad that's awesome you have a scooter - can't wait to see you hack it! Auto drive navigation would be amazing. Asleep at the wheel "Scooter take me home" haha i love it

Ha ya DJ at the cottage would be great with full lighting at night after some of those late night parties trying to get back to my cottage in pitch black night, Robo scooter can automatically drive back to my place and even if I am half passed out with a beer in my hand. Hell ya!

If there was going to be an EZ-B V5 curious what features people would want.   Bluetooth would be nice for audio and control as well as stereo speakers. Aux In or Mic for Microphone would also be helpful.   USB C for power and data so direct connect to a PC would not require FTDI Serial thingamijig and also provide ability to connect USB devices like a regular camera.   If the new version of ARCx can run on anything an on board ARM chip and RAM able to Run ARC would be even better (or would this just be an EZ-B Pi HAT)

what would you want on an EZ-B V5

@Nink. I love all your choices for a new EZB. If something like that would be built into the current EZB platform it would be a dream. I wonder how big the boards would have to be to incorporate all that? I'd be willing to buy something bigger but others that build small robots would probably have a hard time fitting it in. Price would also be a consideration. The current EZB is pertty expensive compared to other controllers. Don't get me wrong, I truly feel that the EZB is worth every penny and several cuts above every other controller available.

To answer your question, I've always thought that a jack to send unamplified sound out to an external amp is a much needed addition. I feel at the very least this jack would need to be added to any new version of the EZB. After soldering many of these jacks to a lot of the current EZB's over the years I don't think it would take much effort or money to add this jack to a EZB-V5 if it were made.

If there were to be an EZ-Bv5, I would want it to be backward compatible with robots running off of the previous  EZ-Bv4. Maybe have two camera ports, four i2c ports, and expand on possible servo ports. Also, have a design on the back to commemorate the iconic EZ-Bv3.

Some may have already mentioned this. I would like a microphone to be put on the board and a way to connect a more powerful speaker. Also, during start-up, the board speaker can be too loud. Maybe make a slider to control the volume.

Also, despite the IO-Tiny board speaker failing, the IO-Tiny is still a great option for builds that don't require as many servos or i2c ports.

DJ, will the new ARC still support EZ-Script? and will the new ARC replace the current or will it be an option? Reason for question is, Do I need to Stop using EZ-Script and convert all my scripts to JavaScript now before the New ARC comes out.

@rz90208, DJ answered this in a different thread. I can't find it right now but the short answer is EZ Script is being taken out of the new ARC. It's not compatible. If you want to use the new ARC you need to convert EZ Script to JS (or Python I think he said). There are a few other things going away also like script migration. You'll need to copy and paste your scripts from old to new. However the old ARC is not going away. It'll still be available for download and use as a legacy program. He didn't say anything about pricing. I don't know if we'll still need to pay to be a Pro subscriber.

Thank you Dave, this is very helpful. I will start converting my scripts over to JavaScript. I should be most fluent in JavaScript by the time I am done as I believe I have close to 80 EZ-Scripts. The Robot uses only a hand full of them.

Both the old and new ARC will require pro subscription. It's still 14 years and 2 million+ lines of code and my blood, sweat, and more tears ha

Oh no! don't kill the old EZ-script. Don't have time to learn a new program, Disappointed at best. I hope it will an easy migration of old to new at least.

@RoboHappy, According to DJ the old EZ Script will be alive and well but only available in the legacy ARC. He says this old version will remain available. As far as migration from ARC to ARCx you'll need to rewrite your EZ Scripts to JavaScript (or Python if preferred?) and manually copy and paste from one version to the other. There is no way to use the "Merge" tool.

It makes sense why Synthiam won't keep EZ-Script.

1. EZ-Robot Inc. and Synthiam Inc. are different companies
2. Synthiam might want to better seperate itself from EZ-Robot more to avoid confusion
3. Python and Javascript are much more common

Also, this might be off-topic, but what happened to the music that you used in some of your earlier videos?

Always did wonder why split from Ez-Robot since he did start that company ( love knowing all the behind the scene secrets  about company's like this) :)

Well, there are two questions there. Hopefully, I'll answer them satisfactorily.

EZ-Script

I created EZ-Script in a way that was based on a need rather than naturally evolving. This is because there was no scripting ability when I made the first ez-builder. Eventually, I needed to add some level of scripting. Initially, there were no IF/ELSE or loop conditions. There weren't even variables. At the time, no prevalent programming/scripting languages were used by people. There was Java, .Net, LUA, and that's about it. JavaScript was limited to the browser, and Python wasn't accepted yet. As time passed, I started "patch-working" EZ-Script to have variables, conditions, and loops. It was the first time I created a "runtime scripting compiler." Because it was native C# and built on something that wasn't meant to be, it was not very efficient. EZ-Builder, now ARC, had many custom hooks and methods to make EZ-Script work. Eventually, not many will remember, but I implemented a c# compiler in ez-builder. It didn't last long because no one understood it.

Fast forward a few years, as I dropped the built-in c#, and suddenly JavaScript and Python began prevailing as the dominant scripting languages. They took over LUA and many others. I'm pretty glad I didn't implement LUA, although we came close a few times. I didn't feel comfortable with it. So, I implemented a JavaScript runtime and then Python. Those two languages were designed to support fast, efficient calls that merged with the ARC built-in functions. Meaning there was no intermediate call between the function and ARC functions. On the other hand, EZ-Script required a lot of intermediate support for every function. EZ-Script took twice as much code to make a single function available.

Because of the tight integration with Python and JavaScript, they started getting new functions in ARC that were fast and easier to use. This slowly pushed EZ-Script further from the platform's inner workings. It made EZ-Script slow and challenging to update. Although EZ-Script did have a few features that both Python and JavaScript didn't have, they were mostly how strings and variables worked. But, those features weren't enough to make EZ-Script worthwhile to continue supporting.

Now we're at the point of ARCx. Many knew it was coming because I hinted a few times that I had plans for a new ARC. The reason is that ARC was 14 years of code, which totaled almost 2 million lines or more. That's a lot of my hard work, which gave you all the ability to do amazing things. But during that time, I took notes of conversations about things you wish it did. Nink was one of the first who mentioned, "Man, I wish the UI was portable." He wanted the UI not to be bound to Windows and perhaps run in a browser. Given that the world is heading that way, it was inevitable. But, as you'll see when you experience ARCx, I did something unique and different by pushing the limits of how a browser-based operating environment would run.

The original plan by Synthiam developers was to make the entire thing run in the browser.  And I wasn't 100% comfortable with that decision. When you close the browser, what happens to your robot project? It stops working as well! So, eventually, Microsoft pushed hard into .Net Core, an entirely new codebase of .Net with fewer dependencies on the older Win32 libraries. This made .Net Core cross-platform (to an extent).

Recently, Microsoft released .NET 8, which has new Blazor functionality; when I saw that, the stars aligned! Suddenly, it came to me. So, I architected an idea over beers with one of Synthiam's lead developers. I told him what I thought ARCx should be (At the time, we called it ARC24 for 2024). But he didn't know it was possible. The team thought there was no way it could be done.

The same day after coming home from those "few beers, " I had a working prototype that evening. I hit a few roadblocks in the following days, but by diving deep into the inner workings of Blazor, I was able to unite a "service" model with a web UI model. So when you close the browser, the service continues to run. And not just that, I was able to implement a "plugin" model that we're all used to that made ARC so powerful.

I wouldn't say we broke the rules of how .NET 8 and Blazor were designed - but I indeed pushed the limits.

So now we get into ez-script. The ARCx was designed with a ton of functionality that I witnessed many users needing. Not just on the forum but with our enterprise and corporate customers. The ones that are controlling forklifts or other high-priority robots and automation. I needed to balance the David DIY users and the warehouse forklift robots. They are two different customers but with similar outcomes. We hit a wall as the platform was being architected for scalability to integrate new advanced features such as AI and advanced computer vision.

That wall was EZ-Script. The "middleware" that made EZ-Script operate was incompatible with the functionality of ARCx. Not just with the ControlCommand() syntax but with how robot skills interchange data. It was impossible to work with the EZ-Script codebase. I spent some time and sleepless nights trying to figure out how to make it compatible. The decision wasn't easy, but it became evident when we realized EZ-Script would have less functionality than its JavaScript and Python counterparts.

I considered what the user response would be from a less functional EZ-Script. Suddenly, we will have users doing amazing things with JavaScript and Python, with EZ-Script users wondering why they don't get the same experience. That would make many people unhappy to see the potential but not be able to harness it. That's when I had to make the tough decision to rip off the bandaid, so to speak. Because the learning curve to get into Python or JavaScript would be less painful than having a robot that doesn't perform as well as it could.

I talked to a few schools and other larger organizations using ARC to understand their concerns about removing EZ-Script. Their feedback was this: It's okay to remove EZ-Script because it's not an industry language and doesn't teach anyone anything useful. That made me sad, of course, because I was proud of ez-script. But at the same time, I knew many of you would feel the same way. So, I hope everyone understands that we all share the same remorse to see EZ-Script come to an end.

But we can all reflect on the fantastic evolution you experienced from early ARC to what ARCx will be. I am also confident that the similarities of the languages will make the migration painless - I'm sure of it. Even if it means we eventually add an Athena function to help convert EZ-Script to another language.

My Music

You know, music has always been a massive passion of mine. I was always a geek with programming, but I thought I'd end up producing music for video game soundtracks. That was where I always pictured my music being used. I eventually teamed up with a few people who wanted to play live shows at venues, which we had great success at. I enjoyed those days and have a vast library of new and recent music. Almost all of the EZ-Robot and Synthiam videos used my home-produced music from a studio in my basement.

Eventually, with the stress of running a company, music became a source of relaxation. Sitting in the dark with the ambient lighting of my synthesizers and racks of audio equipment, I would escape the world of being a CEO. I would forget about having to put prices on my passion and paying bills, employees, taxes, benefits, servers, and rent. As I continued to create music for this reason, I started to share it less. The music I produced began to be more emotional and personal. As you know, when something becomes that personal to yourself, it gets harder to share because you value the opinions of others. If someone were to say, "I don't like this song," it hits close to home.

I guess what I did was keep it close and stop sharing it. I continue to produce music, but I don't let anyone hear it. Emotional experiences influence some of it, and I may be too vulnerable to listen to opinions. If I had a hard day because I had to let go of a staff member, that song would have a tight connection with my emotions that day. If someone said they didn't like the song, it might make me feel like I relived that day again. It could have been a day I wanted to forget - and the song is a snapshot of what I felt then. The song helped me put that day behind me by locking it away on a hard drive.

As I write this response and reflect on my reasoning, there is a possibility things might change. Nothing is forever, and only time will tell what I'll do with the stash of music. Perhaps one day, I'll create a blog that explains the reasoning behind the song that I link. Perhaps one day, I'll have enough time between then and now to have enough separation not to let it affect me as much. So, that being said, I guess the answer is to stick with me, and we'll see what the future holds!

ARCx

I'm incredibly excited about ARCx, and I hope you do as well because you may not know, as I said earlier, that conversations with all of you have inspired all the features of ARCx . Conversations that happen online or offline. And not just that but observations of our community's challenges and successes. While removing EZ-Script might appear that I took something away that is responsible for your success, I'm confident ARCx will make you forget all about EZ-Script. The enhancements will make your robots easier to sell, easier to build, and easier to use.

Oh, I do need to add this about why ARCx became web-based.

Windows UI

Windows evolved since Win95 to use a set of API calls called Win32, which you may have heard references to elsewhere. Win32 links user interface events (mouse clicks and such) to code snippets. It allows drawing buttons and forms on the screen that the user can interact with. The code is executed based on an event when the user clicks a button. These events are pipped through an event manager, and it all worked well for many years.

I put a lot of faith into Microsoft to create a cross-platform UI when I saw the .Net CORE and Linux subsystem support for Windows. This made me think they would integrate a desktop-friendly cross-platform UI for Linux, MacOS, and Windows. Microsoft also acquired Xamarin, which was a cross-platform .NET compiler and toolset. Microsoft also started working with the Mono team, which allowed .NET applications to run on native operating systems, such as Linux and MacOS.

Because of these reasons, I was sure Microsoft would create a cross-platform UI. They eventually did it in 2023 with something called Maui. I was looking forward to it because it meant taking the ARC codebase and porting it to the Maui UI framework. But, like with Windows 8, Microsoft keeps forgetting their largest market is desktop users, and they developed Maui to make cross-platform mobile apps. There is a Maui for desktop Windows, but it isn't compatible with Linux and has many limitations with MacOS.

When Microsoft created Windows 8, it was around the time of the Windows Phone. They saw the success of Apple and Android in the mobile market and assumed they would be strong contenders. What they overlooked is the fact that "power users" who create stuff need Windows. Windows is necessary to create a mobile app. Windows is required to develop CAD schematics, PCBs, CPUs, and products. Windows is needed to make the "things." Because of the simplicity of creating graphic programs in Windows, all of the best design software is in Windows. Microsoft suddenly threatened the designer's customer base by leaning toward a mobile world.

When the question is asked, "What came first, the chicken or the egg?". In this case, every egg is created by programs created in Microsoft Windows. We wouldn't have the mobile world if it weren't for the Windows apps.

This is relevant because Maui is not an environment where people can create CAD software. No one is making a programming IDE in Maui. No one is creating the next video editing suite in Maui. So, how will ARC make a robot development platform in Maui? The answer is we aren't.

ARCx Web UI

Because I was expecting Microsoft to realize its position as an operating system for "the creator," I kept delaying the development of a new ARC. When .NET 8 was announced with Blazor, I saw the answer.

Would I prefer a native UI? Yup!

Will I get a cross-platform native UI? Nope

So, we end up with a web front end, and that's why ARCx will be web-based. But, being web-based means, there are several advantages to interfacing ARCx with existing tools and the Synthiam website. It also means that any device with a web browser can be the UI for ARCx. And because there's no need to render a GUI on the graphics device of the robot, you can run ARCx on lower-powered SBCs.

There are many benefits to a web front end, even though I had different expectations of where Microsoft was heading.

Wow, amazingly deep and inspiring insight into the path you've traveled that has brought us to ARCx. Thanks for sharing the how and whys of where we're heading with Synthiam. You're a courageous genius. We're all very fortunate and benefit from you having the ambition to bring your dreams and ideas to life. I feel very grateful that I've been able to witness a lot of the changes your dreams have brought about sense the early days of EZ Builder. I started using the Ver 3 EZB just after you released it along with EZ Builder and EZ Script. Because of your dreams, my dreams of having a real robot were able to come true. I'm looking forward to learning how to use ARCx and hopefully I'll be able to convert my many EZ Scripts into JavaScript. I don't want to be left behind after all this time. Thanks again for sharing the story of your continuing journey developing ARC.

The programming manual for ESP32-P4 came out this week.   If they were going to design a new EZB this chip is interesting.  50 GPIO ports 2 core RISC-5 400mhz. Also has a 40mhz single core CPU for low energy tasks. You could probably even run imbedded Linux and perhaps ARCx directly on board.  Has streaming video, AI, USB, Ethernet and 50 GPIO ports.

what it lacks is wifi so you have to pair it with another ESP, .They  should have development boards in limited release in April and production release Q3.

Esp32-p4

I know I'm a month late but you should continue releasing music. Many artists have to learn to not take negative comments seriously. It's very hard to do, but is possible. You helped revolutionize the robotics industry and made it more accessible. You can do the same for music. Many other robot manufacturers and companies in between have made their technology complicated and proprietary. With the companies you founded, it's much easier. My point is, the music that you make is amazing and you need to share it more without fearing what other people would think.