You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I think it is worth to sit down and make a clearer architecture on how a "sensor" is added and removed. I can also see that any routine that cannot fail (or we have no method to react to a fail) can go to the IMU object constructor or destructor and hiding the functionality from the public interface.
The text was updated successfully, but these errors were encountered:
I think we could change the ImuInterface::init() signature to ImuInterface::init(const std::unordered_map<std::string, std::string> &config) to allow initialization of imu-specific settings, which could then also be loaded from a yaml file. With this change we could activate crc and burst and also execute the self-test from the ImuInterface::init function. We could then also remove the ImuNode::init() function.
The close function was never called and was part of bug #6. In #14 the ImuInterface::close() function is called after ImuNode::run_node is set to false by the SIGINT handler.
From a user perspective I find it difficult to know which functions I have to call when loading an IMU, e.g., init after object creation, init and burst CRC activation in factory, self-test in node init. Where does the IMU call its close() function?
I think it is worth to sit down and make a clearer architecture on how a "sensor" is added and removed. I can also see that any routine that cannot fail (or we have no method to react to a fail) can go to the IMU object constructor or destructor and hiding the functionality from the public interface.
The text was updated successfully, but these errors were encountered: