Grab yourself the Roomba 980. Its got slam and iOS and Android apps to run it.

Hey DOC LOL.... Those are seriously expensive... and the Canadian dollar sucks to boot...

Richard R I for one am interested in rod. What controller are you using? Arduino platform?

Hey Richard. ROS is great and SLAM is awesome. Add to that something like A* for path calculation and path finding, your indoor navigation is done.

I am doing a lot of this also with Rafiki. It uses the best technology that I could afford and allows communication between multiple controllers. For example, I want to have a robot that does these advanced features but also is able to be expanded with different sensors and has an easy to program user interface. To accomplish this goal, I am using the V4 to allow users to add what they want to the robot. It also allows the user to customize the programming as needed for use of these sensors or allow the robot to do different things without having to know ROS or any more difficult to learn programming language. SLAM and A* run on a different controller in the robot. The robot also has a central controller which coordinates everything and sends the information back to the EZ-B and ARC for the user to do what they want to do with it.

I see this as the best of both worlds personally. Serial communication between these devices is adequate and still allows the user to use ARC while still providing extensive capabilities that I don't want the user to mess with.

Anyway, just a thought. I don't see it as an either or situation. I see it as a "use the best option available for the function that you want to perform" type of situation. It is different if it is something you are developing for yourself and I understand that for sure. I probably would still do it the same if it were just for me but I am using linux on single board computers instead of a pc or tablet. These boards have GPIO ports and serial ports and can communicate information back to the V4 easily.

Anyway, have fun dude. You have my email and keep in touch.

@kamaroman68 For the turtlebot you only need a laptop and the ASUS Xtion Pro 3d camera (or kinect)... The laptop running ROS plugs directly into the iRobot roomba or Create base so no need for a microcontroller. There is a Create control Package for ROS... I am sure down the road I will need to use a microcontroller of some sort for other projects... As David mentioned he is able to interface ARC and the ezb... and also like he says "it's the best of both worlds"....

Thanks David... I am sure I will need to consult you at some point.... I figured as much that you were using slam in one form or another for Rafiki... I wish I could be a fly on the wall with what you are doing... However, once I get Turtlebot working I should have a pretty good grasp of ROS....

Thanks for the reply Richard. I at one time expressed great interest in the pr2 robot. How do you go about interfacing motor control into ros? I was under the impression it was a computer that spoke to an I/o type board hence the arduino question. I don't think computer outputs could handle the motor current draw. Thanks again

Richard, check out the new Thinking Cleaner WiFi faceplate for the 500-600 Roomba that is selling on Amazon.com. $99 It may be something you could use with the ROS environment. I just dusted off my Ubuntu laptop, downloaded the latest upgrades and now downloading the ROS with GUI. Also just received some low power WIFi UARTs with webpages instead of just ATT commands that I'm going to hook up to the Create-Two.

@Doc I hadn't seen that before... That wifi face-plate is so cool and elegant... I am going to try and get one... I would love to see your wifi setup with the Create 2 when you get it going,,,, @kamaroman68 I haven't really looked into motor control options for ROS yet.... For now I am trying to get Turtlebot up and running so I can grasp the basic concepts first. However, I do imagine having to write some basic code in C++ or python and using something like an arduino down the road in order to drive a sabertooth or Romeo controller.... I'll cross that bridge when I get there...

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: https://synthiam.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. 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

@am3081, Any updates on your progress?

@Richard_R, 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?

Regards, Frank

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?

Hi Dave, Looks like the new UpBoard Core has BT & WiFi

linuxgizmos.com/up-core-sbc-is-a-smaller-wireless-version-of-the-atom-based-up/

Regards, Frank

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.

Interesting read guys!

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. 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.

-G

@GBot, Thanks for the info

Regards, Frank