RTIMULib2 seemed to be the best option when we were looking for a multisensor IMU solution.
Having you on board would be a great boost to openplotter, thanks.
So, we would have 3 options:
1- Fixing RTIMULib2 to digest your changes. We could keep managing IMUs with it and we try to implement pypilot as an independent tool.
2- Separate IMU management from "I2C" tab and create a new "IMU" tab for interacting with pypilot as you propose.
3- Switch to pypilot as signal k server.
Personally I would go with the second one. Switching to pypilot as main signal k server would be really traumatic right now and we need an stable version asap, maybe we can try on next stable version.
Regarding option 2,
is pypilot able to drive as IMU types as RTIMULIb2 do?
if we have 2 signal k servers, what about performance?
Could it be possible having those pypilot tools (calibration, inercial sensor viewers...) on "IMU" tab?
Having you on board would be a great boost to openplotter, thanks.
So, we would have 3 options:
1- Fixing RTIMULib2 to digest your changes. We could keep managing IMUs with it and we try to implement pypilot as an independent tool.
2- Separate IMU management from "I2C" tab and create a new "IMU" tab for interacting with pypilot as you propose.
3- Switch to pypilot as signal k server.
Personally I would go with the second one. Switching to pypilot as main signal k server would be really traumatic right now and we need an stable version asap, maybe we can try on next stable version.
Regarding option 2,
is pypilot able to drive as IMU types as RTIMULIb2 do?
if we have 2 signal k servers, what about performance?
Could it be possible having those pypilot tools (calibration, inercial sensor viewers...) on "IMU" tab?