[ros-users] Is scan_tools maintained ?

[Ivan Dryanovski]

On Fri, May 13, 2011 at 6:46 PM, Willy Lambert <lambert.willy at gmail.com> wrote:
>
>
> 2011/5/13 Ivan Dryanovski <ivan.dryanovski at gmail.com>
>>
>> Hi Willy
>>
>> I replied at answers.ros.org, but here's some extra info.
>>
>> The scan_tools stack is being maintained, although we are stretched a
>> little thin in terms of manpower. If you find anything that's broken,
>> or documentation that's out of date, let me know, and I'll fix it.
>> Last time I checked (around cturtle) both canonical and polar were
>> working.
>
> I will certainely have plenty of questions, so if your are keen at
> anwsering, here is some background information :
> I am using this node an a differential robot you can see here (the hokuyo
> providing the scans is a the front on the first left picture.
> http://team-ard.com/images/stories/crotocombo.jpg
> It evolves on such kind of tables with fixed walls often in view:
> http://team-ard.com/images/stories/coupe2010.jpg
>
> The classical odometry does well at the condition of separating the
> propulsive whell from the "encoder wheel". It is not the case in our design,
> so the odometry information are good at :
> _ low speed/low acc
> _ better at the beginning
> _ no good when bumping into an obstacle (and this happens oftenly).
> So my team and I are very interessed in such kind of "no floor link"
> odometry, that's why we are trying the canonical_scan_matcher. But behind
> this, there are industrial applications of this that would love to have a
> working combination of dead reackoning + laser odometry.

There are two ways I can think of that will enable you to fuse wheel
odometry with the laser odometry:

1) Use the dead reckoning as an input to the scan matcher. I believe
this is already implemented in CSM and PSM, but not tested. You need
to provide the scan matcher with a tf for the initial guess. This way
the scan matcher has the final word. The advantage is that providing
input to the scan matchers really decreses their convergence time and
accuracy, especially for angular motion.

2) Provide the laser odometry and wheel odometry independently to
robot_pose_ekf or a similar ekf filter that fuses them. The CSM
algorithm has the option to output a covariance on the scan match, but
it's currently not implemented in the ROS wrapper.

Out of the two options, we are using 1) on our vehicle. We don't have
wheel odometry, but we have an IMU, and hence we can provide the scan
matcher with a guess for the yaw angle.

> What I misses in the documentation is the tuning capabilities of the node,
> knowing that a quite good odometry is provided (I think there are by default
> configured for no odometry returns).  In comparing the 2 systems, I see both
> system sometimes right sometimes wrong. So there must be something to tune
> to have a proper merge of the 2 localisation systems.

Do you mean tuning the parameters? I documented the parameters that
CSM and PSM accept. My documentation is mostly based on the
documentation the authros provided with the original C++
implementations. For more detailed description on what each parameter
does, we'd have to go back to the papers. I have empirical experience
with tweaking them, so maybe I could help as well.

> Another point : it seems that the system is (by far) better when the
> environnment is static (which is normal). Is it something to tune to be
> robust to this ?

Both scan matchers make the assumption that the scene is static. You
can try decreasing the parameter which sets the
max_correspondence_distance. Setting it low might help ignore moving
objects.

By the way, what is your goal for the odometry? Are you building a
map, doing local obstacle avoidance, etc? The scan macthers are purely
incremental, ie, they only compare two consecutive scans, so error
will inevitably build up. If you need an accurate map, and an accurate
global positioning, you can try running gmapping, using the scan
matcher's odometry as an input.

>
>>
>> > BTW I am quite impressed of the precision out of the box of the
>> > canonical_scan_matcher.
>>
>> The props for that should go Andrea Censi, whom I had the pleasure of
>> meeting at ICRA a couple of days ago.
>>
>> Ivan
>>
>> PS looks like you just posted some track tickets. I'll take a look.
>> _______________________________________________
>> ros-users mailing list
>> ros-users at code.ros.org
>> https://code.ros.org/mailman/listinfo/ros-users
>
>
> _______________________________________________
> ros-users mailing list
> ros-users at code.ros.org
> https://code.ros.org/mailman/listinfo/ros-users
>
>