gtsam development branch moving fast

[sanderson77]

Now that we are working with the unstable gtsam development branch, an issue has occurred where contributors to the curves library are using different revisions of gtsam. Which has in turn has caused some confusion about why things are breaking and/or faulting on different machines.

E.g. while the 6D-Expression branch builds with an older revision of gtsam, it does not build with one checked out as of today (rev 61666f22d618010bc1a63298ef856741db62f1d3). Some include locations have changed, and some functions have become private (which were previously public), etc.

Can we standardize on a specific gtsam revision that we will work with for some set period of time? or are the day-to-day expression updates in gtsam critical to our use? Maybe someone more involved on the gtsam side can make a recommendation (is there a recent commit that will be fairly stable for our use until speed becomes critical?).

[rdube]

I agree with focusing on a given revision for the next few weeks. What about the one of today?

61666f22d618010bc1a63298ef856741db62f1d3

Over the next two weeks we will continue to put together our 3D-Laser + Odom optimization framework which is based on curves, GTSAM, minkindr and libpointmatcher. It would therefore make sense for us to focus to a given GTSAM revision.

That being said, it is always cool to have the latest updates and I am excited to see the latest expression features!

[gawela]

Hi all, for the refactoring we went on a new GTSAM revision (No Charts anymore, updated traits concept). We are now working on commit no:

b6a7dc05307dd4eff68feba6353b0d3f48d403c5