dchang0's profile - activity

No update. We gave up on the project before we bought an IMU. I suspect that the IMU would have helped quite a bit, but

There's no fix for this per se. HOWEVER, we did learn quite a few tips that kept the maps from breaking: 1) watch out

There's no fix for this per se. HOWEVER, we did learn quite a few tips that helped keep the maps from breaking: 1) wat

Yes, sort of. The fix was to upgrade from an RPLidar unit to a Hokuyo UTM-30LX lidar unit. With this superior unit, it c

I was inspired by this video to get an XV-11 LIDAR for indoor mapping via hector_slam:

https://www.youtube.com/watch?v=jSlkj...

(Note that the walking speed is quite low--the video had to be sped up 2.5X.)

I'm finding in practice that the results shown at the end of the video may be "at best"--my maps are messy and jump around/overlap on themselves. This is probably due to a problem with the particular XV-11 unit I received (that will be returned/exchanged because it sometimes emits 0.0mm readings for entire revolutions), but while researching the map's jumpiness/overlapping, I'm finding that people either gave up on the XV-11 and went to a higher-end LIDAR with a higher scan rate or added odometry, both of which increase the project cost dramatically.

So, I am wondering, before I return/exchange this XV-11, has anyone gotten the XV-11 to do decent 2D mapping without odometry at walking speeds (1.5m/s)? Is it just not possible with a 5Hz (300rpm) LIDAR? I'm not asking for perfect maps, just usable ones (no walls where there aren't really walls, etc.)

I am basically tasked to do this:

https://www.youtube.com/watch?v=F8pdO...

(Note that the user is walking quite rapidly--probably faster than 1.5m/s. We'd love to be able to go this quickly.)

If you did get it working, how did you do it? Thanks in advance!

I also confirmed that the skip: 0 results in 40Hz scanning and that this is a good thing (unless intensity is true). The min_ang and max_ang shown are apparently the hector_slam defaults. The setting that seemed to produce the largest change in map resilience was map_resolution.

Yes and no.

We never found any settings that magically made the mapping more resilient.

But, I did figure out that persons moving around the mapper or persons moving close to the mapper would dramatically break the map. We defeated this by raising the LIDAR up above most humans' heads.

Here is another clever way they do a 3D scan with just one Hokuyo--rotate the Hokuyo! http://geoslam.com/products/zeb-revo/ We examined this too and found it to be far cheaper to just buy two Hokuyos mounted at right angles (we have not done so yet).

Actually, it IS possible to use ONE Hokuyo. There was a product our team was examining as a possible 3D-mapping solution here: http://www.3dlasermapping.com/zeb1-in...

They stick a Hokuyo UTM-30LX on a bobble stick and convert that into a 3D point cloud. Watch the video. Very expensive!

Kerberos is pretty cumbersome in practice. How about simple SSH tunnels using pre-shared key files (like Amazon EC2 does)? (That is the same as VPN, really, so you sort of answered your own question.) You would essentially be using the built-in AAA of Ubuntu's SSHd and extending it to all OS instances in the system.

EDIT:

To answer your question as to whether AAA is needed--leave aside the fact that Ubuntu already provides AAA. Here is a use case where security would be needed.

Let's say we are a company that has built a swarm of security robots (running ROS) that coordinates the patrolling of a mall to prevent terrorist bombings. The swarm includes bomb-sniffing ground robots, and the terrorists need to fool the robots into avoiding the areas where bombs have been placed.

To do so, the terrorists must connect to the swarm as a fake robot, running fake nodes that pretend to be the robots covering the areas where the bombs are placed and that report "all clear" to the other nodes.

In this case, all nodes would have to be secured well enough to guard against spoofing. SSH may not be secure enough for this purpose--once a hacker gets the SSH keys and establishes the tunnel, the traffic between ROS nodes itself is too trusting. It may be necessary, as you suggest, to integrate security into ROS itself.

(I am prepared for people to tear apart this use case and point out why security is or isn't an issue. I don't claim to be a security expert, and this is just a posed use case for the purpose of discussion.)

It is possible to set up two Hokuyo LIDARs, one mounted scanning in the horizontal plane and one mounted at a right-angle scanning in the vertical plane. Together, they produce 3D scans. I do not have any idea how this would be set up in terms of ROS software, but it should be possible to do it. Autonomous drone builders would have tried this 3D mapping in order to have a drone fly autonomously through a window in a wall as part of a robot challenge.

"Totem pole" style stacking could work for us. We are planning on raising the LIDAR up above people's heads so that there are fewer moving objects like doors and pedestrians that interfere with the mapping. A tall vertical post would work on a ground robot.

Confirmed: turning the LIDAR towards the white wall with windows (through the chain link fence) allows the corridor to be mapped perfectly, including the bland yellow wall. So this has nothing to do with the fence and everything to do with the mostly-featureless view if the LIDAR is facing forward.

I'll give that a try next. All this makes me wonder--is it possible to handle this problem by using two UTM-30LXs? For instance, having "stereo scanning" or putting them back-to-back so that they achieve full 360-degree coverage?

No luck on any of these map_resolution values: 0.100, 0.050, 0.025. The map breaks in almost exactly the same spot in the narrow corridor with the chain link fence. Interestingly, it does not break in another corridor like it that does not have a chain link fence.

Are you able to complete step 1.6? Step 1.7 is outdated--it is easier to start a blank RViz and add a LaserScan to it with topic /laser.

Thanks, Stefan, for the answers! I'll run the test later tonight and post back soon.

Hey, Stefan--I'm curious: would an IMU fed into hector_slam solve this problem of a featureless corridor? We could buy an IMU now but won't have odometry for at least 3 months due to circumstances. From the source code, it looks like no accelerometer readings are taken, so I am guessing no.

BTW, our maximum range is the default of 60m. It SHOULD be picking up the Honda CRV in the photo, yet it is apparently not from the map. I will do another test run late tonight when fewer people and cars are moving around.

Thanks--when you say "higher resolutions," do you mean making map_resolution = a smaller number than the current setting of 0.100m or a larger number?

I'm guessing you mean lower (0.050m or 0.025m) and that by doing so, the laser can pick up the windows in the white wall (same height as Hokuyo).

While testing our Hokuyo UTM-30LX with hector_slam, I ran into a peculiar problem. Every time I attempt to walk up to or along a chain-link fence, hector_slam gets confused and basically "wobbles" around the position where it first encounters the fence.

So, if the fence is 6 feet long, it basically cuts the 6 feet down to 0ft and only continues mapping after I have passed the section of chainlink fence.

Obviously the laser is occasionally hitting the thin wires of the fence and more often passing between them, and this is confusing the algorithm.

Is there a way to fix this? Perhaps it is by setting the Hokuyo's parameters differently (possibly the cluster parameter) or by changing the hector_mapping parameters...

We have also run into problems where a door opening or closing will break the map (I passed through a door opening it 60 degrees to walk through, and after I walked through when the door swung closed, it bent the map by 60 degrees). But this is not really a problem to be solved, since it is a moving object that just happens to look like a wall.

Thanks in advance!

EDIT: added photos/maps per Stefan's request. We have done five runs just like the above and had the map break at almost exactly the same point every time. The little purple "knot" where the "Always breaks here" bubble points is where the trajectory "wobbles" for a while until I get all the way to end of the walkway, after which it begins mapping properly again (but short about 6 feet).