Open AnthonyLeonardoGracio opened 7 years ago
One needs both matrices. At instant t (speed(t), altitude(t)) is the instantaneous "location" of the drone in the flight domain (FlightDomainMesh). You use this first matrix to find the 4 closest neighbours of (speed(t), altitude(t)) (you extract their i,j indexes in fact). Then you extract the 4 gains corresponding to the 4 pairs of extracteur indices, from the second matrix (xxxGains)
OK, thanks for the explanation. So in the tables xxxGains, we can only access values which are in FlightDomainMesh. But 6.7.2.3 states that the tables xxxGains are also indexed by Mass?
Hi Claire,
There is somehow a tricky aspect in the double indexation mechanism, that I will try to make clearer. It should also shed some light on issue #17 (same difficulty, but mass index supplementary stuff).
Why can’t we directly use xxxGain table (for phase xxx) ? Let us assume the grid on altitudes is 0:100:1000 (m) in Matlab notation, and arrays are indexed 1:N. So 1->0, 2->100, 3->200, …, 11->1000. i =1 to 11. Let us assume the grid on speeds is 0:2:100 (m/s), j= 1 to 51. So FlightDomainMesh(3,4)=(200,3). An IxJ array of integer pairs or two 1xN arrays of integers. xxxGain is an IxJ array of float (P,I,D) triples.
Suppose at time t, the instantaneous altitude-speed state is (246,75). We can’t directly access xxxGain because we don’t know where is (246,75) on the grid (alias mesh). Since 200 <= 246 < 300 and 74 <= 75 < 76 the four neighbors of (246,75) are (200,74), (200,76), (300,74), (300,76).
So you get the corresponding (i1,j1), (i2,j2), (i3,j3), (i4,j4) indexes (and you compute the four distances d1,d2,d3,d4). At this stage you can access xxxGain: xxxGain(i1,j1) -> (P1,I1,D1) …. xxxGain(i4,j4) -> (P4,I4,D4)
Finally you can compute the interpolated P(t), I(t), D(t), using the 4 Pi, Di, Ii and di …sets of coefficients (barycenter formula).
Mass is an additional index to acces to the PID gain coefficients. Mass does not evolve (unless icing … but it is not taken into account in the control laws). At init one consults the mass grid (payload mass grid), and get the m index, constant for the whole mission. You have indeed xxxGain(i,j,m) -> (P,I,D), instead of xxxGain(i,j)= … as said previously.
Hope this example helps.
Sincerely, Emmanuel
De : Claire Dross [mailto:notifications@github.com] Envoyé : jeudi 22 juin 2017 14:19 À : AdaCore/RESSAC_Use_Case Cc : Ledinot Emmanuel; Assign Objet : Re: [AdaCore/RESSAC_Use_Case] Confusion between gains table and FlightDomainMesh (#16)
OK, thanks for the explanation. So in the tables xxxGains, we can only access values which are in FlightDomainMesh. But 6.7.2.3 states that the tables xxxGains are also indexed by Mass?
— You are receiving this because you were assigned. Reply to this email directly, view it on GitHubhttps://github.com/AdaCore/RESSAC_Use_Case/issues/16#issuecomment-310363286, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AVVweDVes4-K8lClFTdKDFtypcchmsjnks5sGlu5gaJpZM4N_0z7.
It certainly does, thank you very much. Should we add the payload mass, or at least the corresponding m index, to the inputs of F_FC then?
No, F_FC has to compute it internally. It receives the payload mass and stores the mass grid, so F_FC has all at hands. The mass grid, like FlightDomainMesh and xxxGain tables, are PDIs. PDI = Parameter Data Item (aero certification jargon), i.e a data “hooked to the drone”, stored as “firmware” in static memory, common to all missions, and resilient to power off.
De : Claire Dross [mailto:notifications@github.com] Envoyé : jeudi 22 juin 2017 16:21 À : AdaCore/RESSAC_Use_Case Cc : Ledinot Emmanuel; Assign Objet : [Message publicitaire : ] Re: [AdaCore/RESSAC_Use_Case] Confusion between gains table and FlightDomainMesh (#16)
It certainly does, thank you very much. Should we add the payload mass, or at least the corresponding m index, to the inputs of F_FC then?
— You are receiving this because you were assigned. Reply to this email directly, view it on GitHubhttps://github.com/AdaCore/RESSAC_Use_Case/issues/16#issuecomment-310394705, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AVVweL485Hza527rtUlTHKM1P4EOL4fmks5sGnhDgaJpZM4N_0z7.
OK, perfect, let's just add payload_mass to the table 6.7.2.1 then. Should we remove EstimatedTotalMass from 6.7.2.2 or should it always return payload_mass since icing is not taken into account?
Let's just add payload_mass to the table 6.7.2.1 then.
Correct. Interface inconsistency.
Should we remove EstimatedTotalMass from 6.7.2.2 or should it always return payload_mass since icing is not taken into account?
None of both options. F_FC returns the estimated total mass though any estimated delta of mass does not modify the control laws.
De : Claire Dross [mailto:notifications@github.com] Envoyé : jeudi 22 juin 2017 16:34 À : AdaCore/RESSAC_Use_Case Cc : Ledinot Emmanuel; Assign Objet : Re: [AdaCore/RESSAC_Use_Case] Confusion between gains table and FlightDomainMesh (#16)
OK, perfect, let's just add payload_mass to the table 6.7.2.1 then. Should we remove EstimatedTotalMass from 6.7.2.2 or should it always return payload_mass since icing is not taken into account?
— You are receiving this because you were assigned. Reply to this email directly, view it on GitHubhttps://github.com/AdaCore/RESSAC_Use_Case/issues/16#issuecomment-310398578, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AVVweGdNIDmrXHdUZUSM7uOzPCMkk81zks5sGntAgaJpZM4N_0z7.
alright, we will ask about computation of Estimated_Total_Mass in another issue then. Thank you very much for all your detailed answers, these issues are becoming clearer.
Hi Anthony,
Have a look at issue #16, and possibly #17. It should provide intuition on the double index mechanism:
first table (domain mesh) to locate the 4 neighbors, whose index only you extract.
Then with those indices you extract the gains in the gain table
When I wrote to Claire I did it based on my memory of the spec. Tonight I read it again and I’m a bit concerned with the way I presented the “neighboring logic” to Claire. For Claire I used an interpolation view (finding the right interval in a sequence of intervals). As you are a control engineer, the cell centers are the points where the non linear AV model has been linearized for stability analyses and control synthesis (=> the PID coefficient for this neighborhood).
Don’t hesitate if it is still unclear.
Emmanuel De : Anthony Leonardo Gracio [mailto:notifications@github.com] Envoyé : mardi 20 juin 2017 18:17 À : AdaCore/RESSAC_Use_Case Cc : Subscribed Objet : [AdaCore/RESSAC_Use_Case] Confusion between gains table and FlightDomainMesh (#16)
Document: UseCaseDevelopment/Layer1_MMS/RESSAC_muXAV_SystemRQ_MMS_SW_Incr1.doc Commit: 74aa074https://github.com/AdaCore/RESSAC_Use_Case/commit/74aa0748114875dcf20bcdf7928afa69a77abb4b
In 6.7.4, it's said that the gains for a particular center are contained in a matrix called FlightDomainMesh, which is a matrix indexed by the speed and the altitude.
However, in 6.7.2.3, it's said that the gains are retrieved from three different tables (one for each mode): ClimbGains, CruiseGains and DescentGains.
Are they used for the same purpose as FlightDomainMesh? Which tables are used to retrieve the actual gains?
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHubhttps://github.com/AdaCore/RESSAC_Use_Case/issues/16, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AVVweP4nkZyTyW8Zdt3ozjA9zaSVeHUdks5sF_BqgaJpZM4N_0z7.
Document: UseCaseDevelopment/Layer1_MMS/RESSAC_muXAV_SystemRQ_MMS_SW_Incr1.doc Commit: 74aa074
In 6.7.4, it's said that the gains for a particular center are contained in a matrix called FlightDomainMesh, which is a matrix indexed by the speed and the altitude.
However, in 6.7.2.3, it's said that the gains are retrieved from three different tables (one for each mode): ClimbGains, CruiseGains and DescentGains.
Are they used for the same purpose as FlightDomainMesh? Which tables are used to retrieve the actual gains?