Allow direct integration of GPS data

[ayrton04]

Right now, the process for integrating GPS data is, admittedly, a bit convoluted. While the circular dependency between the filter nodes and navsat_transform_node is necessary, it creates unnecessary confusion for users. This complex interaction between the nodes could be greatly simplified by just allowing the filters to work with the GPS data directly.

To that end, I propose that we add a gps sensor input type to the filters, e.g.,

gps0: /your/navsatfix/topic
gps0_config: [true, true, false ...

We can then move many of the navsat_transform_node parameters into the filter node configuration.

[wangminhang]

where can see this part of code in ros_filter.cpp?

[ayrton04]

It doesn't exist yet. It's a feature idea.

[brunoeducsantos]

Is this feature already implemented? Or do you still need help?
The idea would be creating a separated node to nav_sat filter instead of being convoluted into ros_filter?
Thanks

[ayrton04]

No, that's not what I had intended.

The original intent with the package was based on the suggestions of OSRF for how to make a ROS package, namely, that you make the ROS-agnostic core to the package, and then wrap that in ROS interfaces. Back when I wrote the package initially, it was for a government contract in the US, and funding and time were tight, so it was pretty simple, and the RosFilter class didn't do much except translate data to and from ROS messages for consumption by the filter. Over time, the RosFilter class became large and unwieldy, and is now what I consider "a mess."

So, to answer your question, I don't see having a NavSatFilter class as a unit that would live alongside RosFilter. If anything, I'd do a major refactor, and pull out each data pre-processor (e.g., for pose, twist, etc. data) and make a class for each. But time being what it is, I just don't know how likely that is.

Part of the reason that this package doesn't see a lot of activity is that we're trying to move to the fuse package:

https://github.com/locusrobotics/fuse

There's still a lot of work to do to make it usable and give it feature parity with r_l, but that's out intent.

[brunoeducsantos]

Thanks @ayrton04 for your feedback!

[jotix16]

Hey @ayrton04, how do you really imagine

If anything, I'd do a major refactor, and pull out each data pre-processor (e.g., for pose, twist, etc. data) and make a class for each. But time being what it is, I just don't know how likely that is.

1. Do you want to hold maps with objects from each SensorClass and use the topic name as key?
   Edit1: hash_tables instead of maps as they have O(1) complexity to read instead of O(L logN) for normal maps where L is the stringth length and N the nr of sensors. Important as it has to happen for every callback.

2. Or create classes with static functions and still send the necessary informations from rosfilter? This would not require holding maps for each SensorClass.