Posts: 2,207
Threads: 20
Joined: Jun 2016
Reputation:
65
If you use this device you should really check out my changes to the rtimulib.
I reduced cpu usage by 10x and also got the noise levels of the sensors to about 1/3rd, plus other improvements.
https://github.com/seandepagnier/RTIMULib2
I needed to do this for my free autopilot!
https://github.com/pypilot/pypilot
Posts: 2,866
Threads: 59
Joined: Mar 2016
Reputation:
271
Sean, it seems that your fork is what we are looking for.
https://github.com/seandepagnier/RTIMULib2
It would be great that we could switch to your fork and it could be the first step to include your pypilot into openplotter as we talked time ago.
Could you confirm...?:
If yes I will try to switch to your fork as soon as possible and test your improvements.
Posts: 2,207
Threads: 20
Joined: Jun 2016
Reputation:
65
In my fork the most important change to the mpu9255 is that it uses the internal fifo for mag readings. It's not yet back-ported to the mpu9250, but that should be easy.
Before it would use the fifo for accel and gyro, but read the mag explicitly. This had a rather serious bug that sometimes you got mismatched high and low bytes (different samples) and it had a lot of overhead. It used too much cpu to sample the mag fast enough.
Now, you could simply read the fifo at 10hz, even though the sensors are sampled at 100hz, and it averages the 10 readings giving lower noise of 100hz sample, but updating the kalman filter at 10hz.
I think it would be great to update openplotter. Btw, I tried downloading the image and no seeds on torrent, and also mega keeps timing out on me.
As for pypilot, all the sources are released now github.com/pypilot/pypilot and you could try it. Of course, it runs it's own signalk server which doesn't completely conform to the signalk spec right now, but the differences are probably trivial. The mpu9255 must be read from the realtime process in the autopilot. You can get the data into openplotter or nodered or opencpn or whatever by connecting to the autopilot. It would be unacceptable to add any lag between reading the gyro and commanding the rudder.
Posts: 2,866
Threads: 59
Joined: Mar 2016
Reputation:
271
Sorry the torrent server was down by accident, try now: http://www.sailoog.com/sites/default/fil...ip.torrent
Ok, so I understand the improvements are only for mpu9255 and this will be the chipset you will use on pypilot. Happy to see your project is moving forward, if we can help just shout.
I will test your repo as soon as possible and when openplotter reaches beta stage I will test pypilot too.
Posts: 2,866
Threads: 59
Joined: Mar 2016
Reputation:
271
2017-06-21, 05:58 PM
(This post was last modified: 2017-06-21, 06:00 PM by Sailoog.)
Sean, it was impossible to compile your fork, lots of errors:
Code: git clone https://github.com/seandepagnier/RTIMULib2.git
cd RTIMULib2/Linux
mkdir build
cd build
cmake ..
Quote:CMake Error at CMakeLists.txt:88 (ADD_SUBDIRECTORY):
add_subdirectory given source "RTIMULibFusionComparison" which is not an
existing directory.
when setting RTIMULibFusionComparison to OFF on CmakeList.txt compiling is OK
Code: cd ..
cd RTIMULibCal
make -j4
Quote:objects/RTIMU.o: In function `RTIMU::createIMU(RTIMUSettings*)':
RTIMU.cpp .text+0x78): undefined reference to `RTIMU5883L::RTIMU5883L(RTIMUSettings*)'
RTIMU.cpp .text+0x1cc): undefined reference to `RTIMULSM6DS33LIS3MDL::RTIMULSM6DS33LIS3MDL(RTIMUSettings*)'
objects/RTIMU.o: In function `RTIMU::RTIMU(RTIMUSettings*)':
RTIMU.cpp .text+0x2dc): undefined reference to `FusionMahony::FusionMahony()'
RTIMU.cpp .text+0x31c): undefined reference to `FusionMadgwick::FusionMadgwick()'
collect2: error: ld returned 1 exit status
Makefile:120: recipe for target 'Output/RTIMULibCal' failed
make: *** [Output/RTIMULibCal] Error 1
Code: cd ..
cd RTIMULibDemo
qmake
make -j4
Quote:objects/RTIMU.o: In function `RTIMU::createIMU(RTIMUSettings*)':
RTIMU.cpp .text+0x78): undefined reference to `RTIMU5883L::RTIMU5883L(RTIMUSettings*)'
RTIMU.cpp .text+0x1cc): undefined reference to `RTIMULSM6DS33LIS3MDL::RTIMULSM6DS33LIS3MDL(RTIMUSettings*)'
objects/RTIMU.o: In function `RTIMU::RTIMU(RTIMUSettings*)':
RTIMU.cpp .text+0x2dc): undefined reference to `FusionMahony::FusionMahony()'
RTIMU.cpp .text+0x31c): undefined reference to `FusionMadgwick::FusionMadgwick()'
collect2: error: ld returned 1 exit status
Makefile.Release:184: recipe for target 'Output/RTIMULibDemo' failed
make[1]: *** [Output/RTIMULibDemo] Error 1
make[1]: Leaving directory '/home/pi/RTIMULib2/Linux/RTIMULibDemo'
Makefile:34: recipe for target 'release' failed
make: *** [release] Error 2
Code: cd ..
cd RTIMULibDemoGL
qmake
make -j4
Quote:objects/RTIMU.o: In function `RTIMU::createIMU(RTIMUSettings*)':
RTIMU.cpp .text+0x78): undefined reference to `RTIMU5883L::RTIMU5883L(RTIMUSettings*)'
RTIMU.cpp .text+0x1cc): undefined reference to `RTIMULSM6DS33LIS3MDL::RTIMULSM6DS33LIS3MDL(RTIMUSettings*)'
objects/RTIMU.o: In function `RTIMU::RTIMU(RTIMUSettings*)':
RTIMU.cpp .text+0x2dc): undefined reference to `FusionMahony::FusionMahony()'
RTIMU.cpp .text+0x31c): undefined reference to `FusionMadgwick::FusionMadgwick()'
collect2: error: ld returned 1 exit status
Makefile.Release:222: recipe for target 'Output/RTIMULibDemoGL' failed
make[1]: *** [Output/RTIMULibDemoGL] Error 1
make[1]: Leaving directory '/home/pi/RTIMULib2/Linux/RTIMULibDemoGL'
Makefile:34: recipe for target 'release' failed
make: *** [release] Error 2
Posts: 2,207
Threads: 20
Joined: Jun 2016
Reputation:
65
(2017-06-21, 05:58 PM)Sailoog Wrote: Sean, it was impossible to compile your fork, lots of errors:
I know there are errors but the python module should build ok, and the RTIMULibDrive demo should work.
I think all we really care about is the python module anyway.
I could fix everything else, but this project is not well managed. It should not require rewriting every make file for every demo just to add a new source file to the library.
I am trying to figure out who is maintaining this project and if they would integrate these changes. In any case, I think it should work for openplotter as it is.
Posts: 2,866
Threads: 59
Joined: Mar 2016
Reputation:
271
2017-06-29, 06:43 PM
(This post was last modified: 2017-06-29, 06:43 PM by Sailoog.)
We need also at least RTIMULibDemoGL and RTIMULibCal to calibrate. How do you calibrate?
RTIMULib2 is no longer maintained by his developer.
Posts: 2,207
Threads: 20
Joined: Jun 2016
Reputation:
65
(2017-06-29, 06:43 PM)Sailoog Wrote: We need also at least RTIMULibDemoGL and RTIMULibCal to calibrate. How do you calibrate?
RTIMULib2 is no longer maintained by his developer.
The calibration programs in rtimulib are garbage. They are not accurate and not robust. Even the gyro bias estimation was not very good. For boats we can just lowpass the gyros over a few minutes to get the bias. Even better would be a kalman filter with gyro bias states, but this has other implications.
pypilot automatically recalibrates all the time, and the calibration is written in python. See:
https://github.com/pypilot/pypilot/blob/...ion_fit.py
I have already developed 3d viewers for calibration and viewing inertial sensor (3d model of boat) all in python.
As far as making the rtimulib demos work. It got broken when I added additional filters and sensors. Basically the makefiles just need a few sources added and they will work fine. I didn't bother because it would be nice to fix the build system in this project, it's currently difficult to maintain.
Anyway, I tried openplotter yesterday. It is very interesting and I would like to collaborate to make pypilot an optional component in openplotter. Right now we have a problem with two competing signalk servers, and my implementation is probably nonstandard (the standard keeps changing)
I think openplotter can easily negotiate this situation with a little bit of logic. pypilot must be the program which reads from the sensors. Your server could then connect to the pypilot signalk server to obtain the heading, heel pitch etc in this case. I don't think it would be too bad this way.
Another thing to consider is to simply develop my python implementation of signalk since it's going to be a lot more efficient and easier to develop than what exists written in javascript. I already have all kinds of tools developed for it that don't exist for the other signalk stuff, and it's much more efficient.
Today I finished reprogramming brushless drone speed controllers to drive brushed motors
Posts: 2,866
Threads: 59
Joined: Mar 2016
Reputation:
271
2017-06-30, 06:00 PM
(This post was last modified: 2017-06-30, 06:03 PM by Sailoog.)
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?
Posts: 2,207
Threads: 20
Joined: Jun 2016
Reputation:
65
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,
is pypilot able to drive as IMU types as RTIMULIb2 do?
pypilot uses RTIMULib2, at least my modified version of it. I am sampling all sensors at 100hz.
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?
|