Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

More filters #3

Open
wants to merge 6 commits into
base: hydro-devel
Choose a base branch
from
Open

Conversation

dawonn
Copy link

@dawonn dawonn commented Nov 11, 2013

I have been working on a collection of imu filters that may be useful for the general public.

Here's a general outline of the idea I'm working towards: http://goo.gl/Mv2om0

So far the attitude filters work pretty well on the devices I've tested.

FYI: I'm working on the yaw estimation by integrating the magnetometer data, but it's still a work in progress. :)

trim, bias, accel, gyro, tf all work really well.
rviz is a work in progress but probably going to delete it
working on a fusion of the accelerometer and gyro now (_simple)
Fused accel and gyro together, works well! :D :D
Added lisensing to all of my scripts.
@chadrockey
Copy link
Member

I'm not sure if I should accept Mahony and Madgwick in this package as they are GPL licensed. Mixing the licensing on packages can be confusing. However, there isn't a lot that's as good as those implementations.

@chadrockey
Copy link
Member

This is also a fairly large pull request, can you split this out into at least:

  1. Mahony

  2. Madgwick

  3. Python Scripts

I would also prefer the small python scripts to be implemented in C++ so there's the capability of running them on platforms that may not include python.

@tfoote
Copy link

tfoote commented Nov 11, 2013

This sounds like a good case for separate packages.

@dawonn
Copy link
Author

dawonn commented Nov 12, 2013

Unfortunately, it sounds like separate packages would be best. The remaining question is where to host it...

The package name "imu_pipeline" sounds like a great centralized location to put commonly used IMU filters. But it would seem that only BSD licensed c/c++ code is acceptable? (Understandable, but very frustrating!)

Perhaps imu_pipeline should be reorganized into a meta package so each filter node can be located within it's own package hosted the imu_pipeline repository. This is advantageous for many reasons:

  1. It collects many IMU filtering packages into a single repository where they can be easily discovered.
  2. Each package can be licensed independently.
  3. It allows for advanced users to depend only on filter stages they use.
  4. The IMU pipeline repository can develop a community of users, maintainers, and developers.
  5. Decreases the number of repositories to be tracked, which makes migrating to a new version of ROS easier for the maintainer.

I think this solves all of the for-mentioned problems and yields a better overall experience for the ROS community, thoughts? If you like the idea, I have no problem volunteering to do the work.

@chadrockey
Copy link
Member

@dawonn Sorry for the delay, but I agree, imu_pipeline should become a metapackage for Indigo and include other, better quantized packages.

@mintar @idryanov

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants