Welcome to Synthiam!

Program robots using technologies created from industry experts. ARC is our free-to-use robot programming software that makes features like vision recognition, navigation and artificial intelligence easy.

Get Started
Asked — Edited

I Am Moving On Or?

So, long story short I am learning/moving on to ROS (Robot Operating System)... Ez Robot is still the easiest and greatest software on the market especially for the beginner. I will always push it when people ask me "where should I start". However, I have hit the wall and want to go further, After seeing what Willow Garage's PR2, Xaxxon's ROV and ClearPath's TurtleBot can do using RVIZ and SLAM I am willing to undertake the steep learning curve to to accomplish the same (well as much as possible). Just google if you want to see what these bots are capable of. I have been messing with uBuntu and ROS for the last few weeks and I am beginning to make some serious progress with it...
One of my serious goals is 3d mapping and indoor navigation... ROS does this superbly... I have bought myself a ASUS Xtion Pro and I already have a laptop running uBunto and ROS and an iRobot Create. So now I have a cheap Turtlebot capable of 3d indoor mapping (real time), obstacle avoidance and target navigating...
Yes, I could have learned C# and written add on controls for EZ Robot, but there is no way I have the programming ability to come up with something like SLAM (simultaneous location and mapping). I just do not have the programming skills of guys like DJ and d,cochran,,,, So unless DJ has a rabbit up his sleeve regarding indoor nav the only way I am going to accomplish this is to torture myself learning ROS and do it myself... To be honest I have always felt a bit like a fraud using ez robot... I mean when people ask me or say "how did you do that" or "you really are smart, that's amazing".... I can't help but think in the back of my mind... this is not me, this is DJ Sures he's the real genius here...
Anyway, I feel like I hit a cross road and I have to take another route for a while... I am not leaving here and I will will keep my mouth shut about ROS as it has no place here... Besides, no one wants to listen to my ROS ramblings anyway:P So when I am one here it is all about ez robot and nothing else...

Not sure why I posted this... maybe just to make myself feel less guilty about moving to the dark side for while anyway...:) You never know, I'll probably get overwhelmed with ROS and come crawling back here with my head hung in shame...:D

AI Support Bot
Related Content
Give ROS a shot - i have been working on an EZ-B v4 package for ROS anyway. I'll push it out in a the next few weeks. You can use the EZ-B v4 with ROS, if you dare :). It's a terribly large collection of programs and stuff with no responsibilities for security, bugs and usability. Share your experience and maybe with a little EZ-Robot influence, some of the ROS packages will become wrapped in ARC controls.

So if you magically find yourself having more time than sanity to create programs in C++ using ROS, then you will be able to control the EZ-B v4.

BTW, you don't have to write C# plugins for ARC. You can also do C++ and IronPython. However, it's much easier to program in C# than Python or C++. :)

Here's iron python: http://ironpython.net/
Oh, i forgot to add that ROS has a C# port as well, which can be found here: http://wiki.ros.org/roscs

That makes creating user controls in ARC even easier since the entire ROS framework is also released in C#.
I was actually just thinking about how cool it would be to have a ros publisher and subscriber client for ARC.

All communication is over the tcp stack anyway, so it wouldn't be too hard to tie the two together I wouldn't think.
ARC and Ez-b. It's just ros is so unmanageable and overly complicated. It would dominate if they would split the development efforts toward UI and processing. Instead it's just a big jumble of poorly documented code that "sometimes" works. Open source, no one gets paid so who cares I guess:)
That would be sweet... I mean the ezb4 is the ultimate robot controller. Having ARC/ezb interface with ROS (subscriber/publisher) you would be able to take advantage of 3d mapping and navigating using the Asus Ation or kinect...

It's the ability to do indoor navigating with ROS is why I want to learn ROS. ROS does this part really well... If you (DJ) can write a ROS package to take advantage of ROS's good parts like 3d mapping (SLAM, Moveit!) then I am thinking you wouldn't need to re-invent the wheel writing your own indoor navigating controls for ARC... Besides if you were to write even a simple ROS package I (and anyone else) won't have to use arduino to drive motors or read low level sensors like pings and IR.... If I had the programming skills, I would in a heartbeat create a ROS package for ARC....

My problem is what I want my robots to do, I can't at the moment and I really, really! want to do indoor navigating... I feel (my opinion only) that one of the missing features in ARC that would make anyone question "what's the point of ever learning ROS?" is a SLAM type control in ARC... Yes, I do understand the enormous challenges in order to write a SLAM type control... I do know you don't need to use a Asus Ation or kinect as the lidar from a Neato vac could do the mapping.

I have done simple path planning/navigating using RoboRealm (avm navigator) with one of my ezb4 bots and it works pretty well... However, it is severely limited. Move a chair or move any piece of furniture near it's path and the robot gets confused and loses it's ability to navigate. Even different lighting can send the robot off course. And each path has to be driven over several times for the robot to accurately navigate it. One final limitation is unlike SLAM, you can only send the robot to way marks along it's narrow route... You can't, say send the robot anywhere in the room and have it navigate there like SLAM can..

Anyway, just my ramblings and it's easy to sit here and be an "arm chair" quaterback....
Just to be clear, I am not promoting ROS or EZ-Robot here. I am not putting either down here either. I just believe that a client that handles communications between these two would be an amazing addition to ARC.

ROS works by publishing messages from services. These services can be anything that you want them to be. There is a master service which operates like a DNS service and all services report to the master service to report what they will publish or what they want to subscribe to. The master service just points the subscribers to the publishers.

The EZB and ARC does offer a lot to the robotics community. It opens the doors to many who have no programming background, handles sensors and motors with great eloquence, and also prevents you from reinventing the wheel. ROS offers a development platform on Linux mainly which is appealing to a large number of those interested in developing robot software for a number of reasons. The cost factor is probably one of the biggest reasons, but also stability for the most part, and an OS that can be very light weight (no gui or sound or really anything else that you don't want to turn on).

The thought is that if a ROS publisher service were created for ARC (perhaps using the C# port of ROS) then the communication between ARC would allow ROS to get EZ-B information. If a subscriber client were built for ARC, ARC would then be able to subscribe to ROS services and get the messages (sensor readings, location information or whatever is published). This would allow ARC to use ROS data and ROS to use ARC data.

How would this be helpful?
1. While ROS is the wild west of the robot software, there are a lot of users and a lot of innovative development taking place using this platform that would be very nice to utilize. The goal of ROS is to allow people to build on each others progress. This is a noble goal but not one without its own struggles. Being able to have access to these programming efforts would be great

2. Most colleges allow ROS in their students projects. Perhaps by offering this service, you would see more Comp Sci and Robotics students utilize the EZB in their projects.

3. ROS can run processes (nodes) on multiple computers by design. Because of the publisher/subscriber architecture, there can be multiple single board computers inside a robot which then can communicate with each other over TCP. This can be WIFI or wired connections depending on what you want. To me this is a huge benefit, but it lends itself to being integrated with from other devices (like a pc running ARC) from other locations either inside or outside of the robot.

I am in no way saying that ROS is better than ARC. Really it is not. What you have are many developers working in ROS who are pushing the capabilities or ROS very far. Like DJ says, if there were a concerted effort of the developers to work together to push the tools available ahead, that would be awesome, but that isn't really what ROS was designed for. It is supposed to be the Wild West of the robot platforms which allows rapid expansion of partial ideas and partially working code. That isn't what EZ-Robot is. ARC is much more planned and thought our because there is a company, customers of the product and peoples incomes at stake. Because of this, DJ has to take a different approach and it is a very good approach.

I say all of this because by creating a subscriber/publisher service for ROS, you get the best of both worlds. You get the far more stable environment from ARC, along with being able to bring in the ROS environment. There are other ways of handling this type of joining of these technologies (through serial communications mostly, or publishing data to a flat file or database which then is consumed by a service in ROS), but this publisher/subscriber client would be a far more eloquent way of handling this.
@dj-sures are you still considering releasing an ezb v4 package for ROS connections. I just got my starter kit up and running (its a great product) and its something I would use. I would be interested in even something that was half done as it would save me the time of doing it myself from scratch.
not at this time. Ros is far too complicated and doesn't align with ezrobots educational goals. 99.9999% of ezrobot users cannot make a plugin, let alone program a c++ application from scratch in Linux with Ros.

Given all of the software options provided by ezrobot, the most popular is ARC and the ability to use ARC to create mobile apps. Two items which are impractical to do with ros.

However, I sure won't stop anyone from implementing an interface in ros to the ezb using the published command protocol document: http://www.ez-robot.com/Tutorials/Lesson/18?courseId=5

@dj-sures thanks for the quick reply. Totally understand. I am a programmer during the day and getting into robotics as a new hobby so I have very different needs than I think most people who use this product and am more able to fulfill them without help. Will definitely try to post updates of my work for people in the community who are interested

The Mono SDK was easy to get up and running and I think gives me everything I need to at least send and receive pub / sub stuff from other ROS modules while writing control code with the SDK.
Nice! Sounds like you're the person for the job :D. I'm a huge fan of the initiative which ROS is taking. However, ez-robot's goal is to educate less experienced individuals, and ideally bring them to the ROS level. As you've seen, exposing the library, command protocol, sdk, and plugin system is pretty powerful in itself as well.

Let me know if you have any Q's regarding publishing an EZ-B pub/sub into ROS. When you do, i'll have a link to your work and credit added to the software page
Any updates on your progress?

I'm also looking into ROS for SLAM with EZB... but it's a steep learning curve. I'm looking into getting it running on a Raspberry Pi 3 using Ubuntu Mate. If the RPi isn't powerful enough I'm considering the UpBoard

Do you have any updates?

Thouse UP Systems look promising. Lots of different choices on power and configuration. More choices for more powerful systems coming very soon (next month). However it looks like you need to buy the OP, Bluetooth and Wifi modules separat.

As far as performance I wonder how it stakes up against what LattePanda has to offer?
Looks like a nice upgrade. Up probably had to do that to compete with LattePanda. The two boards look similar now (depending on how you configure them). Still if you don't want to bother with buying and installing windows LattePanda has that available (for a higher price).

I really want a board like this to mount in and control my B9. However I still fear it won't be fast enough to handle the control of my robot. I've got lots of things happening at once and at many times. I guess the only way to find out is to take the plunge and give it a try. Of course I could wait a while until the more powerful Up boards are released. I won't be ready till this winter anyway to try this. :)

Thanks for reopening the thread and getting me thinking. ;)
ROS 2 beta V2 is out now. ROS 2 supposedly fixes all the issues with it not being secure and if roscore goes down then your entire system won't fail now. There is a learning curve to ROS for sure but it does give you great amounts of flexibility. I would love for their to be a publisher/subscriber node for communication between ROS and ARC.

Also I have not had great luck running ROS on the raspi. There are always dependency issues on the install and the board has a hard time handling all the processes. I am using the UDOO X86 to power my robot using ROS. Been having issues with the built in Arduino 101 pins but I think I got it worked out. The UP Board 2 looks pretty promising. Though my question with that is knowing that it uses the same GP-bus pin layout as the Raspi, then will it also have the same clocking issues you get with the Raspi when trying to run LEDs?
Here is the chicken and egg question...

I don't know why anyone would use ros - because you might as well just code everything yourself in c++ from scratch if you can use ros - haha... In my mind, technology should be making things easier, not more difficult. Seems backward to me for ROS to be in development. We might as well sell our PC's and GUI Window environments and replace them with mainframes and PDP toggle switches :D. What's the advantage of taking 2 steps forward and 3 steps back? Other than if it's a line dancing song.

I don't like country music.

Anyway, if you want to use ros, because you like difficult things, then anyone who uses ros can easily make a plugin for ARC that subscribes as a node using tcpros: http://wiki.ros.org/ROS/TCPROS

Point is, even if ezrobot made a ros plugin, there's no point because anyone who can setup ros would already know how to subscribe ARC to it:)

Once we create a plugin, ros still needs to be compiled and configured to do "something". Aaaaaand, the plugin would somehow to magically know what your custom ros configuration is meant to do.

Ros shouldn't be called a robot operating system. It should be called c++, python and a bunch of poorly documented code that only runs on a difficult to use operating system. Hahaha
I mean it is a giant piece of work but you can get it to work and the robot simulations are very nice to debug your code before you upload it to your actual bot. It is extremely difficult to get a grasp of as a noob to codings but I have been able to write subscribing and publishing packages with little experience in coding.

I do think you make a good point as to why use ROS when you could write it all from scratch. You basically are writing the if else statements all yourself but importing the main functions of the robot through packages that are already written for you that would take an extremely long amount of time to write. Ex. Facial recognition, SLAM, speech recognition... Also RVIZ and Gazebo are a great debugging and simulator tool built right into ROS. The SLAM in ROS is a very powerful tool.

Learning ROS was definitely quite the venture when I first started because there was almost no documentation other than the ROS Wiki. Now there are a few books out and also online tutorials that are very helpful. I am using the Robot Ignite Academy to learn ROS. They have many great tutorials on there ranging from beginners to learning how to program a self driving car. (Also business like BMW are using ROS to build their self-driving cars. So it can't be too awful. Is it for people looking to plug and play without a VERY VERY steep learning curve? NO!)

p.s. I am in now way affiliated with ROS or Robot Ignite Academy. Just a big nerd that loves to learn
Hi All,

Just read through this thread and wanted to post my experiences in integrating ROS and EZB.

I have a Willow Garage Turtlebot 1 (old school robot, now in the 3rd iteration) running ROS Indigo, with some cool tweaks like a LIDAR from a Neato botvac, 60 LED addressable indicator strip, and a second kinect for 3D SLAM. I really wanted to integrate the EZ-robot software into the ROS environment to take advantage of the ARC's powerful and intuitive tools.

I wrote a very simple TCP client to communicate with ARC and then post messages to appropriate ROS topics. The client also sends relevant info back to EZB, like positional information, navigation confirmation, etc. I am mainly using the Microsoft Bing plugin to interpret spoken commands, and Microsoft Cognitive Vision to identify objects in a room, but I plan on adding some servos and using the Pandorabot plugin. At any rate, I highly recommend anyone who is interested in adding SLAM to their projects to give ROS a try-- just be sure you are willing to experience many, many hours of frustration as the learning curve is practically vertical. Eventually, once you get the hang of the system, it is very flexible and has some incredibly powerful functionality.

Ultimately I am planning to mount a Surface Pro tablet on a pan/tilt rig and mount it to the turtlebot to use as a face/touchscreen interface. But for now, I am just communicating with the turtlebot wirelessly through my desktop computer.

Thanks to DJ for making a really wonderful product. ARC is such a pleasure to use.

Thanks for the info