2017-06-30, 11:45 PM
(This post was last modified: 2017-06-30, 11:48 PM by seandepagnier.)
(2017-06-30, 06:00 PM)Sailoog Wrote: RTIMULib2 seemed to be the best option when we were looking for a multisensor IMU solution.
probably still is.
Quote: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.
I agree with #2 for now. The third option would cause major breakage and actually might never make sense. My version of signalk is not compatible at the moment either. The autopilot doesn't need to care about this other stuff, ever. Although bilge level might help...
Now, with #2, you could simply connect to the autopilot server to retrieve things like pitch or heel. The subscription would be canceled if the data isn't needed.
Quote:Regarding option 2,pypilot uses RTIMULib2, at least my modified version of it. I am sampling all sensors at 100hz.
is pypilot able to drive as IMU types as RTIMULIb2 do?
Quote: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?
I think performance is ok. Since openplotter typically runs on a raspberry 2 or 3.
I target the raspberry pi zero at only 700mhz, with only 25% cpu usage in the worst case. This is including running a web control app, and lcd screen over spi.
The core autopilot is about 12-15% of a 700mhz armv6 core. Right now anyway. When it gets smarter it will use more, but this is typically idle cpu. I also can optimize it a bit more to make it even more efficient. Basically it's < 3% of a raspberry 3 processing power.
As far as the tools on the IMU tab. Of course it's possible. All the clients already communicate to the autopilot server via signalk, so they can run anywhere. Since openplotter is written in python, and I already have tools using wxwidgets in python, you could probably just drop them into a tab without actually writing much code.
I just got everything working perfectly on an orange pi zero today! Maybe the orange pi is an openplotter candidate as well?