Robot compatability

[lawsonkeith]

Hi

Do you know if this is compatible with the XV-25 and Botvac series robots? Obviously the XV-11 is now obsolete.

Ta

[Deleted user]

Try jlohse's modification, https://github.com/jlohse/neato_robot . I was using a newer firmware with the XV-11 and his modification made the driver a little more generic.

[mikeferguson]

Unfortunately, I have neither an XV-25 nor a Botvac. Pull requests to update these drivers are very welcome.

[lawsonkeith]

Hi I'm happy to do that have you any idea if its feasible?

On 26 Feb 2015, at 03:27, Michael Ferguson notifications@github.com wrote:

Unfortunately, I have neither an XV-25 nor a Botvac. Pull requests to update these drivers are very welcome.

—
Reply to this email directly or view it on GitHub.

[jmtatsch]

@lawsonkeith imbinary fixed it in commit imbinary@bf5d2a3
turns out this still works for the new botvac series and probably also for the vorwerk vr200. Maybe @imbinary can open a pull request for this here? I also forked his fork and fixed his generation of the button msg here https://github.com/jmtatsch/neato_robot

[lawsonkeith]

Is there any meaningful work to do to it then? if the Botvac / XV are compatible the only real thing to improve would be the wiki? I've done this before though for other repos: https://github.com/shaunuk/picar (wiki was previously about 4 lines of text) and it's worked well; I've noticed a lot of the docs on github are brief in the extreme.

[jmtatsch]

@lawsonkeith Nice job with the wiki of picar! I think there also remains some coding work to be done. I couldn't get gmapping to create a map because some angles from the lidar seemed to be out of the allowed range. Maybe you can look into that?

[imbinary]

@jmtatsch I'm assuming you reset the gmapping node to the correct setting to use the bulti-n lidar. In my for I was doing testing on a custom made lidar device. see http://youtu.be/lScTaRXi_bo for the lidar in operation.

[lawsonkeith]

I'll think I'll look at getting a signature; the botvac is more expensive and the extra features aren't important for hacking (picking up pet hair). I propose integrating it with a Raspberry PI and improving the wiki as per what I did on Picar? This should be a good improvement to the ROS package and make it more accessible to newbies. I'll look at any code issues at the same time.

[jmtatsch]

@imbinary of course I didn't. Thanks for the hint, will try it out this weekend.
@lawsonkeith Depends what you are looking for. If you just want a mobile platform with a laserscanner, a refurbished signature is good enough. If you want to use it as vacuum robot, I would recommend to get a botvac alone for the sidebrush. While it would be intriguing to have the computing power of a pi2 on the neato itself, I don't see where it would fit without impairing the lidar except for on top of the lidar. Mounting it on top would increase the height by about 3cm which means you would frequently get stuck while using it for cleaning. I use one of those tiny 3g routers http://www.ebay.de/itm/221521130775?_trksid=p2059210.m2749.l2649&ssPageName=STRK%3AMEBIDX%3AIT with OpenWrt on it to bridge the uart over wifi. Although the concept does work, I have yet to open up the botvac and solder it directly to the main board. Improving the wiki is always good 👍

[lawsonkeith]

I've seen in mounted in the dust collector bay and on top of the LIDAR hood. I can play about with it and see what I can contribute...
The Pi should also enable the use of OpenCV using it's optical camera which is something else I can look at.

[jmtatsch]

I still get the same error messages from gmapping:
Scan message must contain angles from -x to x, i.e. angle_min = -angle_max

The relevant code in gmapping is

00313   // Check that laserscan is from -x to x in angles:
00314   if (fabs(fabs(scan.angle_min) - fabs(scan.angle_max)) > FLT_EPSILON)
00315   {
00316     ROS_ERROR("Scan message must contain angles from -x to x, i.e. angle_min = -angle_max");
00317     return false;
00318   }

The laser scan msgs from /base_scan contain:

angle_min: 0.0
angle_max: 6.26000022888

FLT_EPSILON according to float.h ist 1E-5 or smaller, no wonder this always causes errors.
To mitigate this, I changed neato.py to

scan.angle_min = -3.14
scan.angle_max = +3.14

While this allows gmapping to start properly, is there any good reason why angle_max: 6.26000022888 < 2*PI?

[imbinary]

I think If you use exactly 2PI you will have overlap.

On Sat, Mar 14, 2015 at 11:19 AM, jmtatsch notifications@github.com wrote:

I still get the same error messages from gmapping:
Scan message must contain angles from -x to x, i.e. angle_min = -angle_max

The relevant code in gmapping is

00313 // Check that laserscan is from -x to x in angles:
00314 if (fabs(fabs(scan.angle_min) - fabs(scan.angle_max)) > FLT_EPSILON)
00315 {
00316 ROS_ERROR("Scan message must contain angles from -x to x, i.e. angle_min = -angle_max");
00317 return false;
00318 }

The laser scan msgs from /base_scan contain:

angle_min: 0.0
angle_max: 6.26000022888

FLT_EPSILON according to float.h ist 1E-5 or smaller, no wonder this
always causes errors.
To mitigate this, I changed neato.py to

scan.angle_min = -3.14
scan.angle_max = +3.14

While this allows gmapping to start properly, is there any good reason why
angle_max: 6.26000022888 < 2*PI?

—
Reply to this email directly or view it on GitHub
#8 (comment)
.

[mikeferguson]

Archiving shortly