Estimated local acceleration is logged at low rate about data-driven-dynamics HOT 18 CLOSED

@manumerous Logs are in https://github.com/ethz-asl/data-driven-dynamics/tree/master/resources

from data-driven-dynamics.

@manumerous Sure, I think we need to get in a mode where if things are unsure we have systematic checks that verify certain assumptions with code. This problem will only get worse once we have real vehicle data where you have multiple imus with all different orientations

from data-driven-dynamics.

I was a bit confused about what the actual acceleration is and what the sensor measures

Just try to remember that when you place an accelerometer on a table, it will measure one g up (from the table). In hover, the rotor thrust is acting as your "table", so again the accelerometer will read one g up. Similarly, if you have a fixed-wing plane flying level, the lift is now acting as the "table" giving you again a reading of one g up. This means the accelerometer isnt actually measuring our true coordinate acceleration (i.e. the rate of change of velocity), and is why we need to subtract out gravity when we want to compare a "true" acceleration (left hand side) to e.g. your newton euler equations with aero/thrust build up.

from data-driven-dynamics.

I think you are right by not including gravity the proper way. However, the results currently show accelerations of constantly -20m/s^2. And it also seems weird that in both topics above the gravity offset is in negative direction. That would suggest that they are not in FRD frame I guess.

from data-driven-dynamics.

Could the body frame the acceleration is expressed just be rotated by 180 degrees compared to the FRD frame? It seems to be the case from this mission log where I would expect the acceleration in x direction to be positive.

from data-driven-dynamics.

@manumerous Now I am confused. What is the difference between the logs in #45 ? The logs in that PR show close to 10m/s^2 which I would have expected.

Where did you get that plot and which model is it using?

Anyway, this just points to the fact that we urgently need more tooling to verify that part of the code is correct. Looking at the plots and judging sanity can be misleading.

from data-driven-dynamics.

I just downloaded the new code and used a log of a mission to generate the simple_multirotor_model. Yes I also would have expected that and was a bit surprised.

Yes I agree, else it is impossible to to make any valid statements about how well it fits.

from data-driven-dynamics.

@manumerous So, what you are saying is that with the test log I have provided in the PR it shows ~9.8m/s^2 but in the mission log that you generated it shows ~20m/s^2?

from data-driven-dynamics.

Yes exactly. Although I did not test with your log. Where would that one be?

from data-driven-dynamics.

Also strangely enough when I adapt the VTOL model to the new format and test it with a mission log it seems to work fine:

from data-driven-dynamics.

But maybe before adding some tooling it would be essential to know exactly what the data we are using and in which frame it is represented. Without even knowing this the hole code is just prone to errors and we can not even validate the transformation with the attitude quaternion.

Currently it sems that thte sensor combined topic is in some kind of body frame different from FRD. But Airspeed is computed in FRD currently. Adding more complexity before this is fixed makes it just harder I think.

from data-driven-dynamics.

But maybe before adding some tooling it would be essential to know exactly what the data we are using and in which frame it is represented. Without even knowing this the hole code is just prone to errors and we can not even validate the transformation with the attitude quaternion.
Currently it sems that thte sensor combined topic is in some kind of body frame different from FRD. But Airspeed is computed in FRD currently. Adding more complexity before this is fixed makes it just harder I think.

@manumerous I am not sure if I agree. You need tooling to prove what part of your code works and doesn't 😄 The plots you are making is not enough to decide what is going on in the pipeline. So there is no point looking at it

Basically, you need tooling to prove exactly this

it would be essential to know exactly what the data we are using and in which frame it is represented. Without even knowing this the hole code is just prone to errors and we can not even validate the transformation with the attitude quaternion.

If you can't find documentation, just add a simple test to see figure out what frames they are using. You can do kinematic consistency checks between inertial estimates and body estimates and comparing the transformed values. The fact that it is not documented well, and there is no one to tell you what the correct frame references are cannot be a blocker

from data-driven-dynamics.

Yes, I am trying to reverse engineer that. Currently I did the following:

• take the accelerations from vehicle_local_position
• substract 9.81 from the z axis
• transform it into body frame using the method of the DynamicsModel
• compare it to the sensor_combined acceleration
  

So this way we can transform from one into the other frame ant it works fine. I am just a bit confused that apparently the z axis of the frame of vehicle_local_position and the frame of sensor_combined seem to point upwards. What contradicts all the px4 FRD/NED conventions.

But this way we can validate that we can correctly transform between the frames used by the two topics.

from data-driven-dynamics.

@manumerous Can you provide somekind of math/equations on what you are doing? "subtracting" is an ambiguous term if we are talking about vectors.

And how did you come to the conclusion that the coordinate system is pointing upwards? (I don't think this is true) - you can check this by looking at the position / velocity.

It is anyway better to have a doc somewhere in this repo where we keep the math on even grounds for everyone (latex or pdf)

from data-driven-dynamics.

Yes sure:
I calculate _I (ax, ay,az)^T = _I (ax, ay,az)^T - (0, 0, 9.81)^T
Then i generate a rotation matrix C from the quaternion q to transform the accelerations into body frame
_B (ax, ay,az)^T = C_BI * _I (ax, ay,az)^T

Good point yes you are right about the velocities. Here it seems like the z axis is pointing downwards. This is what confuses me.
I mean if we have for example in the inertial frame an acceleration vector a= (0,0,-10)^T and the z axis of the frame is pointing downwards the vector has to point upwards, because its z component is negative. In case of our acceleration vector that would mean that either gravity is pointing upwards or the z axis is pointing upwards. Here the latter seems much more likely.

Or am I missing something?

from data-driven-dynamics.

@manumerous Since all the inertial accelerations are almost close to 0, you are just transforming your vector - (0, 0, 9.81)^T which may or maynot be related to gravity. Can you elaborate on why you think the vector subtracted by - (0, 0, 9.81)^T to match the accelerometer measurements?

from data-driven-dynamics.

Ah yeah my mistake. You are right it is pointing downwards... I was a bit confused about what the actual acceleration is and what the sensor measures. Sorry for the confusion.

Sure. I can elaborate on that. But maybe it is more efficient to do that in a short video call after the presentation if you have time?

from data-driven-dynamics.

I was a bit confused about what the actual acceleration is and what the sensor measures

Just try to remember that when you place an accelerometer on a table, it will measure one g up (from the table). In hover, the rotor thrust is acting as your "table", so again the accelerometer will read one g up. Similarly, if you have a fixed-wing plane flying level, the lift is now acting as the "table" giving you again a reading of one g up. This means the accelerometer isnt actually measuring our true coordinate acceleration (i.e. the rate of change of velocity), and is why we need to subtract out gravity when we want to compare a "true" acceleration (left hand side) to e.g. your newton euler equations with aero/thrust build up.

Thx yes that together with not knowing which frames are used was exactly what confused me again in the beginning. :)

I remember know. It is because the gravity pulling on the proof mass has the same effect as if the accelerometer would accelerate with 1 g upwards in space (or anywhere without gravity).

from data-driven-dynamics.