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 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 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!! 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 > >