Back to the wobot

Had a torrid time with my health for a few months, but seem to have turned a corner and back on project. The new platform wobot2 is progressing slowly. The idea was to use an iRobot platform as size and level of integration with ROS was very attractive but someone gave me a robomaid a totally different vacumn robot.

Oh well plans change and it will give me something to do. Plan is to use the motors/encoders, proximity sensors  and the physical platform but gut the rest.

Over the xmas break there was a simply outstanding deal on MS Kinects which just could not be refused, so wobot2 will have a kinect as range sensor, I am quite excited with that and making progress.

The Beagleboard is currently dumped but maybe feature again depending on how  my cheap second hand netbook handles the Kinect. the kinect over USB along with USB wifi is simply beyond bandwidth capabilites. I am not sure if this is a ubuntu kernel limit but the system layout is a single usb hub and trying to get the usbgo port running well all too much trouble in the end.

The netbook was up and running Ubuntu and ROS in short time ( not much source compiling  as needed for the ARM builds on the Beagleboard) no changes in boot processes to contend with and config and running ROS from a proper keyboard screen in a windowed environemt so so much easier. I will consider the beagle board for motor cmd_vel/move base if the netbook is under resourced but I may save up for a better laptop/netbook first!

Progress has been slow but my health has improved. I got the kinnect tuned for the netbook. Yhis runes a atom with a single core with hyperthreading.

So with 1.5 Gb of ram with the kinect drivers up and the nodelets for pointcloud_to_scan running in the same nodelet space I’ve got 420Mb free and system utilisation is better. So that’s using a launch file with the nodelet manager the same for the kinect driver and the throttle / pointcloud to scan.

System utilistion has dropped 40% no change in user % but I also noticed that network traffic is down on the loopback interface.

I also dropped the windows manager to xfce which also helped. You install it and then when you log in change the session to xfce.

I am running diamond back. I was watching the kinect session of roscon 2012 and fuerte will have a better splitting of the drivers and pointclouds processing. I’ve tried this om diamondback and found that there was considerable lag in the pointcloud to scan conversion so even 1 Hz update rate was poor and probably not updating for slam or gmapping to work.

At this stage my old pc started dying and has just about finished itself off. So been saving for a new PC for off robot processing.

Got some new parts on order for the netbook a new internal wireless card and a USB 3.0 pc express card. USB 3.0 will be used for a usb drive to lessen the drain the battery. Some of the USB 3.0 pen drives are very quick so it’ll be used as a cheap alt to ssd drive. The internal network card will free up a USB2.0 port for the arduino’s.

The base is progressing, I had to rip out almost everything and then devise new motor mounts. It;s been a hack but nearly there. Now need some long M2 self tapping screws.

Minoru Stereo Webcam

I’ve got this hooked up via ROS on a test rig. Seems to be very accurate at 50cm to a 2M.

Point clouds are coming off the stereo_proc and rviz is looking good. The camera image and pointcloud superimpose on each other which is neat when you are trying to work out object image/range….good one guys!

I got the minoru from http://www.firebox.com in the UK for quite alot less than many other shops.

The http://www.minoru3d.com domain seems to have been surrended since I ordered the device and receiving. So updates etc maybe an issue. If you do an update from windows 7 minoru applets, you get something but I’m not sure about that source.

The minoru seems to work fine with uvc_camera (ros stack umd_camera) and the stereo_image in image processor/image view stack package.

I’m using maverick on the base pc/test rig and ros diamondback.

Had some funny issues after installing some extra stacks which looked like cturtle compile errors, so followed the errors on ros.org and that seem to be addressed by some answers that tully posted. Something along the lines of wrong md5 sum, expecting “md5 checksum “, got “md5 checksum for messages in stereo_proc or stereo_image.

If you use the theora transport network bandwidth is greatly
reduced. append “transport:=theora” to the rosrun image_proc image_proce image:=/camera/image_raw transport:=theora.

‘ve been playing with opencv via the ros packages. Quite enjoyed that, but also tried I tried the windows 7 install of open cv 2.31 and code blocks, and not had any success. I’m not sure about going upto visual studio c++ as it’ll wreck my laptop, it’s not exactly purring MIPS.

Next job is to obtain a 2D Laserscan message from the 3D stereo pointcloud, for gmapping gslam.

Looking at the various implementations of openni and kinect there’s a pointcloud to laserscan converter. But it’s nodelets and I’m very unsure of what the inputs are, and it’s in c++ groan. I can get the x y z points out easy, using some example code I keep loosing the data. Seems to be related to boost libraries so will have to learn some more.

So this is more main focus for a while.

so far the elektron_kinectbot package looks the most useful from a coding perspective. It includes some filters in the launch file.

Trying to work out the various transforms and frame ids for what does what ? Beyond me at the moment.

The Field of View for the minoru seems to be about 40 degrees, so new lenses are required, or I mount on a servo.

I had some silly things with the sentienceros minoru webcam instructions and v4lstereo, with the second video device

also check the /dev/video* they can be non contiguous, ie /dev/ideo0 and /dev/viideo2

Update

I had a long period of downtime on this, health issues. The minoru is useful and I was able to convert pointcloud to laserscan customising the pcl to scan as a nodelet. There were some shortcomings range etc probably a bit low for proper slam, I was in the midst of changing to a bigger robot platform and a MS Kinect came up at $8 more than the minoru……..so have a kinect now and up and working in 5 minutes.

The infra red projector on the kinect is a big improvement over the passive minoru just running rviz on the kinect you can see the improvement in range and resolution. Out of the box driver support is excellent. Tilt position is handled. Thanks to all involved in that not just the kinect but all the other plumbing needed GOOD JOB!!!fancy a year ago getting a range finder for $88.00…..dreams.

I felt a bit guilty using others code but that is what ROS is about!

 

 

 

 

Sharp GP2Y0A02YK Distance Measuring Sensor

References

data sheet: http://www.robotgear.com.au/Cache/Files/Files/33_GP2Y0A02YK0F_ss.pdf

methods for linearisation: http://www.acroname.com/robotics/info/articles/irlinear/irlinear.htm    l

there is an offiical sharp product guide which also defines this method but I cannot find it! Most of these guides are for an older product so make sure you reference and do the maths for the correct  sensor

More help:

Arduino.cc has a lot of guides for implementing and coding sensors and the forum is a gold mine!

Robotics Internet shops often have help and community forums they are also a good resource!

The Sensor

This is the 20cm – 150 cm range sensor I got mine from junon.org ( i have no interest but the price service and delivery were good! and that’s worth a mention ).

Overview

You feed 5V in ,and connect the sensor out to a adc, (analogue to digital converter)  pin on the arduino. The output is inversely proportional to the range sort of. The output is not really linear (straight line ) but there is a published method for doing this, which made my head ache remembering electronic control theory courses. That was a long time ago

Basically this sensor is an LED light source and a measuring unit. The light source is infra red and the measuring unit is designed to limit issues you might have with a straight light sensor. Notice I said “limit”.

Some surfaces are better than others, white A4 paper excellent, not good surfaces to have around, eg shiney black computer case is very stealth, brown cardboard boxes. Angles such as very acute even on white paper is not very good. Passing into light/shadowed areas esp sun light. Glossy dark surfaces are horrid.

Corners also give some issue, as there are reflections but i found you can code for them as they have a distinct signature well usually!

Calibrating and Coding

There are some good tutorials on the sharp range of sensors and there’s clear instructions on how to calibrate and the maths required to determine range from output.

So you need the data sheet for the sensor, it gives you a guide to input output and the relationship between output and range.

However this is only part of the story.

Noise

Like many of the sensors so far, simple code no other devices integrated the sensor is pretty good, as soon as you start arduino code and other devices, driving motors and servos with PWM noise increases, so you need to do some filtering. Now there are other methods for reducing noise and these include using shielding, keeping the wires away from other wires and sources of noise, ie motors servos and away from PCB’s . all these help but the wire only has to move a bit or you increase motor current and things got suddenly get worse. So you may need another form of noise filter

There are a couple of ways you can do this, the two I tried were:

take a number of measurements, The sensor samples at about 40  KHz I found that 20 samples was about right.

1. mean the 20 samples and then reject top and low 15% and re-average  ( use this if you are resource limited,ie low power arduino or a busy Mega)
2. Standard deviation reject readings outside 1 SD and re average the remaining.

If too many readings are rejected  reject all and read again.

This worked ok, but still quite inaccurate when used on a robot, hummmm!

I found the mean and reject 15% method better if the robot was moving, but stayed with the standard deviation as this may be required in the future for kalman or other forms of advanced navigation and localisation.

I am using  a Seeeduino Mega and I do not plan to be making many readings on the move, I prefer to stop and scan. I would not consider implementing SD on a less powerful/resourced arduino.

Calibration

Oh well inaccurate, time to calibrate again. Well I tried doing this a several ways but the most effective was disconnect the output of the sensor and measure with a digital multi meter. Using the ADC was just too hard even with SD.

Put some basic code on the arduino which just measures ADC disconnect everything else, make sure your power source is stable and at your nominated voltage level ( fresh batteries)

You get a nice perfect piece of plain white A4 paper. It needs to be perfectly upright and it needs to be square to the sensor. I mount some on a piece of chipboard. Carefully move the paper across the range of the sensor, taking measurements of the DVM and the range.

Plot in excel/calc etc and check against graph in the data sheet it might differ a bit but should be quite close in terms of voltage/dist and should not have to many bumps. If you have bumps go back and measure again.

ADC Conversion

The Analogue to digital converter will produce a digital number that you need to convert back to a voltage. Check the data sheet for your processor/adc. for the arduino i have the ADC ranges over 0-1023 and max voltage in is 5V.

One ADC step is 5V /1023 or 5V/1024

So Vin = ADC reading * ( 5 /1024)

If you are using tables you do not necessary have to convert ADC reading to Vin.

Tables or Calculation

Once you have the measurements you have a choice method to determine range.

On way is to use a table,

setup two arrays one for Vin (voltage from sensor output) and R corresponding range.

if vin is between Vin[next]  and Vin[next +1] then range is between R[next] and R[next+1]

else next +=

loop

I do not think this sensor is worth utilising unless your range resolution is greater than 5cm and better at 2.5.

So this adds issues over the size of the arrays in low power/resourced arduinos.You will never get perfection in electronics and whilst a great deal of effort might be  expended in calibrating and coding your range finder the surfaces you might have to measure off might well be awful.

Calculation

Making a non-linear graph linear

The various guides to using the sharp sensors state a method for making the graph linear and calculating the gradient and konstants. Fairly easy and if you have plotted the graph both excell and calc will find the values for you. However i did some checking of the linearisation and was not happy with the results.

At this stage I was trying to extract objects from the ranging data and I needed the accuracy to be slightly better than it was.

So I did some tests and some research and looked for some curve fitting methods.

First Attempt “sliced straight lines”
i tried because it was quick and dirty was to plot the data and obtain series of best fit lines and change the gradient and offsets
( y = mx +c ) across the graph, this was easy but the accuracy was a bit off still. So having spoken to my son who’s much better at maths than me I looked for a curve fitting solution.

Second Attempt Curve Fitting

Ok so time to dust off the maths, actually I cheated and found a curve fitting site on the Internet. zunzun.com takes your data and when you submit is it asks for some parameters such as algorithm.

(You need to submit data as columns)

I’ve got the plot data and submitted to zunzun.com using the “Marc Plante’s Custom Quadratic With Linear Decay And Offset” , that’s in 2D polynomials, Theres a submission of text data and some options

Data is prepared x for vin and range cm as y ( I’m not going to even try and transpose the formula)

zunzun.com returns a report with a formula and the values for a really good curve fit. I used “scilab” a matlab type engine to check data and curve fit which showed some glitches in the data, corrected resubmit and got this back

y = ( (-b + (b2 – 4 a (c – x))0.5) / 2 / a ) / (d * x) + Offset
Fitting target of sum of squared absolute error = 1.0087491765917592E+02
a = -1.9035009792227321E-10
b = 2.2117131291348640E-04
c = 4.9075752602887955E-02
d = -3.7454750379930721E+00
Offset = 1.2109501295599825E+03

DO NOT USE MY VALUES, I found that small changes made very big differences

arduino code is something like this,

range_value is the result of the noise filter.
if ( range_value >=  0.35 && range_value < 2.4     ) {

float   a = -1.9035009792227321E-10;
float b = 2.2117131291348640E-04;
float c = 4.9075752602887955E-02;
float d = -3.7454750379930721E+00;
float offset = 1.2109501295599825E+03;
float x = ( float ) range_value;
float y = 0;

y =   ( (  -b +  sqrt(sq(b)  –  4 * a * (c-x) ) ) /2    / a )  /  ( d * x ) + offset ;
range = double (y);
if (range > 150) { range = 150 };

The range finder is pretty accurate now, I’m using a seed meg and the code fits well into my resource budget. Again it is not suitable for a low power mcu.

I would not use my values, even a small change will throw the graph way off , use your own.

Tests

Seem to be getting close to -+ 1 cm from ideal surfaces measurements in near to medium range and acceptable out 130 +- 2cm as the scan passes a surface the responses map very well with the angle and distance the object is to the robot.

Conclusion

Idealising filtering or curve fitting is not going to help if the surfaces are not friendly. I did notice in a ROS/willow garage video alot of white panels around desks and started laughing rather loudly, as I knew why! Legs dark voids……

When I tried this, I was trying to extract objects from the range finder data and I needed something more accurate than I had. The curve fitting did help, it was lot better than 5cm tables, and I ‘m sure better than the linearisation, I did n’t actually test with code but doing the maths and spreadsheets I did some graph lookups on data and was n’t happy. But the curve fitting tests actually showed me where i needed to go back to my calibration and re check the vin/range  data. If you are using small occupancy grids you need finer resolution for sensor data. If you are trying to find gaps corners etc and navigate through them reliably then you need the best accuracy you can get.

You do not need to implement the curve fit or filtering on the arduino or even the robot, pass it through to a base PC via bluetooth / wifi and  use the PC ‘s power! I have n’t tried alot of maths in arduino/processing package but python is quite nice for maths. f I need to I will, but at the moment the arduino is well resourced the code is bedded in,  and I want a local range check for my environment.

IR Range finder on ROS

I do not know how well the sharp will stand up for what I want to do in ROS, I’m thinking that the more range data the better for localisation to work properly. I have the range finder mounted on a servo and the 180 degree sweep takes 19 seconds. I am in no hurry so to speak but where I have areas of low reading density i  notice the maps really skew even though odom and range are fairly good.  As I’m not into the maths I am finding it hard to work around the low data rate and usual robot sensor errors. So I’m planning a stereo cam.

pirobot have a demo of pml poor man’s laser doing obstacle avoidance without a map on you tube.

Update rangefinder and ROS

Basically data rate is too slow you need a full update 1cm/1second for gslam to work or your maps are not good!

 

rospy rospython and message structures

In ROS there are some important tutorials which only have cpp examples, and I found that trying to recreate them in python was a time consuming pain especially, as some did not work, or tring to figure out what needed to be changed due to package variations from convention. there’s a quirk when you setup a publisher/listener and then publish or setup a structure where the tranform tree seems to be back to front.

the 2 which cost me alot of time were:

• LaserScan, and visualization markers

I did a several things in both cases, do the tutorial in cpp then try a python equivalent then look for working python code. Then try python code which did n’t work…..groan…….then repeart the later alot. Still always say you learn more when things don’t work first time.

LaserScan

There were a couple of nearly working examples in the ROS Packages the ones I remember ardos and arbotix thankyou you guys. These were licensed I think with GPL or similar. I acknowledge that he full source can be found at http://www.ros.org.

Picking through the package code wcan be a bit of a ordeal but the message structure is quite easy. I think the biggest issue is getting the transform frames correct. Typically base_link is parent to base_scan. Scan base_laser seem to be used in other packages but the tutorials are base_link and base_scan.

You will need an odom trasform to base_link and a static transform between base_link and base_scan. These are covered excellently by the python tutorials.

scan = LaserScan()
rospy.loginfo(“in scan pub” )
scanPub = rospy.Publisher(‘base_scan’, LaserScan)
print “trying stamps first header then scan_now”
# had issues with getting scan_now and the header to work
scan_now = rospy.get_rostime()
scan.header.stamp = scan_now
print scan.header.stamp
scan.header.frame_id = “base_link”
scan.angle_min = config.radar_rad_start
scan.angle_max =  config.radar_rad_finish
scan.angle_increment = config.radar_rad_inc

# be careful with scan_rate i tried to set this as I thought it should and it was rejected so it got set to 1 and worked!
scan_rate = 1
scan.scan_time = scan_rate
scan.range_min = 0.20
scan.range_max = 1.500

# scan.ranges is a list ( or array)

scan.ranges = [config.range_buff_index]

print “check scan.frame”
print scan

# i have a problem with the usb buffers on my arm/ubuntu controller on the robot which seems to drop the range data
# the empty range data was causing gmapping gslam to crash so checking to make sure I have range data

try:
if scan.ranges  != “”:
print “scan.ranges is not empty”
# this is hard coded for a full 180 degree scan,
if len(scan.ranges) == 181:
print “scan.ranges contains 181 readings”

try:
scanPub.publish(scan)
except Exception ,e:
print “exception scan publish , err =”,
print e

except Exception,e:
print “empty or missing data in scan.ranges”

Visualization_Marker

this allows you to add markers in rviz, I use this to add a waypoint marker so I know where I’ve been. but you can also add coloured shapes.

There’s a Berkeley ROS package or utility called rll_utils.py which when i looked at it used rospy messages wrapped into cpp ,  So you have to do is add a ;line to your manifest (cturtle) and import the message type and determine the message structure. I  had issues with the ones in the berkley util, so I did the cpp tutorial and worked it out eventually. Thanks Berkeley. The package is found at http://www.ros.org  and the Berkeley Repo.

on cturtle you need to add a line to the manifest.xml in your package.

<depend package=”visualization_msgs”/>

and then rerun rosmake.

I think in diamondback,  the visualization markers have been included in a standard messge type, you need to search and make sure you add the correct message type.

The message structure example is below, but you should try the cpp totorial, and also setup  rviz. You need to change the package name and in real life change the frame id from my_frame to something more useful like map or odom.

ooops the message structure is at the botom of this post!!!

Text Markers

I use pyside and obtain the odom x y position and use the text marker to insert a way point number into rviz. You can also resbag record this topic as well so it plays back for mapping etc and the waypoint gives me a much better idea of where I am or where I am not!

_type = Marker.TEXT_VIEW_FACING

this allows the text field to be populated

marker.text = str(index)

index I increment along with

marker.ns = “basic_shapes”
marker.id = index

the different marker id creates a new marker in rviz.

The text size is set by

marker.scale.z

you can

rostopic echo visualization_marker

if the topic is listed, but not echoing the message something is wroing with your messsage structure use try except blocks

message structure

python code……..rosrun <package> <pythonfile>

# minimum headers

#!/usr/bin/env python
import roslib
roslib.load_manifest(“wobot”)
import rospy
from visualization_msgs.msg import Marker

_id=0
_type = Marker.CUBE
r = 150
g = 1
b = 0
xscale = 0.10
yscale = 0.10
zscale = 0.50

marker = Marker(type=_type, action=Marker.ADD)
##marker.header.frame_id = point.header.frame_id
marker.header.frame_id = “my_frame”
marker.header.stamp = rospy.Time.now()
marker.pose.position.x = 0.0
marker.pose.position.y = 0.0
marker.pose.position.z = 0.0

marker.ns = “basic_shapes”;
marker.id = 3;

#pointxyz
marker.pose.orientation.x = 0
marker.pose.orientation.y = 0
marker.pose.orientation.z = 0.0
marker.pose.orientation.w = 1

marker.scale.x = xscale
marker.scale.y = yscale
marker.scale.z = zscale

marker.color.r = r
marker.color.g = g
marker.color.b = b
marker.color.a = 1
marker.id = _id

marker.lifetime = rospy.Duration()
pub = rospy.Publisher(‘visualization_marker’, Marker)
pub.publish(marker)
print marker

gmapping gslam and magnetic variance

This has been a toad,

I’m using a sure electronics compass, a sc-503 from memory. It’s a cheap but pretty good compass using an i2c interface with the arduino. The basic i2c and arduino sketch for the compass provides a solid bearing. On the robot with the sketch fully loaded there’s a bit of noise but -+ 1 degree.

But indoors,  compasses seem to be subject to other magnetic influences (groan) it took me a while to work that out…..the fridge, reinforced concrete,  power outlets the old wireless modem…..all throwing the compass out. Every now and again the robot will chuck a twirl but I think that is a low arduino battery issue.

Really ROS seems to like pure output from the wheel odometers, for the z rotation but with my robot and the arduino code I’ve got working that’s a pain. The odometers are not too good, reliable on 2cm resolution but not 1 cm.

With differential drive the resolution is too poor, So I’m staying with the compass.

I think 1 degree error over 1 M is 1 cm in the y plan(sideways), (x =forward) , but over 6 M I worked out the error to be a crash. So the method I’ve been using is to stop the robot when heading/bearing differ by a few degrees and stationary diff turn onto course. To make more precise turns I’ve used the range finder to re-position the robot of 2 walls and then make more precise offset turns and then re-position off 2 walls again.

So the challenge is to get the compass less influenced by the bad influences.

Method

I mapped out the magnetic variances with a normal compass every 10cm . I’m getting swings -+ 20 degrees in specific areas, which is where the reinforced areas seem to be. the fridge is -6 and as long as I’m not too close to the mains outlets they are ok ( maybe trunking ).

The worst area is at the end of the 6M corridor there’s a right angle turn and that’s quite bad > 20 degrees and very patchy. As there’s a nother 90 turn there through a doorway which does not open properly I need to get that right.

Raising the compass

I lifted the compass mounting so it’s 40cm off the floor. any higher on my chassis is not practical and does not seem to benefit much. I  Re-Mapped at that height,  the swings are reduced to +- 10 degrees and fewer areas, so that’s a great improvement.

Degausing

I tried a bit of degaussing, which did n’t do too much. Probably need a lot more current and wire for that to really help.

ROS gmapping gslam parameters

I tried playing with the ROS pararmeters in gmapping and increasing the _stt:= the rotational error theta/theta that did n’t seem to help too much. My walls got more curved. So I did some basic maths now I’ve remapped the magnetic hotspots and theta/theta, I am assuming the error is +-err/360 and _sttt:= less than default of 0.2      It seems better !!! gslam is giving me a much better map…..

Work todo

So next change is to use the y value from the odometry and set a compensation on the compass between the worst areas.

I do not think the odometry is good enough to reduce the errors to zero, but to +- 5 degrees should help.

The approach is apply 0.5* compemsation needed  So if there’s any error in position  I’m not applying the full 10 degrees in compensation on an area of 2 degrees swing or 0 degrees so the error applying undesired compensation is only 5 max.

The gyro

I’ve got a cheap gyro and with the compass it’s possible to detect the areas of -+ 10 degrees swing if by simply polling the change in bearing and gyro rate and simply if delta compass > 5deg/s and delta gyro < 5deg/s hit the outer edge of the bigger fields.. I’ll see if I can use that to apply and remove the compensation more accureately along with odometry.

I think I’m getting back on track!

ROS calling WOBOT, ROS calling WOBOT!!

This is a new blog, detail is in the about tab….

I am using ROS and an arduino and making slow progress, largely my health and some silly mistakes

I would dearly have avoided some of the time wasting so some notes!

Biggest one to date!

ROS Tutorials RobotSetup

http://www.ros.org/wiki/slam_gmapping/Tutorials/MappingFromLoggedData

gmapping errors

there are a series of similar errors which make the gmapping not work.

In the tutorials and in transform troubleshooting you slowly get the jist.

It is common to hit issues at this point and the responses for help have a common theme! for me one answer nailed it, you must be sending all transforms continuously!

Yeah!

Ok now the rest of it

Timesync

Make sure all the systems are time synced,for some reason the beagleboard was using UTC and often reverts back to it. So

run tzselect (contained in tzdata apt-get install tzdata) from the command line and follow the menu options.

I use the command line tool ntpdate to sync with the time server,

install via apt-get install ntpdate maybe a default package.

the beagle board will loose the RTC when powered off for too long so I always run this before starting the ROS nodes.

ROS will discard old tranforms as they are time stamped by the publisher node, so when broadcasting between different linux systems if there is a time difference mesaages such as transforms will get discarded. The default for time stamps to be considered is about 10 seconds. Differences may also be due to latency so so time sync is important.

I believe all ROS systems should use the same tz and all use utc or local time. when you run date from the command line you should see either UTC or local time, i had issues when the beagleboard showed 2 times one UTC and the other local. running tzinfo fixed this.

ntpdate  with the local ntp server pool for me that is:

ntpdate au.pool.ntp.org

roscore restart

before each run either recording or playing and certainly if using gmapping stop restart all the nodes and services  ESP roscore and gmapping rviz nav_view make sure you know when you should be and should n’t be publishing static transforms.

make sure you have the static transofrms started on record and stopped when playing the bag file

Record bag file

ensure bag file is correct, for some reason

rosbag record -O fielneame /tf /base_scan did not work, missing base_scan messages,

so recorded with

rosbag record -O fielneame  /base_scan /tf

you can check a rosbag contents with rosbag info filename.xxx look for the base_scan and tf and see how many messages of each are within

So a good idea is to make a short record, stop run rosbag info on the file if everything checks out restart recording. Better than driving around for an hour only to find the bag file is missing data.

playback

From the tutorial you need to set the parameter for sim time !

when you play back, use –clock and if needed –pause

rosbag play –clock filename.bag

or

rosbag play –clock filename.bag –pause

restart roscore and gmapping every time or you get errors on play in gmapping tf_old_data

NB rosbag play , set the sim time param……see the tutorial

Transforms

ros answers has lots of similar questions when folk first try mapping.

you need a static transform which is covered in the tutorial tf pub and listener for base_link to base_scan

you need an odometry message and transform which is covered in the odometry tutorial again make sure your names for the messages and transforms match

odom and base_link for some other robot may have different names.

if your mapper is not running you should see odom -> base_link -> base_scan

if mapper is running map -> odom -> base_link -> base_scan

there are a variety of tools for viewing and diagnosing the transforms

rostopic list

rostopic echo <name of topic>

eg        rostopic echo tf

rostopic echo odom

rosrun tf view_frames, and repeat and then evince frames.pdf

rosrun tf tf_monitor odom base_link

rosrun tf_echo odom base_link

also rxgraph and rxconsole

tf view_frames make sure the transform tree is correct throughout the whole playback,  I had a proper tree sometimes….other times two trees    map->odom     and another base_link ->  base_scan.

you can speed things up by using the rosbag play <file_name.bag> -i switch but this would not reveal problem where the transforms are missing intermittently.

on playback make ure you close down all the rosnodes and services you started for making the bag file esp the static transforms.

some documents or answers state you need  a transform containing base_footprint -> base_link, that’s easy if required either coded or using the command line tool static publisher

I have found that after starting stopping bag files and roscore it is often a good idea to restart rviz.