question

jrm1493 avatar image
jrm1493 asked jrm1493 answered

Closed loop SimInertial latency over scramnet?

Are there any resources describing system latencies introduced when using SimInertial being fed trajectory data over scramnet? In particular, what kind of time lag can be expected between the writing of trajectory data to scramnet by the "truth" sim and the response to trajectory events on the output side of SimInertial. I am using a GSS8000, and Honeywell ISRS-2 card for INS model type.
SimGENPositioningSimREMOTESimINERTIAL
2 comments
10 |950

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

LarryVeilleux avatar image LarryVeilleux ♦♦ commented ·
I am checking with our support team for an answer to this now.
0 Likes 0 ·
jrm1493 avatar image jrm1493 LarryVeilleux ♦♦ commented ·
Thanks! --John
0 Likes 0 ·
LarryVeilleux avatar image
LarryVeilleux answered LarryVeilleux edited
There is no existing answer specific to SCRAMNet and SimINERTIAL but knowledge base article SOL10324 gives some standard theory (you need to log into support.spirent.com to see it). You have to consider the following:- 1. Average latency of the SCRAMNet interface 2. Chosen scenario iteration rate 3. How soon/late the commands arrive at SimGEN wrt scenario iteration rate -The chosen scenario iteration rate and command arrival time are bound to dominate. So you can pretty much ignore point 1, in general (though of course there could be a faulty cable or something that can impair the system so always be mindful of it). -Motion is sent to SimGEN which in turn updates SimINERTIAL. -SimGEN has to work 2 epochs in advance when running SimINERTIAL, this means that it is always extrapolating the vehicle motion data -When SimGEN is at time into run T it is sending data for T+Tir to SimINERTIAL (where Tir is the iteration rate), so that SimINERTIAL has the vehicle data for Tir in advance in order to generate inertial data at Tir -So if we assume a command for time T arrive at SimGEN at time T, SimGEN has already sent data for T+Tir to SimINERTIAL at this point, so the command for time T isn’t used in SimGEN until T+Tir, at which point SimGEN is preparing data for SimINERTIAL at T+2Tir. -Hence the latency at the SimINERTIAL side will be ~2Tir, whereas at the SimGEN side it will be ~Tir However, it is more likely that the command for time T arrives just after time T at SimGEN and misses SimGEN’s computation cycle that takes place at time T ready for time T+Tir (T+2Tir in SimINERTIAL), hence latency is more likely to look like 2Tir at the SimGEN side and 3Tir at the SimINERTIAL side. This extrapolation technique should not pose any concern as long as the incoming remote commands are self-consistent and reliable.
10 |950

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

jrm1493 avatar image
jrm1493 answered
Thanks for the info Larry This is exactly what I am looking for... trying to get an idea of the overall latency for our HIL system. When we have large changes in trajectory dynamics we have found that the SimInertial will try to "catch up" by increasing inertial DV/Dtheta output beyond what is actually sent over scramnet. This makes sense based on what you have described, and of course it keeps our state "good" but it also means that the IMU output is not exactly like what one would expect in real life. Based on the way the closed loop sim has to work (with dynamics prescribed by our sim truth model), I don't think there is any way to really avoid this. We have found that fake timestamping scramnet commands a bit in the future helps cut down on this extra IMU output, but I think this is just an artificial fix and we should not be doing it. --John
10 |950

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.