Several demos have been run before, in fact, you only need to record the rosbag in the same format as before to run your own package. According to your needs, it mainly includes: laser (scan), gear encoder (odom), inertial navigation (imu), static road signs (landmark) and so on.
Step 1: Verify the data packet
Cartographer provides the cartographer_rosbag_validate program to detect whether the data packet conforms to the cartographer's running format. The official website documentation says that the cartographer_rosbag_validate program is powerful, not only can detect whether the data is complete, but also give a reasonable data format suggestion, but the editor has not found it in actual use.
However, this tool is still useful. Let me say that the most commonly used editor is that you can know the frame_id of each data through this tool. This is very important. Frame_id is the name of each component in the urdf.
[why?]What is urdf? Urdf is a description of the three-dimensional spatial connection between the various hardware of the robot. What is the use of urdf? If you only have laser laser data sources, the function of urdf may not be reflected, but if you have both a camera and a laser data source, you need to display the landmark road signs seen by the camera under the laser map during the slam process, then you need to see the landmarks seen by the camera Convert to the laser coordinate system, and at this time we need to know the spatial posture of the camera in the laser coordinate system (external parameter between the camera and the laser). This urdf is to manually provide the input file of the external parameter. Okay. You may also want to ask: Why should I convert the landmarks seen by the camera to the laser coordinate system? This answer is the function of the static landmark mentioned in the previous article, that is, it is used to quickly locate the robot. As soon as the camera sees the landmark, it immediately knows its own map location and can then navigate and cruise. Can accept some small errors in the parameters provided by urdf, cartographer can correct these small pose errors, but if the external parameters provided by urdf are not comparable, cartographer is not a panacea.
Instructions
rosrun cartographer_ros cartographer_rosbag_validate -bag_filename your_bag.bag
Step 2: Create a .lua configuration file
Cartographer is highly flexible and can configure various robot runtime parameters. This configuration file is written in lua text, and its directory is under src / cartographer_ros / cartographer_ros / configuration_files.
Note: Ideally, a lua configuration file corresponds to a robot , Instead of corresponding to a data packet.
[Problem to be solved]In fact, according to the demo we ran earlier, we can take it directly and need to provide the corresponding map_frame, tracking_frame, published_frame and odom_frame in the lua file. After verification, you only need to fill in the tracking_frame and pubilish_frame. Tracking_frame and pubilish_frame generally correspond to base_link, which is the robot center coordinate system, and the specific functional details are to be added (that is, map_frame, tracking_frame, published_frame, and odom_frame in the program respectively).
Introduction of some parameters:
- num_laser_scans : the number of lidars used, topic type sensor_msgs / LaserScan
Note: If only one lidar is used, the cartographer's topic interface is / scan.
If multiple lidars are used, the cartographer's corresponding topic interfaces are / scan_1, / scan_2. - num_multi_echo_laser_scans : the number of multi-echo lasers used, topic type sensor_msgs / MultiEchoLaserScan
Note: same as num_laser_scans, only different types of radar data are used - num_point_clouds : the number of point cloud transmitters used, topic type sensor_msgs / PointCloud2
Note: same as num_laser_scans, only different types of data are used - use_landmarks : whether there is landmark data source input
- use_nav_sat : Whether it is useful GPS data (I haven't tried it yet, I would love to try it)
- num_accumulated_range_data : It is to accumulate the laser data of several topics as a complete scan and send it to the front end of cartographer. There is also a parameter num_subdivisions_per_laser_scan and num_accumulated_range_data parameter. For per_s, num_accumulated_range_data is to accumulate a few per_s.
[why? ]Why divide the laser into several parts and then accumulate them again? This starts with the 2d laser transmitter. The 2d lidar has only one launch point, but why can it scan the entire 2d plane? Because this device has a high-speed rotator, which can drive the launch point to rotate at high speed, and then form a 2d plane, how does this relate to the above problem? For example, a laser 2d plane may be composed of 360 laser points (we call a frame of data), each laser point is 1 degree apart, due to this rotating imaging principle, the order formed between each laser point has The order is different, so the timestamp of each laser point is different, so how does this relate to the above num_subdivisions_per_laser_scan parameters? We know that the robot is moving all the time. If the robot moves fast, the laser frame may not be scanned, and the robot has moved to another location, so that the robot obtains a frame of laser data at multiple positions. Obviously such data is problematic (this problem is the movement distortion of lidar), how to solve it? It is to correct each laser point of a frame of laser with the current pose of the robot (usually use odom and imu to correct) , Because their frequency is relatively high, can reach 100hz per second), then this seems to have nothing to do with dividing the laser into several parts? Yes, it ’s irrelevant. This is because we only considered the case of only one lidar. If we have two lidars working at the same time, the data of the two lidars can be aligned in chronological order after being divided into several parts. Why? Want to align? Why do you say it?
The parameters in the remaining options will generally not change, but in fact some still need to be changed, see the case. Attach my lua file
Step 3: Create a .launch file based on your robot
According to the previous demo, try to configure your urdf (you need to publish tf without urdf) and see if the frame_id of your tf tree laser, imu, odom corresponds correctly in urdf or / tf. tracking_frame and pubilish_frame are as good as base_link. I do n’t think there is any other problem. Attach my launch file, Good luck!
Run demo screenshot
