Hello,
I was indeed referring to robot_pose_ekf in my last. Sorry for the
confusion, I didn't realize the ROS navigation stack was separated from
that.
Regards,
Kyle J. Kauffman
On Fri, Sep 6, 2013 at 2:26 PM, William Woodall
<
william@osrfoundation.org>wrote:
> I think we are overloading the term "navigation", in some circles it means
> planning to navigate a space, in others it means "navigation filter", as in
> an estimator.
>
> David is referring to the navigation stack which does not deal with state
> estimation or localization per se, but instead makes and executes plans
> based on state information, external sensor data (exteroception), and a
> given goal.
>
> Kyle, I think you are referring to the navigation filter where you take
> multiple sources of proprioceptive data and filter them for a better state
> estimate. This is more in line with what the `robot_pose_ekf` and related
> packages do.
>
> Just thought I'd point that out.
>
> --
>
>
> On Thu, Sep 5, 2013 at 5:22 PM, Kyle Kauffman <kyle.j.kauffman@gmail.com>wrote:
>
>> Hello,
>>
>> I'm glad to hear there is some interest and work going on with the ROS
>> navigation components. We decided to build our own internal nav package due
>> to a few things not being available at the time we looked:
>>
>> 1) Flexibility in bringing in measurements in different ways (loose
>> integration, tightly coupled,...). For example, camera measurements can be
>> brought in to a filter via PnP, raw non-linear angle measurements, as a
>> velocity update (odometry), and so forth, each with their own advantages.
>> We wanted a way to generically specify the sensors and then have the filter
>> bring the measurements in via a configurable option.
>>
>> 2) Easy plug-and-play sensor swapping. For example, being able to add in
>> an inertial to an already existing lidar/camera navigation filter and have
>> the filter automatically convert itself to an error-state model with
>> respect to the inertial; ideally, without having to change any filter code
>> (only bring a new ROS sensor node online).
>>
>> 3) The ability to apply to quadrotors and other 6dof applications.
>>
>> 4) Capability to swap filter implementations, such as particle filters
>> and GPU computation backends.
>>
>> I'm hopeful in the future we'll be able to release our nav package. At
>> that point I'd love to see what could be integrated into the ROS nav stack
>> as it progresses as well.
>>
>> Regards,
>> Kyle J. Kauffman
>>
>>
>> On Wed, Sep 4, 2013 at 4:04 PM, David Lu!! <davidvlu@gmail.com> wrote:
>>
>>> Hey all,
>>>
>>> As many people know, I've been working on improvements to the ROS
>>> Navigation Stack. In order to maintain maximum compatibility (and for
>>> my own curiosity), I want to find out how many robots are using the
>>> ROS Navigation stack. I've set up a wiki page here for people to add
>>> their own robots to.
>>> http://wiki.ros.org/navigation/RobotsUsingNavStack
>>>
>>> (Feel free to add to the list even if your robot's navigation
>>> configuration is not public)
>>>
>>> Consequently, if you are using navigation on your robot and not using
>>> ROS Navigation, I'd be curious to hear why.
>>>
>>>
>>> Happy roboting,
>>> -David!!
>>> _______________________________________________
>>> ros-users mailing list
>>> ros-users@code.ros.org
>>> http://lists.ros.org/mailman/listinfo/ros-users
>>>
>>
>>
>> _______________________________________________
>> ros-users mailing list
>> ros-users@code.ros.org
>> http://lists.ros.org/mailman/listinfo/ros-users
>>
>>
>
>
> --
> William Woodall
> ROS Development Team
> william@osrfoundation.org
> http://williamjwoodall.com/
>
> _______________________________________________
> ros-users mailing list
> ros-users@code.ros.org
> http://lists.ros.org/mailman/listinfo/ros-users
>
>
(text/plain)