Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Robot compatability #8

Open
lawsonkeith opened this Issue Feb 25, 2015 · 12 comments

Comments

Projects
None yet
4 participants
@lawsonkeith
Copy link

lawsonkeith commented Feb 25, 2015

Hi

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

Ta

@ghost

This comment has been minimized.

Copy link

ghost commented Feb 25, 2015

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

This comment has been minimized.

Copy link
Owner

mikeferguson commented Feb 26, 2015

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

@lawsonkeith

This comment has been minimized.

Copy link
Author

lawsonkeith commented Feb 26, 2015

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

This comment has been minimized.

Copy link

jmtatsch commented Mar 9, 2015

@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

This comment has been minimized.

Copy link
Author

lawsonkeith commented Mar 10, 2015

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

This comment has been minimized.

Copy link

jmtatsch commented Mar 10, 2015

@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

This comment has been minimized.

Copy link

imbinary commented Mar 10, 2015

@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

This comment has been minimized.

Copy link
Author

lawsonkeith commented Mar 10, 2015

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

This comment has been minimized.

Copy link

jmtatsch commented Mar 11, 2015

@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

This comment has been minimized.

Copy link
Author

lawsonkeith commented Mar 12, 2015

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

This comment has been minimized.

Copy link

jmtatsch commented Mar 14, 2015

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

This comment has been minimized.

Copy link

imbinary commented Mar 15, 2015

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.