Vosper Mini Fins Stabilisers retrofit on MiToS

[jfm]

Loving this. Nothing much to add, but enjoying reading all this. The roll in third video looks good- you should get excellent STAR if you can get that much roll when berthed. Respect!

 

[kashurst]

+1 great going Vas, good luck with the stability algorithm.

 

[Anders_P42]

Hats off to you, great project and I'm sure very rewarding.

 

[vas]

Loving this. Nothing much to add, but enjoying reading all this. The roll in third video looks good- you should get excellent STAR if you can get that much roll when berthed. Respect!

that's my view as well John. Don't expect to get even close to a pro system though, if I do, I'd probably have to thing about a career move

+1 great going Vas, good luck with the stability algorithm.

Kevin,

still haven't focused on your detailed post as it seems I'm finding new plain logic errors on my existing basic s/w...
However, I'm indeed getting into an hierarchical approach to roll triggered response of the system using the roll speed as the main component (for now at least!)
I'm having problems with getting a roll angle (plain and simple, no integration of rolls of change et al, too complicated for me right now...)
I can calculate roll angle (through some sqr and multiplications) but no matter how much I smooth it, it's still a bit jerky and not fit for testing and decision making based on these values.
Anyway, got a long winter in front of me, so plenty of time to improve on a working system.

Hats off to you, great project and I'm sure very rewarding.

thanks, v. rewarding indeed after a lot of ups and downs...

Now a quick update with some s/w related pics.
I had lots of issues in triggering the fins, eventually roll acceleration (roll speed from the gyro) tuning down to silly low values was the key as well as making sure movement is not triggered when simple boat is not moving and roll accel is 0 indefinitely .

The other great problem I had was the feedback sensors.
I initially designed the s/w to get into a while loop effectively sending an instruction to the hydraulics and waiting for the feedback sensor value to reach a set point in order to stop the hydraulics.
This is simple programming, but exceptionally bad practice. You hog the tiny processor (albeit running at 120MHz and being 32bit and having floating point h/w support) waiting for a integer from the feedback sensor that matches a range of values you've preset. Not to mention there are two of these buggers and this way it simply goes serially port first, stbrd second. Plain wrong!
Solutions discussed extensively with pagoda from PBO were simple:
A. dual core processor ESP32, so get each loop on a different core running concurrently. Bought one but solved it before it arrived from DE!
B. more teensies but I'd just shift the bottleneck elsewere
C. using Interrupt Service Routines (or plain interrupts)

Interrupts are too good to be true, and rather difficult for a non-programmer to implement at low level. Existing libraries were rough, so took me 3-4 days working 6-7h per day to sort it. [btw, if anyone want's help in running ISR on a teensy drop me a note]
So to cut a v.looong story short, after removing the bilge controller, bringing it home, rewiring slightly the teensy and feedback sensor cabling, fins now move accurately and stop exactly where I want them, don't even need a range of values to get them to eventually stop somewhere close... Well impressed with myself and the tiny arduino board!
A side effect of this is that now both fins start moving at the same time (instead of sequentially with my older crappier programming) and there's enough CPU time to measure roll accel and roll values, keep them and measure mins and max over each roll period. I also have enough power from the chip to measure roll period and format the N2K sentences and sent them to the dash tft touchscreen. Effectively means that I can get a reasonable update on fins placement 5+ times a second, not bad.

A few screen captures from the laptop running the program and visualising with rough graphs the values reported from the arduino and the MPU.

next couple of pics are showing roll speed (the nice sinusoidal curve) and roll angle (the bloody awful jagged line)

next pic has a attempt of timing and getting the movement of the fins (the square wave one) Good in theory didn't work in practice due to above explained problems.

next pic is a text log with lots of values:

following pic shows a roll from a passive fishing boat, rather abnormal movement overall

final pic is recording another fishing boat roll and the fins response and elimination. Problem is that roll was really little and fins are easily overpowering the correction, so had reduced the fin amplitude A LOT to get a decent response:

Still not happy, got to take onboard the roll accel values on each roll period as part of my feedback loop and thread along the lines explained by kashurst in post #156.

Conclusions so far, OK got them moving, need to get timings, fin movement, angle, power, etc sorted. Certainly keeps the brain spinning this job!

cheers

V.

 

[vas]

me again

Taking onboard my previous comments to myself I had some long programming sessions sorting out the trigger and response loops.
It was evident that I cannot manually alter fin amplitude (travel) and system sensitivity.
So devised a way that by default the system based on GPS speed (don't forget where I am...) and roll acceleration adapts to conditions and only triggers when it has to. There's a manual override for testing but looks like the auto mode is much better even in it's crude form of 4lines of code now.

Surprisingly I'm getting there!

Turned out that rate of accel change was too fast when the liner approaches (registers values up to +-10 whatevers I'm measuring -just to give you an idea) compared to a tiny ripple or a slight roll (which registers 0.5 or so) effectively making my whole code to fail grabbing the point that accel change was zeroed (the red v.wiggly line below on the graphs) and fins where not moving at all.
Further, having a constant roll amplitude trigger point was proving difficult in other respects so I factored that in.

To cut a long and incomprehensible story short, this evening was the first time that system behaved properly throughout the 5mins of vigorous roll from the liner. No salon sliding doors slamming about, no massive rolling, just a gentle movement compared to the boats around me! Still some tuning to the fin travel over roll accel to be done, as I have a linear interpolation on which is definitely wrong so got to try some jazzy curvy function to get better results in medium roll.

typical roll increasing (system off):

next pic shows how the 9 whatevers roll accel drops to 3 by changing from manual to auto just before half length of the graph:

So definitely happy!

Must be the first ever system that STAR operation is being sorted before the under way stabilisation is even properly tested
Another first for MiToS...

Unfortunately it's pitch black when the liner is in port and I'm having problems videoing the whole thing, maybe I'm lucky as sometimes on w/e it's back in early, we shall see.

cheers

V.

 

[MrB]

Vas, your brain is to big. :encouragement: #tinymindblown lol.

 

[vas]

Vas, your brain is to big. :encouragement: #tinymindblown lol.

what about kashurst brain then? see this post and tell me...
Still haven't gone round implementing it.

Mind took me all this time just to get the bleeding fins moving when they should and as much as they should (give or take...)

cheers

V.

 

[MrB]

what about kashurst brain then? see this post and tell me...
Still haven't gone round implementing it.

Mind took me all this time just to get the bleeding fins moving when they should and as much as they should (give or take...)

cheers

V.

I recall the Kashurst's post and you getting him to post online as opposed to email...... I cannot read it, it makes me "rock in my chair and dribble" with vacant eyes.

 

[MapisM]

Must be the first ever system that STAR operation is being sorted before the under way stabilisation is even properly tested

That's nothing, Vas.
It's bound to be the first ever DIY fin stabs system, period - let alone a STAR capable one.
I'm pretty sure that the tuning of stabilization under way will now be a piece of cake, in comparison.
Very, very, very well done! :encouragement:

 

[Mr Googler]

Unreal Vas. Absolutely amazing

 

[Hardmy]

Vas, you are THE jack-of-all-trades. There is nothing, be it manual- or brainwork you cannot handle yourself! What you are able to achieve on your own with those stabs is properly embarassing for the engineers developing those systems probably full-time. Really looking forward to a video with stabs compensating a chop underway.

 

[vas]

update

first thanks for the comments, V. you're comparing my work with multidisciplinary teams doing it professionally... They'll obviously be better, although tbh I've no idea how many are working on the s/w and electronics part of things there. For sure they have years of experience and data to support their work as well as better programmers (would be embarrassing if that's not the case...) and hopefully some proper engineers and not an architect juggling all that!

And to prove all that, well started optimising the code and rewritting the routine that triggers the control loop only to find that the previous code was so bad and inefficient that timing-wise I was half a roll off on most of the time. So "tightening" up my code meant that fins where working the wrong way round and I had to swap the movement over That was shocking bad and explained why at certain roll period and conditions fins weren't triggered, or were late or fast...

Playing with smoothing algorithms for the data collected and presented and being a visual guy I couldn't sort the whole puzzle with plain numbers, (graph is king!) I ended up with a working code that performs reasonably well on the handbrake turn and the aftermath slaps we get from deflections and whatnot of the waves about the marina.
Having a better triggering algorithm meant I could start the fins with 90% of travel (I started with 40% a few weeks back) and not overshooting the correction.
The only visible issue (data graphs show more, but not for now) is that it has a hysteresis of half a roll to one full roll. ie. it's slow in starting the fins moving, could be something relatively simple (and possibly silly) but will only have time to look at it at the w/e.
Also implemented the park individual fins which was rather helpful in assessing the effectiveness of the algorithm with just one fin working - I know it's not the purpose of the routine, but a interesting byproduct

a couple of pics of the graphs, red sinusoidal is roll accelleration btw.

low roll situation, fins parked:

highish roll left half fins parked, right half fins activated and you can see the jerky cuts on the roll accel as the fins kick in. Should have better ones, but was still noting things and didn't have time to screen capture data.

Did manage to take a crap video last night and as a result I got a cold and suffering now (7degrees at 6pm yesterday + a nice breeze...) It's interesting how misleading the video is, looks nice and smooth and I was hoping about on the crappy floating pontoon, oh well.
Apologies for the sound and most importantly the fcking blue leds that this joke of a mayor we have here has filled the whole city AND the rental yachts in port!

you can spot on two occasions that boat rolls initially and then the fins start and stabilise. I'll get to the bottom of it I'm sure.

Next task is reroute the hydraulics to split at the pump and go in parallel to the two stabilisers (now it's serial, port first, stbrd after it) and play with the inverter Hz so that I could up and lower pressure of the system to alter the response characteristics on STAR operation.
The task after that is to figure out how big a pump I really need (as it seems the one I'm using currently is too big...) order it and mount it on the port engine so that I can have stabilisation on the go without obviously having the generator on all the time.
Third and unfortunate task is remove the yanmar 2GM20F that runs the generator and have it rebuilt as it's suffering from stuck rings most likely on one cylinder making it hard to start and occasionally unreliable (although now with the cold weather it seems to be just fin running, still abitch to start) And all that on 1000h (but at 3K rpm from stone cold to boiling)

and not to forget that at some point I have to get kahurst email processed and considered, looks like that's the hardest of all, but I can do it at home without getting hy hands dirty or freezing

got a few Qs for JFM, I'll email them tomorrow. off to a four hour class...

cheers

V.

 

[BruceK]

The mind boggles. I have an inkling of an idea as to what you are trying to achieve but am just so darn impressed and clueless I am now feeling a bit inadequate. Hats off to you and anybody else who has the foggiest as to what you are attempting to program.

 

[jfm]

Awesome stuff Vas. I'll check in tmrw

 

[vas]

OK

since there seem to be a few IT ppl in here and since I'm not going to patent my approach to stabilising (cos I cannot be bothered, and I'm not too keen to be ridiculed ) I'll try to describe the process I've followed.

So, boat is rolling about.
9DOF (degrees of freedom- as in 3 axis acceleration, 3 axis gyroscope and 3 axis magnetometre rather pointless since I'm using just the gyroscope data for the time being...) pumps out lots of numbers in rapid succession, nice.
I grab the gyroscope data on the correct axis (Y in my case as this has to do with the way chip is mounted against the boat) in rad/sec - let's call it rate of angular rotation over time .
I started trying to use that as well as calculate the actual roll angle of the boat. After almost 3 months I accept defeat as IIRC kashurst pointed out you don't really need that info... Since the chip doesn't really do angles, you had to do some trigonometry in order to convert accel vectors to angles. Due to the fact that Pythagoras used some square roots in there, bleeding resulting values weren't smooth and nice, too steppy and jerky. Being a visual guy I didn't like that as the programming approach I was following (based on the way I visualised roll) was expecting idealised sinusoidal curves that I find mins and max and query at will. Don't work like that I'm afraid!

Enough of an intro, lets see what intuition tells me to do!
Simple, find when boat is at the ends of it's roll travel (as in max roll angle which in the previous para dismissed as practically impossible todo accurately-and not to mention quickly on a tiny processor like on the teensy 3.5) and as soon as it's over that point and the moment it starts to move the other way, I move the fins and cut the roll as much as I can. So that's a simple idea, maybe too simple, but my understanding of physics says that's what I should to. Not much point letting the rolling to the other side develop before trying to stop it fe as you have to fight inertia on top of all that...

So getting back to the Y axis gyro rotation over time. Values I get are in the 0.1-1.0 range. As I didn't like them in the arduino IDE graphs I multiplied with 10 so that I get a decent curve even on almost idle, so that I can see what my actions do and most importantly establish that my calculated values are OK. Not very scientific I know, but I like my curves curvy and not flat so that I can see them clearly... So values from 1 to 10 it is!

• 1.1 is where I want the fins to start reacting,
• over 2 definitely feels moving about,
• over 7 salon sliding doors start dancing about and it's rather annoying,
• 10 hold on for real life sort of thing, a wine glass will definitely tip over and break.

There's also a manual mode where I can decide when to trigger fin movement

How can we find the exact point in time that roll has reached either end?
Simples, see when gyroY accel zeroes itself. That's the swap over point from rolling to port to rolling to sbrd (and vice versa)
So Task 1 is find the point in time that gyroY == 0
My original approach was to find when gyroY was within a small margin of values around 0. Now considering the roll period of approx 1.3X2=2.7sec (could be larger a bit) and the amplitude of the roll at higher values, I ended up having to devise a way of running automatically adjustable margins, 0.3 on low values of roll, going up to 1 for higher else I was missing completely roll periods (even 3-4 together!). That was causing issues as the timing of the trigger point was all over the place and in a few occasions, by the time this Task 1 was activated, Task 2 (to be described below) was out of bounds so fins remained still, or were moving with great delay and/or not enough...
Solution suggested by my el. eng colleague at the Uni was to run my loop as per normal and check by multiplying current gyroY value with the previous one! Now, if result was <0 (negative) meant that gyroY JUST crossed 0 and one value was negative and one positive. If both values were either positive or negative, result would be positive. Was rather p1ssed off I didn't think of that myself, but implementing it was dead easy, much faster (in CPU cycles for the small teensy) than setting intermediate test values and doing all sorts of comparisons and loops and gave the right results at the right time, everytime! So thanks to George, task 1 was solved. Note, each time I've managed to improve the code and optimise it even a bit, the result was also visible on the lowerhelm dash display that became more responsive as little chip had time to update data sent to dash screen more often and not only desperately trying to calculate what I wanted.

Program now knows that boat is at the end of its roll period, good! Program doesn't know yet which way boat is leaning and boat doesn't know if the roll is serious enough in order to take action. I mean even a tiny ripple will be enough to change from positive to negative and as such trigger Task1.
So now (inside Task1 and activated only when Task1 is true) Task 2 is to find if roll is more than 1.1 -in reality 0.11rad/sec but also adjustable btw manually if you so wish, down to as little as 0.5 and up to 2.0 (mainly for experimenting) or autoadjusted based on speed of craft and whatever else I can think of in the future...

Task 2B is to find which way boat is leaning in order to make sure fins move the right way round
Easy you say, not difficult I'd say, but remember at the moment Task1 triggered and got us looking at it, gyroY value has just passed 0 So we need to look back and find the latest absolute max value of gyroY. OK, easily done, I feel it's still quite expensive computing wise, I should be able to optimise it at some point.
Task2B is relatively easy, check if gyroY is above or below zero, and act accordingly.

You'd think I should be done and over in a couple of hours, but things aren't that simple in life I'm afraid (and I'm a self taught programmer...)

For starters, that zero I've been mentioning is surprisingly NOT zero really, as the sinusoidal curve seems to be shifting itself up and down at will, or over time, or whenever it feels so (that's my scientific explanation - now I'm sure some smart arse is going to come up with the real reason...). Tried to find out why, got bored reading various incomprehensible technical manuals for the MPU9250 and gave up. So now I'm constantly calculating and updating the mid point of the gyroY curve and out of this the over and under shift of 1.1 in my case so that I can be sure I start the antiroll routines only when it's the right time. I mean a maxY value of 2 maybe not enough to trigger fins moving (if midpoint is 1.5) and a maxY of -2 maybe enough if midpoint has shifted to -3.5...

Throw in some other tests like how many rolls and how reduced is the gyroY before I park the fins in the middle position and you're at a 1000line code. This includes comments (lots of them!) and

• comms with the display through custom NMEA2000 messages,
• querying NMEA2000 bus for:
  • GPS speed - could also be water but my bleeding wheel never works for more than a month and cannot be bothered tbh in the Med
  • gear (in order to park them when reversing) and
  • port engine rpm (gives me a better view on pump output when under way)
  • whatever else I can think off (wind data could be an idea not sure it's really an important issue though)
• various smoothing data routines
• interrupt service routines to swiftly and without cpu hogging stop fins moving when they reach the right point as reported by feedback sensors
• etc...

Still to do is reading yet again kashurst post and seeing how/where it relates to what I'm doing and how I can learn and pick things up from it but I need time and no other things in mind to do so.


Now a few Qs to John and however else could help:

do fins run at full amplitude at STAR or are there cases (v.little roll) that amplitude drops?
or does the system alter speed of movement to achieve that (again in STAR mode)? I know you run a variable displacement pump so easy to do so.
how does the progressive control box relays/solenoids (call them as you wish) operate in STAR mode? Starts slow, accell movement and taper off at the end or that's mostly used on the road mode?
Generally seems that on STAR things are not too complicated, move fins as quickly as they can and as much as they can!
So slightly curious what to expect when moving and want to prepare a bit.
Finally John, have you got any pics of gyroaccel plots over time with fins moving to see how Match responds to fin operation?
I mean on this pic I posted previously:

you can spot the points where the fins operated and it's not THAT consistent (it's the crippled top of the sinusoidal curve). Wonder how Match curves look like.
I'm going to try and optimise my code based on that over the next week or so if the weather plays ball that is.

that's all for tonight folks, and sorry no new pics on this post!

cheers

V.

 

[kashurst]

Hi Vas
great progress, I'm not sure what trace is which on your graphs can you give a key/description on which trace is which reading?
I still would concentrate on keeping pump speed constant at the moment and focus on fin distance movement V roll with a fixed hydraulic pressure.
Another question - do your fins move in parallel left to right?

 

[vas]

you're right, it's a bit complicated and each time I capture pics I have other slightly different data shown so colours are all over the place (and lines also...)
For the time, try to focus on the clear strong red sinusoidal at the bottom.
I'll probably be on the boat on Sunday (off tomorrow) and try to get some decent plots with just the necessary bits turned on and then I can explain what you're seeing.

agreed, that's what I'm doing atm (not much point changing too many variables at the same time and trying to figure out which affected what...)

yes fins at least now move in parallel and in sync with the stbrd one trailling slightly the port one as hydraulic routing is wrong and have to be redone in parallel and not serial they are now.
Ah, for the record I sometimes test with the one of the two fins stopped, helps in establishing how much work the one can do and how close I am to sorting it out

cheers

V.

 

[rgarside]

On the graph, what is the time base - seconds?
The red curve you draw attention to - from your comments I take it that it is roll rate, is that correct?

Trying to integrate only the roll rate to get a roll angle will likely result in an increasing integration error, so you are right to avoid that.

I thought that there was a way to get the 9250MPU to provide roll figures it calculated itself using its 9dof results to reduce the integration errors. However, for your purposes working from the simple roll rate values in the way you describe should work if the rest of the system can respond quickly enough.

It would be useful to know which of the other curves is the fin, and what sort of measure of the fin it represents.

I'm very impressed with everything you have done, and it is great to see the progress all described here!!

 

[vas]

morning all,

rgarside thanks for your comments:
time base is seconds, one vertical line to next is 10secs, red curve is indeed roll rate. So the circa 2.7 roll period is about right.
If you do come across a way to get plain roll from the MPU9250, without resorting to the code below do let me know

ran = -1.0*(atan2(IMU.getAccelX_mss(),IMU.getAccelZ_mss()) - 1.5707963);

but really I'd only need it to report it in the lower helm dash, can definitely live without that...
Teensy 3.5 seems to respond v.well and coping with the tasks at hand, 3.6 would be nicer (and I stupidly had one in my drawer and forgotten about it when I was putting the board together!)
ATM I'm slightly overclocking it to 144MHz from 120MHz, can go up to 168MHz apparently but not too keen tbh.

Not going to describe what the other lines represent on the previous graphs (different things each time, not much point) as I realised from your point that it's been a long time since I had actual feedbacksensor data plotted together with the gyro values. So did that last night and it's quite helpful now that all the other serious s/w glitches are done. Have a look at the following pics.
We have:
Blue roll rate (the x10.0 value)
orange midpoint curve of roll rate values
red port fin angle [positive to stbrd, negative to port]
lightblue stbrd fin angle [same as above]
both angles are plotted divided by 5.0 so that values are okayish and not altering graph scale making roll rate invisible. Didn't want to do them divided by 10 as they'd mess with the roll rates and be more confusing.
Max value is 30degrees (or thereabouts anyway haven't bothered to check the the protractor, I'll do it when boat on the hard in spring)
Note that stbrd fin moves slightly less. Manually dropped it's limits on some earlier tests haven't (on purpose) brought it up to port fins limits.
Further, note that all graphs are with fin travel at 90% of full (and give another 3-4% of safety margin that I'll add when finetuning the fins next summer)
so system runs at approx 86% of full amplitude, and with I'd guess only around 80% of efficiency due to hydraulics routing and slower system pressure (running at 65-70bar against a max of 95-100bar iirc).

flat water discard the jerkiness of the fin angle values their integer values typically toggle between 2 nearing numbers hence the zig-zag, just a mater of granularity of data as processed by the arduino-fin not actually moving!:

note how much the roll rate midpoint curve is moving up and down especially 1/4 to the right of the graph [analysed below]:

fins now start moving, again orange line all over the place. Don't ask why port fin moves a bit and then stops (both on this and the next graph) haven't got the faintest idea, got to investigate further. I could imagine it's to do with a tiny instruction to move which is cancelled and only port gets the hydraulic pressure/power to do so for a split second, but then s/w should really instruct the fin to be in that spot, else on next loop it would move back to wherever it should have been. Will check relay states for sure:

starting stopping, roll not too much, a couple of flaps of the fins stop the roll, comes back after a while. Note same dodgy behaviour from port fin, only to be slightly matched at a point just right of the middle of the graph by stbrd fin:

full blown roll. Would be in the 8+ rate if they weren't on. This is a situation that I'd be happy to see roll down to 2 and not 4, but I hope I'll get there at the end when full fin amplitude is used and hydraulics are rerouted properly:

now fins turned off (halfway through the following plot) boat rolling a bit:

again fins are off, after a while roll has increased to a slightly uncomfortable 4:

After the 15min of roll when the liner came into port last night and whilst reviewing the plots, I realised that one of my problems is the orange line, midpoint curve of roll rate. It's too sensitive and thus loses the plot (excuse the pun) once a correction is done and the roll sinusoidal curve is temp reversed and then continues in the original direction. As a result, when my Task1 loop as described four posts above is trying to find if I'm crossing zero or even worse when the task2 tries to establish if the maxroll is over the threshold compared to midpoint, values are all over the place and start of fin movement is delayed. As a result I altered the smoothing factor of the midpoint curve making it much less responsive (had a bias of 30/100 and dropped it to 5/100 so now it's extremely sluggish to respond to changes) and I think it will improve fin trigger response. Will check in the evening again. I feel I'll have to revisit my midpoint calculations but it's last week of classes and have way too much to do before xmass break. Anyway, that's the on the spot correction, looks much better:

Finally a final plot this time on roll under 1.1, turning system to manual to check how smoother the midpoint calcs are. They are definitely better but I bet my approach is wrong anyway and I have to move to a rolling average calculation or something. Got to be computing power friendly though! Note that I now plot the limits of the acceptable roll rate out of which fins should be moving (instead of the midpoint - so midpoint + or - the 1.1 threshold). Not doing that bad, but since roll was really little it was overpowering the whole thing and I was playing with various fin amplitude values to get the feel of the whole thing:

My main problem atm is figuring out when it's the right time to park the fins in the middle. Since boat is in STAR mode, I'm doing all my tests with fins moving port or stbrd as needed but NOT parking in the middle when roll is too little. Tried it, but was introducing roll and messing balance a bit...
My original approach was move fins to port, then park, then move to stbrd and start again. But that's definitely wrong doubling the instructions to both fins and solenoids to no avail, so need to find the right condition to return them to centre. I have some code under testing atm but unless I solve the roll rate midvalue plot calcs properly there's not much point in working on this.
Obviously this wont work with the boat underway as leaving the fins to port or stbrd will lead to a listing driving a response by the system ad nauseam, not exactly the point of stabilisation

anyway, hope the above makes sense, off to work!

cheers

V.

PS. Bruce you have no excuse now, it's crystal clear, right?

 

[rgarside]

In the MPU 9250 product specification available from Invensense there's a reference to:-

Page 22 of 42
MPU-9250 Product Specification
Document Number: PS-MPU-9250A-01 Revision: 1.1
Release Date: 06/20/2016

"4.9 Digital Motion Processor
The embedded Digital Motion Processor (DMP) is located within the MPU-9250 and offloads computation of motion processing algorithms from the host processor. The DMP acquires data from accelerometers, gyroscopes, magnetometers and additional 3rd party sensors, and processes the data. The resulting data can be read from the DMP’s registers, or can be buffered in a FIFO. The DMP has access to one of the MPU’s external pins, which can be used for generating interrupts. This pin (pin 12) should be connected to a pin on the host processor that can wake the host from suspend mode.
The purpose of the DMP is to offload both timing requirements and processing power from the host processor. Typically, motion processing algorithms should be run at a high rate, often around 200Hz, in order to provide accurate results with low latency. This is required even if the application updates at a much lower rate; for example, a low power user interface may update as slowly as 5Hz, but the motion processing should still run at 200Hz. The DMP can be used as a tool in order to minimize power, simplify timing, simplify the software architecture, and save valuable MIPS on the host processor for use in the application."

It's a couple of years ago I was playing with an MPU 6050, and recalled that being referred to. I didn't get to the point of investigating how to make it work that way, and I don't know whether any of the available open source libraries access those functions. I think it is that sort of functionality that enables the nav systems of all the drones people like to play with.

I think I have missed where you explained how you calculate "mid-point curve of roll rate values", and what you use it for. I guess it has some "numerical" lag built in to it as it is probably based on history.

Once I had kept reminding myself that your graphs were all at rest, it looks like they are pretty good. It looks as though the system response is fast enough, and that they are being moved at about the right time.

I'm looking forward to the in-motion stages later too.