Navigator benchmark framework #47
Conversation
There was a problem hiding this comment.
I really like this! The only functionality I think it's maybe missing is something to report what sensors "failed" (became classified as unreliable) and when as this feels like another important metric to use when comparing/benchmarking navigation algorithms?
|
Some tests are a bit iffy still... should be fixable, though. |
|
I've also fixed a plethora of bugs and just bad code along the way so we kind of want to get this merged. Though we should pay special attention to the types because changing them around isn't fun. In particular, I have opted to give the sensor values without timestamps no names (if possible) so that users will be forced to use the timestamped types unless they want to spell out the whole thing. |
| virtual core::Result configure(); | ||
| virtual std::optional<core::Measurement<core::RawAcceleration>> read(); | ||
| virtual std::uint8_t getChannel() const; |
There was a problem hiding this comment.
i think there are plenty methods currently in derived classes that omit virtual. dont think it changes anything if we omit it or not? but reckon we should decide on the standard, im okay with adding this to derived method from now on.
There was a problem hiding this comment.
I would say that we should definitely include virtual. It just makes it clearer that the signature comes from the interface.
There was a problem hiding this comment.
cool, will start enforcing this
No description provided.