0
$\begingroup$

Rosanswers logo

Hello

I gave a question regarding using some data from my sensor package. I have a sensor package of IMU, Laser rage finder and Camera in my robot (its actually electric wheelchair).

For my robot localisation Im using only individuals laser scans and amcl. But my amcl jumps and my results are not so good. For example when Im calculating some parameters like velocity or distance to some object the results are not so good. Im using IMU data only in for the ICP in the laser scan matcher package. But for other purposes not.

So my problem is how to improve the results?? For example for my linear velocity parameters im using exclusive the amcl pose. But how to improve that using IMU data or for example extended kalman filter. I dont have any odometry. My odometry is all based on the laser. In that way is my pose estimated, only using laser and amcl.

So how to improve the robot heading, motion estimation based on the sensor package I have. So with laser scans, IMU and camera (for the kinect), how to get a better results in sense of motion estimation, heading, and obtain some parameters like linear and angular velocity. Any help??

Thanks

Originally posted by Astronaut on ROS Answers with karma: 330 on 2012-11-26

Post score: 1

Improve this question
$\endgroup$

3 Answers 3

Reset to default
0
$\begingroup$

Rosanswers logo

Provided you have a high update rate LIDAR (or your robot travels relatively steady and slowly) you can try hector_mapping. As can be seen in the video on the linked page, that can work pretty well while using no odometry at all. So far I had pretty positive feedback by numerous people using it on robots without odometry. The "localization only" mode isn't implemented right now, but having localization through SLAM is probably better than not having localization at all :)

Alternatively you could also try to fake odometry for AMCL either by using the laser_scan_matcher, by using imu data and maybe also desired velocity commands. The latter essentially means generating odometry by converting your cmd_vel commands to fake measured data. This might or might not improve AMCL performance, depending on how closely your robot can follow the motion commands you provide.

Originally posted by Stefan Kohlbrecher with karma: 24361 on 2012-11-27

This answer was ACCEPTED on the original site

Post score: 4

Original comments

Comment by dornhege on 2012-11-27:
Here comes the hugely overkill approach if you really need localization instead of SLAM: Use hector_mapping to produce the odometry transform and feed that into amcl.

Comment by Stefan Kohlbrecher on 2012-11-27:
Now that you talk about it, hector_mapping actually can write out odometry using the undocumented "pub_odometry" parameter, which leads to odometry getting published on the "scanmatch_odom" topic. Feeding that into robot_pose_ekf could work (never tested it though)

Comment by Martin Günther on 2012-11-27:
Hehe, "hugely overkill" describes it pretty accurately... nice to know that hector_mapping can do it, though! +1 for the idea of using the desired velocities, and for suggesting hector_mapping

Comment by Astronaut on 2012-11-27:
so i can use hactor_mapping package , than publish odometry on that topic. And than feeding it into robot_pose_ekf. So I will use hector mapping and robot_pose_ekf instead of using IMU and AMCL? OR I understand wrong??

Comment by Astronaut on 2012-11-27:
Im bit confuse now. So what is the difference between using hector mapping + AMCl and hector_mapping +robot_pose_ekf. I get a bit confuse. Can somebody explain to me, please?? Or should I post that as a new question??

Comment by Astronaut on 2012-11-27:
And also Martin said to use robot_pose_ekf if I have access to the wheel encoders. But I already said that I do not have any encoders. I do not provide such type of odometry. All is laser based.

Comment by Stefan Kohlbrecher on 2012-11-27:
What you should try first is just hector_mapping, to get an idea of how well it works for your robot. What would also be possible is generating odometry using hector_mapping and feeding that into robot_pose_ekf along with your IMU data, which in turn generates fused odometry for AMCL.

Comment by Astronaut on 2012-11-27:
Ok. Thanks. Is there any tutorial or example how to use robot_pose_ekf and IMU with AMCL??

Comment by Astronaut on 2012-12-02:
@ Stefan Kohlbrecher I do not understand you. If It is possible to get the odometry using hector mapping and feeding that into robot_pose_ekf along with your IMU data, why I need than ACL?? With EKF robot pose I will have my localization. Why in turn generates fused odometry for AMCL??

Comment by Astronaut on 2012-12-02:
But Hector Mapping is already using a EKF in the navigation stack. Why to use is than again robot_pose_ekf ??

Comment by dornhege on 2012-12-02:
robot_pose_ekf does NOT do localization, it only fuses odometry/imu/etc. readings. Also hector_mapping does not use robot_pose_ekf internally (AFAIK). The point of putting odometry from hector_mapping into robot_pose_ekf is to fuse your IMU reading with that.

Comment by Astronaut on 2012-12-02:
But looking at the published paper http://www.sim.informatik.tu-darmstadt.de/publ/download/2011_SSRR_KohlbrecherMeyerStrykKlingauf_Flexible_SLAM_System.pdf it is clear that navigation subsystem is based on EKF.

Comment by Astronaut on 2012-12-03:
But as in ROS wiki documentation said robot_pose_ekf implements an extended Kalman filter for determining the robot pose. That is what Im looking for. An accurate pose estimation as my amcl "jumps"

Comment by dornhege on 2012-12-03:
Sorry for getting confusing: There are two different things: hector_mapping and robot_pose_ekf. hector_mapping will provide SLAM (map + pose). robot_pose_ekf takes position estimates and applies an EKF to it. The difference is that hector_mapping uses laser scans for feedback.

Comment by dornhege on 2012-12-03:
This should give you way better estimates than just using robot_pose_ekf. Maybe it's best for you to just try hector_mapping now and if that works continue from that.

Comment by Astronaut on 2012-12-03:
So hector mapping take as input laser scans and IMU and provide SLAM, The robot_pose_ekf takes as input also laser and IMU and provide with estimated robot pose. So Which approach gives accurate robot pose??As my problem is to estimate more accurate robot pose. What mean laser scans for feedback?

Comment by dornhege on 2012-12-03:
No, the robot_pose_ekf does NOT take laser. That is the difference between the two and the reason why hector_mapping should give you more consistent estimates.

Comment by Astronaut on 2012-12-03:
So I do not see any reason to use robot_pose_ekf . Because my sensor package consit of laser, IMU and camera. I do not know if robot_pose_ekf can givemore consistent estimates fusing IMU and the camera ( visio2 package).

Comment by dornhege on 2012-12-03:
Well robot_pose_ekf claims to be able to fuse IMU and visual odometry. That should be a use case for you, but I never used that.

Comment by Astronaut on 2012-12-03:
Im not clear with robot_pose_ekf . How will be build tha map than?robot_pose_ekf give the estimated pose but what about localization in the map?? How to provide with the map , to localize that estimated robot_pose_ekf pose in the map??

Comment by dornhege on 2012-12-03:
That is what amcl or other localization approaches are used for.

Comment by gleb on 2016-10-04:
Hi, I want to use amcl with odom from hector_mapping combined with imu_data, but I am not able to get it running. I get tf errors, since I am missing tf from map to odom and from odom to base_footprint. How can I feed hectors odom to robot_pose_ekf and make robot_pose_ekf work together with amcl?

Improve this answer
$\endgroup$
0
$\begingroup$

Rosanswers logo

Do you have access to the wheel encoders? If yes, I would propose using the robot_pose_ekf package.

Edit in reply to comment: The EKF's job is to fuse several independent sources of information, in this case wheel odometry and IMU data. Since you only have IMU data, there is nothing to fuse; using the laser_scan_matcher, as you seem to be doing, is probably your best hope. Still, as @Claudio writes, you're in for a rough ride without wheel odometry.

Originally posted by Martin Günther with karma: 11816 on 2012-11-26

This answer was NOT ACCEPTED on the original site

Post score: 2

Original comments

Comment by Astronaut on 2012-11-27:
Is it possible to use robot_pose_ekf only with laser scans and IMU??is that better estimation than an amcl???

Comment by Astronaut on 2012-11-27:
Im using laser scan matcher package. and also amcl. But still the results are not satisfied.

Comment by Astronaut on 2012-11-27:
so amcl is using the laser scan matcher topics???

Comment by Astronaut on 2012-11-27:
So you suggest to use robot_pose_ekf and laser scan matcher ?? At the moment Im using amcl node and laser scan matcher.

Comment by dornhege on 2012-11-27:
AFAIK robot_pose_ekf doesn't do any scan filtering. It just "merges" probability distributions. You best choice would be to use laser_scan_matcher to provide an odometry transform and pass that into amcl. Alternatively if full SLAM would be OK, look at hector_slam.

Comment by Astronaut on 2012-11-27:
but Im using amcl and laser scan matcher. But the results is still not satisfactory.

Comment by Lorenz on 2012-11-27:
I think you are close to the technical limits of your approach. If you want better results, add wheel encoders and provide real odometry or don't use AMCL.

Comment by Astronaut on 2012-11-27:
so what otion do I have if I do not use AMCl and without adding encoders?? So at the moment I can not add encoders. Whats the best I can do without encoders??

Improve this answer
$\endgroup$
0
$\begingroup$

Rosanswers logo

First of all you should give your question a title pertaining to the content. And yours is very deceiving as you are not even talking about ROS here.

About your question you already have you answer: you have an IMU and you don't use it to correct the odometry, so use it.

Your AMCL is based essentially on the IMU which (unless it's a very expansive one) does a really awful job at providing movement estimations. So since you're going to filter IMU and odometry, use this for the AMCL.

If you don't have odometry, then you're in for a lot of headache. Get two encoders on the wheels.

A partial workaround would be a very precise SLAM running off the laser, but I don't know how much better could it be with jumpy positioning.

Originally posted by Claudio with karma: 859 on 2012-11-26

This answer was NOT ACCEPTED on the original site

Post score: 2

Original comments

Comment by Astronaut on 2012-11-27:
I do not have any wheel encoders. As I already said im not using any odometry, so I do not have any encoders. All is laser scans based. And im using only IMU for the ICP. So how can I improve the performance with IMU and laser without using an odometry??or the best way is to use an encoders and ekf?

Comment by Astronaut on 2012-11-27:
so how to use IMU to correct the odometry?? Any help??

Comment by Claudio on 2012-11-27:
The AMCL already uses a particle filter, and that gives the best results. You may try (if you can) to get higher data frequency from the laser ranger: this should at least give you more fluid results.Think about putting encoders on the wheels. Customize the AMCL to also take IMU data as input.

Comment by Astronaut on 2012-11-27:
ok. so how to customize the AMCL to use IMU data??

Comment by Martin Günther on 2012-11-27:
Just as a note for people who might wonder about the first sentence: the title was "subscribe to a ros topic" before I changed it.

Improve this answer
$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.