Dunning-Kruger
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
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...
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/
That makes creating user controls in ARC even easier since the entire ROS framework is also released in C#.
All communication is over the tcp stack anyway, so it wouldn't be too hard to tie the two together I wouldn't think.
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....
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.
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
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.
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?
@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
As far as performance I wonder how it stakes up against what LattePanda has to offer?
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
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.
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?
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 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
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
Thanks for the info
Regards,
Frank