Writing a motion cueing software from scratch.

Nothing is perfect. For the head you could also use a helmet g-system I suppose. But as I stated a g-seat along with a simple 2 dof to provide acceleration and orientation (tilt) cues for surge, sway, pitch, roll, and minimal heave works pretty good to immerse you. A 6 dof provides even more cues though if you have the time/money to go that route. But with a g-seat providing pressure for surge and sway, I don't think that the linear surge and sway a 6 dof can provide is really necessary. It would be nice having yaw for flight and traction loss for autos though as well as additional ability to provide heave.

Hey guys, I'm deleting these two posts and replacing with more updated thoughts after some more experimenting. I've been at this for six hours now!

So after trying some other things I'm back to being convinced that with the filters and features available in FlyPT the only problem remaining is the motors not being perfectly synced.

Any thoughts on how to improve this would be very very much appreciated.

The problem is that when there's a heave movement, and one actuator lags behind for an instant, then catches up it causes a very sudden false cue. Mostly it's perceived as yaw I'd say.

But the main thing is it's just jarring because it's a pretty significant "bump".

I have issues with pitch as well which may or may not be the same thing, I'll have to go after that next. Anyway, I've got my heave to where I think I'd be satisfied with it if it wasn't for those bumps from one actuator lagging behind.

This doesn't happen every time, but it happens very frequently.

Any ideas on how to solve it? Re-doing the auto tuning on the VFD's was suggested, so I'll probably try that in the next day or two.

Hey guys,

maybe someone (@Thanos? @pmvcda? @Trip Rodriguez? ...or anyone else with am AMC1280?) can help me with this. I would like to support the AMC1280 in my software, but I am not sure if the bytes are being transmitted correctly, since this is the first time I am ever sending bytes directly. I own an AMC 1280, but I am not seeing any reaction from it. To be honest I don't even know where to look for one

Up until now, I have used my own controller...

...made from a custom PCB and cheap components from Adafruit. I will also publish it open source once I got to do some testing. Still I would like to keep it compatible with the AMC1280's data format, because I think I might eventually switch over to the (way more advanced!) AMC1280.


Would some of you be so kind to download the software from here and just follow these steps.



Basically, all you need to do is:
1. Connect to the COM port of the AMC1280
2. Move the platform up and down using the "Platform Control" window

I would just like to know if the data reaches the AMC1280 correctly.

That would be super cool of you! Thanks!!!

Dirty

btw: The black box in the top right corner of the video is an overlay from my own serial monitor, it is not present in the software.

I don't have the AMC1280, but if those numbers are what is sent through the serial, then it's OK.

Ok, I downloaded your software and followed your instructions:
https://github.com/Dirt-e/Nutkicker_Motion_Controller

But there was no motion. I fired up the serial monitor and it looks like you are sending wrong data, the AMC does not respond unless the correct type data is received.


See a capture of the data your program is sending:

Code:

3C302E303030313B302E303030313B302E303030313B302E303030313B302E303030313B302E303030313E0D0A3C302E303030313B302E303030313B302E303030313B302E303030313B302E303030313B302E303030313E0D0A3C302E303030313B302E303030313B302E303030313B302E303030313B302E303030313B302E303030313E0D0A3C302E303030313B302E303030313B302E303030313B302E303030313B302E303030313B302E303030313E0D0A3C302E303030313B302E303030313B302E303030313B302E303030313B302E303030313B302E303030313E0D0A3C302E303030313B302E303030313B302E303030313B302E303030313B302E303030313B302E303030313E0D0A3C302E303030313B302E303030313B302E303030313B302E303030313B302E303030313B302E303030313E0D0A

<0.0001;0.0001;0.0001;0.0001;0.0001;0.0001>
<0.0001;0.0001;0.0001;0.0001;0.0001;0.0001>
<0.0001;0.0001;0.0001;0.0001;0.0001;0.0001>
<0.0001;0.0001;0.0001;0.0001;0.0001;0.0001>
<0.0001;0.0001;0.0001;0.0001;0.0001;0.0001>
<0.0001;0.0001;0.0001;0.0001;0.0001;0.0001>
<0.0001;0.0001;0.0001;0.0001;0.0001;0.0001>


3C302E353335373B302E353335373B302E353335373B302E353335373B302E353335373B302E353335373E0D0A3C302E353335373B302E353335373B302E353335373B302E353335373B302E353335373B302E353335373E0D0A3C302E353335373B302E353335373B302E353335373B302E353335373B302E353335373B302E353335373E0D0A3C302E353335373B302E353335373B302E353335373B302E353335373B302E353335373B302E353335373E0D0A3C302E353335373B302E353335373B302E353335373B302E353335373B302E353335373B302E353335373E0D0A3C302E353335373B302E353335373B302E353335373B302E353335373B302E353335373B302E353335373E0D0A3C302E353335373B302E353335373B302E353335373B302E353335373B302E353335373B302E353335373E0D0A3C302E353335373B302E353335373B302E353335373B302E353335373B302E353335373B302E353335373E0D0A3C302E353335373B302E353335373B302E353335373B302E353335373B302E353335373B302E353335373E0D0A3C


<0.5357;0.5357;0.5357;0.5357;0.5357;0.5357>
<0.5357;0.5357;0.5357;0.5357;0.5357;0.5357>
<0.5357;0.5357;0.5357;0.5357;0.5357;0.5357>
<0.5357;0.5357;0.5357;0.5357;0.5357;0.5357>
<0.5357;0.5357;0.5357;0.5357;0.5357;0.5357>
<0.5357;0.5357;0.5357;0.5357;0.5357;0.5357>
<0.5357;0.5357;0.5357;0.5357;0.5357;0.5357>
<0.5357;0.5357;0.5357;0.5357;0.5357;0.5357>
<0.5357;0.5357;0.5357;0.5357;0.5357;0.5357>

See a capture of what the normal data the AMC should see...

(By sending "RQM" to the AMC, you should see it respond with its firmware version "AMC1280USBm6v3.5")








Thanks
Thanos

Ahrggh.... Yes, of course!!!

God, how could I have been so stupid!?! Sometimes I wonder how they can let me fly planes...

I changed the code, rebuilt the executable, but did not push the commit to the Github page! It's updated now.

I looked at it in a serial monitor and now I see the 20 bytes starting with "FF FF" and ending with "0A 0D".

Could you try again? Or could you tell me where to look to see if the AMC1280 receives the data properly? I was hoping I'd see some numbers change in the display, or some bar graph dance up and down, but I see nothing.

Could you check? That would be a tremendous help.

I checked again. Now the COM port opens partially, See some data going through, but only 115kbps speed... The AMC needs 250000 baud rate.

"COM is open Baud rate 115200 RTS off DTR off Data bits=8, Stop bits=1, Parity=None "

OK,

Thanks A LOT.

I will try again tomorrow with 250000 baud. I thought it would work with any baud rate up to 250k. Didn't know it needed exactly that.

Thanks for the help.

Dirty

Looks like I came to late to help test, but all I would have been able to report is "not working" so it's lucky Thanos came to the rescue! I will probably be able to test for you tomorrow (late evening US Eastern Time) so if you have any tests you want me to run just post instructions for me. =)

At this point I believe strongly that a G-seat + 6DOF is the way to go, but a G-seat with 4DOF might be just as good.

Quick question guys, I just noticed during my testing that my sim does not go straight up and down when using pure heave movement.

Starting with heave at lowest position, as it comes up to mid travel the platform moves forward about 20-25mm, and as the platform continues from mid travel to max travel it then moves back about 20mm.

So heave axis by itself looks like this instead of straight vertical line as it should be:

..........\
............\
............/
........../

If using fast heave movements it creates roughness and false cues, so I'd like to fix it. What do you think is causing this?

Hi @Dirty ! I hope you are enjoying your holiday. =)

I have confirmed that it works. =)

I wasn't seeing anything on the display, but I wasn't satisfied with that.

I fully disconnected one of my actuators so that it could spin full circles at any speed safely and fired it up.

Results:
When I launch DCS and let it run with the Ka-50 flying around via keyboard inputs I get what looks like nice smooth motion. =)

The rest is outside the scope of the requested test so may be invalid data but I thought I'd post it just in case it's useful:

Park position appears to be set to zero. With my AMC1280USB (set to 12bit DAC) I learned previously that it does not read the sensors properly when it approaches 0%, if a position below that is requested by the AMC the actuator spins full circles, moving slowly when it is near 0% and fast the rest of the way around. Rinse, wash, repeat. So this is what I get when in "park" position.

When I move to "pause", it appears to go to somewhere near the 100% position and stay there.

Thank you very much, @Trip Rodriguez

in "Park" it should send a value of almost 0% , in "Pause" it should send a value close to 50%

What I'm getting is this:


..so it appears that changing the Baud rate to 250k helped. Does that screen mean everything is OK?

Strangely I am not getting anything other than that screen. Is that normal? Isn't there supposed to be some numbers representing the target values? If I press some buttons, eventually the screen will go blank. Is that normal too? @Thanos , can you take the time to take another look at this?

Download Link still here: https://github.com/Dirt-e/Nutkicker_Motion_Controller

That would be great!

Dirty

Hi,

Yes, this screen is normal. I disable the LCD updated during normal operation with motion cues, to get the max performance out of the controller.

I'll try the new version soon. Thanks

Ahhh, great! Thank you! That's good to hear.

Ok, tested it on my AMC mini rc servo platform and moves correct from park to standby position...



Thanks
Thanos

COOOOL!!!!! HAARRR,..... That is so cool! Thank you very very much!!

This is actually a major milestone reached on my roadmap. I was a bit anxious because the display went blank when I tried it, but looking at it from a performance point of view, that makes total sense. Thank you so much for your support!

Dirty
...just can't stop smiling...

You can actually place a jumper on the S4 on the AMC board and will force to keep the bars on the screen while connected to motion software. Also you can push the encoder button while on bars screen to switch to display percent numbers on the display for the position of each axis...




Thanks
Thanos

I hope the next major milestone will be rotary support

keep your ideas up !

Crank arm setups are certainly a point on my list, but I have to admit that so far I just lack the "intellectual access" to the topic

I know how stupid this sounds, but for many other problems I knew long before I had the solution THAT I was gonna find a solution. The thing with the crank arm setup is this: There are always two possible solutions for the equations of motion. However, only one of them will correspond with your actual hardware setup and the other one will be a "phantom position" somewhere in the other hemisphere of the servo arm. I just don't have a clean mathematical solution how to distinguish the two.

And I should probably also admit that I haven't yet invested all too much hammock-time into the problem, as it was never a make-or-break issue for me personally.

I know @pmvcda made a good post about the math in one of his threads a little while ago, but for the life of me I can't find it anymore. Maybe you can point me to it.

Dirty