Repository navigation
Conversation
# Conflicts: # navigation/eskf/CMakeLists.txt # navigation/eskf/launch/eskf.launch.py # navigation/eskf/test/ros_contract_test.py
| double keyframe_interval = 0.2; | ||
| double integration_covariance = 1e-8; | ||
| }; | ||
| class GtsamNavigation : public NavigationEstimator { |
There was a problem hiding this comment.
It strikes me as somewhat strange to use the NavigationEstimator interface to implement an fgo backend. NIS doesn't really make sense in this context (just use one of the robust noise models if you want something "similar"), etc
Better to treat these as two separate filters entirely?
There was a problem hiding this comment.
(that is to say, you can pretty comfortably get away with gtsam's "predict" and not have to think about anything eskf :))
There was a problem hiding this comment.
Oh lord you're already here hahahaa. I meant to create this as a draft.
Thank you very much for the feedback already though!
(Have you implemented something like this?)
There was a problem hiding this comment.
hahahahaha i get notifications 🫶
draft PRs are really really nice, makes for a better feedback loop. I'm familiar yes, figured I could give some initial pointers, and a more thorough review once its out of draft, if desired
There was a problem hiding this comment.
Would love that yes!
I like draft as a place for conversations and visibility so those who'd like to give advice can do so early :)
There was a problem hiding this comment.
very neat, final thing for now I'd say keep things simple, rather that than immediately having all the bells and whistles (read in Edmund voice)
you'll run into plenty of issues with any filter ever, especially when running it live, so best do your future selves a favour 🤞
| gtsam::Values values; | ||
| gtsam::FixedLagSmoother::KeyTimestampMap stamps; | ||
| impl_->append_keyframe(factors, values, stamps); | ||
| impl_->solve(factors, values, stamps); |
There was a problem hiding this comment.
Letting the solver be IMU-driven can get a bit fucky when you start adding sensors or get multiple non-imu measurements as input in a row (i.e. lag in the output vs what information you technically have available), should double check that this is fine for you. Good that the aiding sensor handlers do solves too, but running it keyframe style seems a bit like "i want solves at a minimum rate", which if you want something like anchoring out of sequence measurements you dont really need to solve. You might also want to look at outputting odometry at imu-rate with last solve + prop state
There was a problem hiding this comment.
(Also, its not a bad idea to run the solver periodically in case of imu free run, but that can be at a much lower rate than keyframing for out-of-sequence)
| class DvlFactor | ||
| : public gtsam::NoiseModelFactor2<gtsam::Pose3, gtsam::Vector3> { | ||
| public: | ||
| DvlFactor(gtsam::Key pose, gtsam::Key velocity, const SensorDVL& sensor) |
There was a problem hiding this comment.
if you wanna be fancy you can support along-beam velocities too !
2 participants
Add an alternative GTSAM manifold-preintegration and fixed-lag navigation backend on top of the ESKF navigation fix in #740. Includes the GTSAM estimator, launch path, validation notes, and tests.