Writing a motion cueing software from scratch.

Thank you @Iromaniuk. It IS interesting indeed.

This is model predictive cueing. The grey shaded areas in the diagrams are the predictions and you can literally see what is meant by the term "receding horizon". Definitely more advanced than the classical filter based approach we are following here.

Thanks

Hey @Thanos or @pmvcda ,

Would you mind helping me out here a little? It's still unclear to me how exactly to convert into bytes to send data to the AMC1280. You gave examples for 0%, 15%, 50% and 85%, but I am unable to come up with the same values. *scratching head*

here's the code for a simple C# console application:

Code:

static void Main()

        {

            float utilisation = 0.150f;                                 //Actuator position between min(0) and max(1)



            UInt16 value = (UInt16)(UInt16.MaxValue * utilisation);     //Map utilisation to a value between 0 and 65535

            Byte[] Bytes = BitConverter.GetBytes(value);                

            Array.Reverse(Bytes);                                       //To get MSB first

            writeBytes(Bytes);                                          //Write bytes to thte console

           

            Console.ReadKey();                                          //Just to keep the console window open

        }

...but this is what I see in the console when I try to convert 15% into bytes:


How do you convert 15% into 064 000?

Here's what I do, step by step:
100% = 65535
15% = 9830
Binary: 00100110 01100110
Bytes: 038 102.

Can you tell me, where I am going wrong?

The data string has the following format:

ID AXIS1 AXIS2 AXIS3 AXIS4 AXIS5 AXIS6 AXIS7 AXIS8 LF/CR

- The ID is byte values 0xFF + 0xFF
- Each Axis is 16bit wide.
- LF+CR is required in the end (0x0A + 0x0D)


Here is an example in C ... kind of...

Code:

// variable Declarations
int outputValue0 = 0;        // value output 16-bit
int outputValue1 = 0;        // value output 16-bit
int outputValue2 = 0;        // value output 16-bit
int outputValue3 = 0;        // value output 16-bit
int outputValue4 = 0;        // value output 16-bit
int outputValue5 = 0;        // value output 16-bit
int outputValue6 = 0;        // value output 16-bit
int outputValue7 = 0;        // value output 16-bit

byte ID[2];
byte buf0[2];
byte buf1[2];
byte buf2[2];
byte buf3[2];
byte buf4[2];
byte buf5[2];
byte buf6[2];
byte buf7[2];
byte endstring[2];


//Normal loop with some calculations and conversions

// change the  output values from 16-bit to individual bytes (MSB first):
  ID[0] = 255;
  ID[1] = 255;
  buf0[1] = outputValue0 & 255;
  buf0[0] = (outputValue0 >> 8) & 255;
  buf1[1] = outputValue1 & 255;
  buf1[0] = (outputValue1 >> 8) & 255;
  buf2[1] = outputValue2 & 255;
  buf2[0] = (outputValue2 >> 8) & 255;
  buf3[1] = outputValue3 & 255;
  buf3[0] = (outputValue3 >> 8) & 255;
  buf4[1] = outputValue4 & 255;
  buf4[0] = (outputValue4 >> 8) & 255;
  buf5[1] = outputValue5 & 255;
  buf5[0] = (outputValue5 >> 8) & 255;
  buf6[1] = outputValue6 & 255;
  buf6[0] = (outputValue6 >> 8) & 255;
  buf7[1] = outputValue7 & 255;
  buf7[0] = (outputValue7 >> 8) & 255;
  endstring[0] = 10; //LF
  endstring[1] = 13; //CR


// Send bytes
  Serial.write(ID, sizeof(ID));   // Sends byte values 255,255
  Serial.write(buf0, sizeof(buf0));
  Serial.write(buf1, sizeof(buf1));
  Serial.write(buf2, sizeof(buf2));
  Serial.write(buf3, sizeof(buf3));
  Serial.write(buf4, sizeof(buf4));
  Serial.write(buf5, sizeof(buf5));
  Serial.write(buf6, sizeof(buf5));
  Serial.write(buf7, sizeof(buf5));
  Serial.write(endstring, sizeof(endstring));    // Sends Byte values 10,13

This is what I get:
0%: 000 000
25% 063 255
50%: 127 255
75%: 191 255
100% 255 255

Are you sure, that the values you posted are correct?

OK, thank you very much for the code! Straight forward I think I can understand and use it.

Could you still confirm 15% and 85%?

Thanks for the help!

Yes, this is correct conversions... You could eve use the windows calculator in programmer mode for conversions between hex dec or binary...

The reason there is 1 digit offset is because usually I deal with values like 127 or 255 instead of 128 or 256 for bytes...

I was searching for a paper which should come with the vid but I didn’t found it.

@Dirty , if you understand this prediction algorithm you could maybe explain the basics of this approach...

Two of them:

https://pdfs.semanticscholar.org/1973/f0ad15b60f4973d464ea5f4930a67de9fb0e.pdf

https://pdfs.semanticscholar.org/5637/233de0b69a0cb84fc3e206d3cf8b06538640.pdf

I have more somewhere...
But did not read them yet (it was grabbed by title).

Here http://people.tuebingen.mpg.de/fdrop/presentation_full.pdf is a presentation (not a paper) mentioned in this video. And here https://pdfs.semanticscholar.org/b57e/9b1716781318bb95ff5151cec7b35eba3605.pdf is a paper describing different MPC method.

It seems that it will be close to impossible to incorporate this kind of (MPC) controll algorithm in general purpose simulation (case of switching vehicle type from plane to car or even from daily driver to race car) since predictions are usually calculated according to some behavioral model of particular vehicle. Additionally some kind of feedback input (like telemetry of the platform or output from model of human vestibular system) is used to achieve more accurate predicitions. In general it's a fight for better workspace utilization which leads to better motion cues. Still I think that no matter what kind of algorithm is used it is impossible to mitigate false cues in case of agressive motion that is produced by race cars or acrobatic planes - that thought makes me wonder if making my hexapod with all its limitations is still worth it.

Well explained! Better workspace utilisation is a possible benefit of this. But the better it gets for one Vehicle the worse it gets for all others.
I think I said it somewhere before with the words: It's always a trade-off between making the motion more "gerneral" vs. more "specific".

For our use case (human-in-the-loop, open world scenario) predictions are of very limited use, because the better the motion gets when they are correct, the worse it gets when they are wrong

At least for flighthsims the idea of a simulator is NOT to have to follow a preplanned path.
"Touchdown on the runway" might be one of the few events that can be predicted with sufficient reliability. And even that only with a few seconds prior notice.

Dirty

I've often thought the same thing. But ever since SeatTime broke ground with his 6 dof simulator it seems most everyone wants a hexapod 6 dof now because they think its the best. Unfortunately a lot of creativeness people used in the past to build unique and better motion rigs has now been lost to, "Lets just build a hexapod 6 dof".

I'm more and more convinced everyday though as I've been developing a g-seat that a g-seat that's capable of applying adequate pressure in the right places for surge, sway, and heave along with a simple 2 dof (or 3) is the way to go. The g-seat handles sustained forces while the 2 dof provides basic acceleration and orientation cueing. VR likes it better too.

But I suppose if you're an actual pilot of planes or race cars and are looking to recreate real life experiences on a motion rig you are likely to be disappointed no matter. But if you're not then motion that is similar to the real thing should be enough for you to train yourself to accept these cues as a second reality.

. G systems are great and I added them to my 6DOF rig, due to (at the time) major cue algorithms shortcomings and to get more 'Gs' out of our small rigs. Had been mainly using my 6DOF for pitch/roll/heave (with a small/sharp amount of Sway/Surge), but with all these new 6DOF controllers now available, I look forward to getting back into tuning my 6DOF for a even better experience.

A 6 dof will obviously allow more types of cueing than a 2 or 3 dof. However when time and/or budget is a consideration then I would rather have a well functioning g-seat (or system) with a 2 or 3 dof than to have a 6 dof without a g-seat. With a g-seat its up to each individual to determine whether the additional expense of a 6 dof is worth it to gain the additional cueing.

Btw I don't know if the GS-5 is a well functioning G-seat or not since I've never been in one. But I'm skeptical about the use of just 4 paddles that apply pressure to the butt and back only. The G-seat I'm developing utilizes 3 additional zones. I've been delayed somewhat though due to finding the best motor(s) to use to heave with because it still takes a lot of power to heave a person even if its a couple of inches and be fast enough to simulate the road texture also without overheating after several laps.

I’ve been thinking about throwing an accelerometer on the platform and doing an automated set of runs - tweaking the motion cueing parameters a little for each run... then comparing the output of each run to the input.

That said, my masters report is in (and by the sounds of it, approved, yay me) so I think my wife might want the garage back for a while.

There are plenty of apps to measure/log accelerations, and I've had similar thoughts, but eventually I arrived at the question: What parameter(s) would I even want to optimise?
I found some articles about cost functions, but it hasn't yet "clicked" in my head.

Well, in my case it's about tuning the omega(s) in the motion cueing... and maybe my PID parameters.

i am one of these persons.
i just want to save time, building simulators are not easy.. and i hate to re-invent the wheel as well.
i am lucky to have everyone here as a resource.
part of me thinks its ok that there is a lot of hexabods, so that the hexapod community can share its successes and errors collaborate and improve their builds instead of tons of dissimilar designs...

i mean hexapod builders are pretty much following industrial designs.. how far can we go beyond that unless some has resources and space to build a man-size centrifuge..

Well I guess hexapod Stewart was a holy grail of DIY simulation for a long time due to extremly high costs (at a time - though building a 6dof now is still not cheap at all) and it's also quite complicated. Peapople where looking for other solutions to incorporate motion to their experiance.

As for the gseat - I must confess that I'm sceptical. G systems are pushing only certain parts of a body (to mimic sustained accelerations) but your head (and vestibular system in it) stays put - that's a serious drawback. On a 6dof you can emulate sustained acceleration with tilt coordination - sure it's limited (or rather should be) with rotation rate etc. but it acts on your whole body - that convinces me more - a drawback is that it's slow and easly can create false cues.

I'm not a pilot or a race car driver so it should be quite easy to make me happy it terms of motion as long as the motion makes sense to my brain ( or maybe to what it expects to feel)