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@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@code.ros.org
https://code.ros.org/mailman/listinfo/ros-users


_______________________________________________
ros-users mailing list
ros-users@code.ros.org
https://code.ros.org/mailman/listinfo/ros-users