[ros-users] iRobot - Roomba vs Create
Gonçalo Cabrita
goncabrita at gmail.com
Sat Dec 4 20:08:24 UTC 2010
Hi everyone!
First of all thanks for the kind comments related to the documentation.
To answer your question Alex,
One more question, if you had an option to buy a new Create and used Roomba 560 at the same price today, which one do you think you would buy?
Since we have a lot of Roombas I would like to purchase a Create to try it out. Also the Create can have that green block, the Command Module that I believe can be used to connect a bunch of stuff that can be accessed over the iRobot OI protocol. Furthermore the Create has more room to mount sensors and actuators.
The Roombas on the other side require more handy work to become ready for research. We had to buy some connectors, make some voltage regulator boards for the lasers and we added an arduino to each robot, allowing us to connect other sensors we commonly use around here.
Still, bottom line, if the Roomba's odometry proves to be better I would go for the Roomba. However that ROS vision odometry stack could solve the odometry problem if one could use a cheap one camera system (at the expense of extra computational power, which in our case is really bad since we have tiny EeePCs!!!).
Gonçalo Cabrita
ISR - University of Coimbra
Portugal
On Dec 4, 2010, at 7:22 PM, Ken Conley wrote:
> FYI: We're starting an effort here at WG to use Creates. We didn't
> benchmark against the Roombas, and perhaps some of those will end up
> in our arsenal as well. Also, we've noticed Gonçalo's great
> documentation coming online, so we hope we can build on each other's
> efforts. We're using it to integrate some of our main libraries
> (navigation, OpenCV, PCL) into a low-cost platform. We've already
> posted our Kinect + Create tutorial, which is part of this effort.
>
> One main difference between the Creates and the 500 series is (IIRC)
> that you can't read the raw encoder counts off the Create. The Open
> Interface for the Create only goes up to Packet 42. The 500 Open
> Interface adds Packets 43-58, which include encoders, light bumper,
> motor currents, and stasis caster. I assume this means the odometry
> with the Create will be worse, but, like Gonçalo, I don't have
> experience with both.
>
> Our driver right now is in Python and uses Damon Kohler's PyRobot,
> plus bits and pieces for other ROS drivers. The stack is still a work
> in progress and will move soon, but for now you can find it here:
> https://code.ros.org/svn/ros-pkg/branches/trunk_cturtle/stacks/create_robot/
>
> - Ken
>
> 2010/12/4 Gonçalo Cabrita <goncabrita at gmail.com>:
>> Hi Alex,
>> Hope you don't mind I started a new thread for this.
>>
>> Buying the Roomba instead of the Create was not an option for us. At first
>> we were aiming for the Create since it was designed having research in mind,
>> but the Portuguese iRobot reseller told us we could only acquire the Create
>> on the United States. So we got a sweet deal on a bunch of Roombas instead.
>> Let it be clear that I never worked with a Create in my life, so I cannot
>> make a comparison between both robots.
>> When we first got the Roombas we had some trouble with the odometry... ok a
>> lot of trouble! The Roombas have very poor encoders, single channel, 4
>> pulses per motor shaft turn (I believe direction is determined from the
>> motor speed, I don't think you can even call this an encoder). Also,
>> initially we were getting distance travelled and amount turned from the
>> robot, which resets after each read, so at the speed we were polling the
>> Roomba (10Hz) and due to the low resolution on these values (1 degree for
>> the angle for example), we were getting really bad odometry readings. Later
>> we decided to poll the encoder counts instead, which greatly improved our
>> odometry (this is how the roomba_500_series package works) however we bumped
>> into another problem. Usually encoder counts increase as the wheel moves
>> forward and decrease as the wheel moves backwards. However on some Roombas
>> encoder counts only increase. You can still make a quick fix using the motor
>> speeds as an indicator of the wheel direction, but the odometry on these
>> robots is far worse. Now that i think of it, this should go into the
>> roomba_500_series troubleshoot section! We recently got a batch of 555, non
>> of them seem to have this problem. However some of the 530 and 560 we have
>> suffer from the "crappy" encoder problem.
>> Globally the Roomba is a very robust platform, it can take a lot of beating.
>> It also brings a nice package of sensors and actuators. iRobot 's
>> documentation on the communication protocol is very good, you get access to
>> pretty much everything the Roomba has. The docking station is very cool, we
>> love it. The battery usually holds for 2-3 hours pumping juice to the Roomba
>> and an Hokuyo laser. We run it with the ROS navigation_stack and it moves
>> without problems
>> Finally I guess for the money we spent we couldn't expect better, the value
>> for money is great, specially for us, we have a lot of Roombas for swarm and
>> multi-robot experiments. You can't compare it to a robot designed
>> specifically for research though.
>> Now I guess people who are using the Create could give their opinion on this
>> matter :)
>> Hope this helps!
>> Gonçalo Cabrita
>> ISR - University of Coimbra
>> Portugal
>> On Dec 4, 2010, at 6:01 PM, Alex Bravo wrote:
>>
>> Goncalo,
>>
>> I've been looking at the package you created for Roomba
>> 560 http://www.ros.org/wiki/roomba_500_series
>> and I just wanted to say thank you for such an excellent job!
>>
>> We are considering purchase of iRobot and wondering if extra expense of
>> Roomba 535/560/570 is worth it compared to iRobot Create. We also see that,
>> say Brown University still uses iRobot Create.
>>
>> Considering your experience (if I remeber correctly, you were mentioning
>> those robots a year ago), what are you thoughts on the
>> advantages/disadvantages between those models?
>>
>> Thank you,
>> Alex Bravo
>>
>> _______________________________________________
>> ros-users mailing list
>> ros-users at code.ros.org
>> https://code.ros.org/mailman/listinfo/ros-users
>>
>>
> _______________________________________________
> ros-users mailing list
> ros-users at code.ros.org
> https://code.ros.org/mailman/listinfo/ros-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ros.org/pipermail/ros-users/attachments/20101204/74d122b7/attachment-0004.html>
More information about the ros-users
mailing list