Conversation
…ses msg imu/data_raw and /orca/pose as the dvl info
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #564 +/- ##
========================================
- Coverage 6.61% 5.89% -0.72%
========================================
Files 37 42 +5
Lines 2117 2375 +258
Branches 50 52 +2
========================================
Hits 140 140
- Misses 1977 2235 +258
Flags with carried forward coverage won't be shown. Click here to find out more.
🚀 New features to boost your workflow:
|
jorgenfj
left a comment
jorgenfj
left a comment
There was a problem hiding this comment.
Would be nice if odom is pubilshed in body(base_link) fame accompanied by a dynamic tf2 transform from odom to base_link.
|
|
||
| void correct() { | ||
| Eigen::Matrix3d R_nb; | ||
| R_nb << 0, 0, -1, 0, -1, 0, -1, 0, 0; |
There was a problem hiding this comment.
maybe expose this rotation as ros params for when the dvl mount is altered
There was a problem hiding this comment.
There is still some issue here, but yes that is the goal
There was a problem hiding this comment.
Im still fighting for "Set the frame assumptions internally and correct on the outside" - I.e. use TF2 on the ros side.
The TLDR is: You will fuck up transforms when rolling it yourself, so better let TF handle it and just make sure to use it properly
There was a problem hiding this comment.
^
Set transforms internally for standalone application.
Use ros defined transforms when used with the rest of the autonomy system. The cleanest way to do this imo is to include a boolean flag if ros transforms are to be used.
Instead of defining the ros transformations in the config file, just define the name of the frames. Then in the ros constructor you lookup these transformations using TF2. This way we avoid defining the same frame multiple places and keep the frame definitions in a centralized place (orca description).
This means stalling execution until the frames are available, but this is acceptable.
|
|
||
| // @brief Update the nominal state and error state | ||
| // @param dvl_meas: DVL measurement | ||
| // @return Updated nominal state and error state | ||
| std::pair<state_quat, state_euler> dvl_update( | ||
| const dvl_measurement& dvl_meas); |
There was a problem hiding this comment.
We talked about generalizing away specific sensors for any update methods - is that still a go?
I think it would be really nice to write the eskf as a library, and have the user provide the spec for whatever sensor they bring.
You could call it PO, but having seen how many kalman filters have been written over the years, it would be really clean to have this be the go-to solution for years to come 🙏
There was a problem hiding this comment.
yeah, its the end goal, just making it work properly for the thesis now, but will be the next step before merge :)
|
|
d8de3a7 to
dd0f97a
Compare
for more information, see https://pre-commit.ci
|
Before merge, make a simulator test (could be just to start up the node in the ros environment and make sure the output is sufficiently good compared to ground truth, for instance) and add it in this list |
No description provided.