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


ARC Pro

Upgrade to ARC Pro

With ARC Pro, your robot is not just a machine; it's your creative partner in the journey of technological exploration.

#9  

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

PRO
Synthiam
#10  

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/

PRO
Synthiam
#11  

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

#12  

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.

PRO
Synthiam
#13  

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:)

#14  

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

#15  

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.

#16  

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