No pressure or anything, but I’m checking twice a day to hear how you’re gettin’ on with this issue.
Finmark might have been telling you he’s in love with this bot:
She’s quite a looker, that one.
2 Likes
It’s a good thing that there isn’t an enemy submarine at the end of that scan. 
I have every confidence that the two of you will get that figured out.
2 Likes
Thanks - I was just looking at my URDF yesterday and was thinking about making it more realistic. But not sure that that matters for navigation which I think uses the URDF for the tf’s and to estimate clearance. I think it matters more for simulation to get all of the masses in the right spot.
/K
2 Likes
OK - calibration and getting the URDF a bit more correct seems to have helped.
Unlike @cyclicalobsessive, I decided to keep my URDF stylized. However I did try to get the size of the overall robot better, as well are getting wheel size and placement more correct. Also got the base_link between the wheels (at least in the xy-plane).
Here’s what it looks like in RVIZ
Note that I got rid of the distance sensor solid since it didn’t really look like the distance sensor on the GoPiGo3. I just modeled a white slab (not wanting to fool with the actual stadium shape of the real distance sensor).
The body is translucent for Gazebo.
I included a blue slab for the IMU, although I don’t actually have that implemented yet.
When I did the 360-spin in place test, note that the results aren’t nearly as bad as they were.
As I’m writing this up I may try moving the base_link to literally between the wheels (z-axis as well) to see if that helps.
/K
2 Likes
I don’t believe z-axis offset should affect xy-plane.
When you square the bot to a wall, do the scan walls appear exactly parallel and normal to the bot?
Are the scan distance values for 0,90,180, and 270 and the 0+180 and 90+270 distances accurate?
(In Dave’s case, I can see that I didn’t do a good job of getting the LIDAR 0 to line up with the bot 0.)
1 Like
Great ideas - I’ll check.
/K
1 Like
You can attach two LEGO 1x3 blocks sticking out from the front of the bot for a truly perfect square alignment.
2 Likes
Also, is your GoPiGo3 publishing Odom and tf fast enough that the scan frame is getting a good transform? I don’t know how to be certain that each scan has a tf that matches the time stamp (or does ROS interpolate frames?)
1 Like
THEORETICALLY, it shouldn’t.
However. . . .
Theoretically bees can’t fly and theoretically every publisher in ROS should have an active listener too. 
I would try it as I have seen stranger things happen.
1 Like
The z location of the base_link cannot influence anything that operates only in the xy plane, but if a sensor is designed to operate with variable z, such as a distance sensor mounted on a tilt Joint, the z ref becomes essential.
Now there are some other things I can think of that might possibly cause the exhibited variance in scan distance you are seeing. One is if the GoPiGo is not level. The distance forward on a slightly front-low bot will be slightly more than the side distance when the bot has turned 90 degrees, (front and back actually). I think the variance of the cosine at small angles is relatively tiny, but since the walls are quite far, perhaps bot tilt and the z point of the tilt axis would need to be included in the URDF. And there might be some issue of vertical beam width that could cause variance, but I cannot imagine the beam width causing the consistency of distance variation in the rviz display. Also there is a variance in the actual distance measurements for the LIDAR, but I think that would be visible in the thickness of the wall line, not a variance in the wall angle.
Confirming that the 0 degree scan distance is the same as the 90 degree scan reading when the LIDAR is the same distance from each wall is a good test for any angle effect, but measuring millimeters at arms length is also fraught with difficulty for me.
The encoders output 1/2 degree precision? And the I don’t remember what my odometer turn accuracy came out to when I was doing the occupancy grid stuff, but It did not result in a perfect square path. That I do remember. It is possible that without IMU turns and odometry traverses, the scanned walls are going to spin like a bad drunk.
You mentioned location variance; Was it around 5 percent, or really gross variations?
2 Likes
Great idea - I’ll have to clear off my front deck first.
Good question - I don’t know how to check that, but will look into it.
/K
2 Likes
I think I’ve mentioned before that one of my favorite quotes is “In theory, there’s no difference between theory and practice. But in practice, there is.” So your suggestion is a fair one.
As @cyclicalobsessive points out, there are some reasons why the z-axis position might make a difference. I have noted that the lidar doesn’t pick up the far wall always. Finmark has a very slight downward slant (it had a slight upward one, but I replaced the standoffs on the back caster to fix that). I’ve checked the floor - it’s nominally level. Perhaps there is still enough difference. Or perhaps the lidar isn’t quite level. Makes me wish I had built taller walls (in theory they are tall enough 
).
/K
Did I? I’ll have to check.
Great idea - but I’ll also have to make sure that the walls are actually a true 90 degrees.
/K
2 Likes
In ROS (1):
rostopic hz /tf
rostopic hz /odom
rostopic hz /scan
2 Likes
/tf and /odom are about 30
/scan is about 12.65
So the /odom is easily keeping pace with the scan frame it would seem.
Started a new thread for this issue since it wasn’t directly odometry related and this thread is getting long.
/K
1 Like
Interested in what is the effect of one scan at the closest odom, and the next scan at the closest odom when the bot is spinning.
If the bot is spinning at 72 DPS say, with 30 pubs per second, then each odom is 2.4 degrees of spin on average, maybe with some +/- accuracy and some rounding for 1 degree precision of the encoders, and some jitter.
Each scans data is actually spread over 6 degrees when the bot is spinning at 77 DPS, so by the time the scan takes the 719th distance, the bot has actually rotated almost 6 degrees but the LIDAR doesn’t know that.
I’m wondering how ROS is able to use any of the data when the rotation magnitude is large. I have not looked at SLAM or localization yet, but I’m guessing the algorithms have to average out a lot of these realities.
2 Likes
I hadn’t thought about it at that level of detail, but as I do I’m guessing you’re right. I’ll try my spin test again but spin VERY slowly and see how much difference it makes.
I looked at the YTLIDAR spec sheet - it says the scanning is 6-12 Hz (voltage or PWM controlled). Looks like I’m getting the max. So I’d need a better lidar to get any better performance. For this project this will have to do.
/K
1 Like
I would guess the major improvement will be when using the IMU for angles and encoders for distances, but when I was doing the occupancy grid eval, the encoder only path came out quite comparable, so only trying it is going to tell.
1 Like
Then again, there are other possibilities:
- When was the last time you cleaned the LIDAR’s lenses?
- Are you absolutely parallel to the floor? (Or can you adjust the LIDAR itself for level?)
I remember seeing LIDAR images from you a while back that were as crystal clear as a fresh mountain stream. What’s different now?
Don’t give up!
Slightly off-topic:
What IS that display on Dave? I’ve been looking for something like that for Charlie for a while now!
P.S.
How about a nice profile picture of Dave.
1 Like
The picture here is 20 seconds of lidar returns stacked up as I did a 360 spin. If I have it sit in place I still get a crystal clear picture. And I’m fairly happy with this - much better than it was initially (see top of thread). And as @cyclicalobsessive points out - there will likely inevitably be some smear since the rotation of the lidar is slow enough that the robot will shift appreciably between scans.
The lenses are recessed, so they should be OK, and with a moving platform I can’t count on staying level.
For the price point I’m not complaining at all.
/K
2 Likes