My 3DOF project is born!

Hi all, today I am TRULY happy about my 3dof!

In fact today is the first day that I had no problems about the connection lost of my jrks! since the start of my project over 1years ago..

all past test days had a connection lost or electrical problem.. no chance to obtain a full test day without these damn problems.

But today, 5 times I turn on my 3dof and 5 times without any electrical problems! nothing, even the smallest problem!! ;D

Ok, today I made these indispensable and important modification:

1) My major mechanical problem was the spring rigidity. After weeks of calculations and forecasts about the right spring for my configuration so I obtained an almost perfect spring BUT not perfect.. I made a wrong of 15kg. My spring is too many rigid by 15kg.
So today I put some extra weights on my platform, trying to respect at 100% my CG.
Adding these 15kg to my platform I perfectly reach the result of obtain my spring as a inverted gravity force (some amps if platform is at minimum position height or if the platform is at max position height! perfect balance!!.
Now my motor REALLY strives in equal way if it's challenging the gravity or if it's challenging the spring resistance.
beyond my best imagination! :thbup:

Before of today, when I was turning on my platform so the 3 motors were to half position and always I seeing my motors really suffering...
but today I watch my motors going on half position (and in minimum position too, when there is the maximum force against the spring resistance!) with a really easy behaviour!!
Today my platform going up and down with a really pure naturalness!
then really less effort = NO ONE TIME the connection lost! :yes:


2) Today for the first time I am using a usb HUB too.. here the info:
Model :
Trust Hu-1240Tp 4 port USB hub
Power rating : 5V DC --- 2Amps

3) Back to use 1 battery for each motor! (no more parallel batteries as adviced by pololu forum)


I don't know what of these 3 today modifications are the cause of the success.. I think both are really important..
Finally today I achieved a major milestone in my project life and If the next days will to confirm these results so my damn thing will reach the final goal!!

PS. All today tests made using DUTY CYCLE = 599/600 - ACCELLERATION 599/600, much more extreme configuration by the standards of recent days that was DUTY CYCLE 450/600 - ACCELLERATION 500/600.
So today much more effort but NO connection lost problems! ;D

Here my actual motor and PID configuration :



:

Looks like you are getting the hang of PID, good to see, continue to fiddle with if you need to.
I slowed my motor down a bit with PID, but still got good snappy motion in vertical. So motors calmed a bit an no errors here as well.

Hi bsft, my adventure with the PID it's just in the start.. I would to test with PID since I will find a PID configuration capable to beat or reduce the bad inertia of the winch mechanisms and gears.

Over that I need to play with PID to find a final solution to a little (but annoying) problem: In same inclinations circumstances I see that my LATERAL motor (right or left) when is under effort, start to drag other lateral motor.

Seems almost that in some platform inclination circumstances the power of one motor, helped by the platform weight, beat the power of the other lateral motor, dragging it (so and so 1 or 1,5cm) and making him to get OVER max pot value then making the jrk STOP the motor to avoid damages to the pot.

I could to use a 15 turn pot to avoid this problem making a larger range of possible motion (So sure this drag can't make the pot get over max position) or simply I could to reduce a bit the movement range to avoid to approach too near to the MAX pot position.

but I would to try to solve this little problem with PID.
is feasible in your opinion?

This was a tricky one as I had this problem with my big motors and single turn pots, but not the wiper motors with the same single turn pots, (yes I am recycling) . I found a combination on d adjustment and profile adjustment seems to fix this. I was getting overshoot - motor driver errors something fierce as well. I even set the feedback for less travel, more travel, didnt really help.
Anther thing that helped, thanks to Eaorobbie was the addition of the collision effect in the math settings. Once i had this figured out, thanks again to Eaorobbie, It really settled overshoot issues . For instance, I added the collision effect for each current motion, like vertical force - bumps, found a happy motion without crashing or anything big. Then I added the collision effect of this and where the smaller number is , I copy/pasted my number from vertical force into that and added 200 to the number. I left the auto adjustment of the big number alone.
What this does is give you bumps, but when you hit wall or really big bump, it settles the motion so you are not getting smashed around and causing errors and BIG power spikes to the jrks and motors . This really helped me sort my motor driver errors a lot. I still get the odd one, but thats just a need of a number change in the original motion profile setting, or reducing effect percentage or softening it up a bit.
Try this and see how it goes.
Cheers, David.

mmm seems to be a good tricky! Thank you very much bsft, I am really curious to check it!
From what I understand, this adding collision effect is just to deceive the x-sim making it to stay in the pot range avoiding to get an over shoot instead to actually have a collision effect (indeed you add just 200 value).

Thanks to you and Eaorobbie too! :

Thats right ,add 200 to the value you already have in the current force, so for example, if the lateral is 177500, you would put in 177700 in the small number section of the collision and then let the effect find the big number itself. If you like you can raise or lower this number as you wish to get a good feel for motion. I use between 200 and 500 on top of original number.

Mmm good example but,continuing to follow this example, what is the number you are using to the trigger? (I mean the number that when it's overtaked so the collision effect can start)

Are you meaning that this small number selection is the trigger (flag) number that if overtaked make start the collision effect?

I am at work and I don't forget how the collision effect math plugin page is structurated.. :

I will take a screen shot or two later and post them to explain

Ok here it is...

The bottom pic is the force and I have circled the number I use. ( you use whatever number you have ).
I copy - pasted that number into the collision effect and selected the same force and put in the threshold value and I added, in this case 300 to the overall number. Adding a bit allows you to get that slight extra bump before the collision effect takes over. I left the maximum value alone as the program finds its own number. The I adjust time of effect ( 0.1 - 1 second) . I did this under instruction from Eaorobbie for all my forces on all axis.

Thank you so mutch bsft! Now it's perfectly clear! :thbup:

Hi again bsft and hi all,
please take a look on these pics about my threshold collision effect solution to avoid the overshoot of my motors on the 26 effect / vertical force :





You can notice that:

1) I put the threshold math plugin line just below the 26 effect line and not as the last line of the axis.

2) I am using 550000 as maximum gForce math value and I am using this same value for the threshold value in the threshold collision math plugin

3) So when the value will reach the 550000 value so the collision event will start.

4) In the threshold collision math plugin page I put 549000 as the maximal value +/-.
My idea to avoid the motor overshot is : When the 550000 value is reached and the collision event start so immediately later I will obtain a value that forces the motor to stop his run to the over limit position because the new collision event order is that the motor have to change is direction.
I hope you can understand what I mean!

5) I am using inverted input value and effect as negative shock in the threshold collision math plugin page to obtain the collision effect start ONLY when I reach a -550000 value (negative value).
So I don't want to obtain the collision effect start when I get positive 550000 value. The collision event must start ONLY when I get a negative value of 550000.

6) After these 5 point I ask to you : Are we sure that the maximal value +/- on the threshold collision math plugin is the value that the motor MUST reach when the collision event will start??.. right?? :

It's all correct ?

PS:
I am pretty melted after all these work weeks on my platform!.. :?

Add 200-500 to threshold value, leave max value alone, it will always update its own number , try that

Sorry bsft if I repeat question, but I would to get perfectly the situation challenging my evil english..

When you write max value alone so are you meaning to check the automatic maximum adjustment on the gForce 1:1 plugin?

or you mean just to leave the MAXIMAL VALUE +/- from threshold collision math plugin without modifications?


If you mean the one from gForce 1:1 plugin so I noticed that checking the automatic maximum adjustment then I obtain an automatic value in the maximal value +/- in the threshold collision math plugin. So probably you mean this..

or you mean just to leave the MAXIMAL VALUE +/- from threshold collision math plugin without modifications?

That is what I mean. You have got it.
:clap:

Thanks mate, today I made a lot of optimization about profiler , pot configuration and weight balancement... I hope tomorrow or saturday I can test these new optimization and finally to find the final configuration!

What a battle dude... :headfullofmath:

Hi all! This morning for the really first time I made a COMPLETLY NO ELECTRICAL AND OVESHOT PROBLEMS test with my 3dof!!

I am really happy about. Today I feel a sense of tranquility while doing the test and this is a GREAT news for me!

No connection lost problems, no mechanical problems, no overshoot problems! (THX bsft and Eaorobbie!)

Really a lot of time of problems and solutions, problems and attempts and tests and slowly the chances of obtain some problems decreases more and more!

Really fascinating challenge, really fascinating how the work, the tests and the perseverance can make you obtain better results!

Sure I lost a lot of brain cells in this last year working on my 3dof but thx to the x-sim forum and to my team mate I am really happy about my ugly mechanical moving creature



Here the vid of 2 laps on A1ring (Austria) and an onboard cam in Suzuka (Japan) with Subaru impreza 2006.

http://www.youtube.com/watch?v=d4Q2E7g6i68&feature=youtube_gdata
You can see the vertical motion finally working good! and the lateral and longitudinal inclinations near to 90% of their full range!


http://www.youtube.com/watch?v=1xksv4ro2jI&feature=youtube_gdata
Unlucky I put the camera a bit too low but you can notice well the rudeness of an hard driving on the left/right/left/right Suzuka corners! Notice the hard force of the braking moments and of the uneven road surfaces!



The profiler configuration was not again perfectly what I want to obtain but was enough rude to test propely my platform. Sure is not my more rude profile but was ok for this morning tests.
Next tests will be more vertical travel (today so and so was 20 cm), I can push my platform up to 32 cm using these pots (up to 35 cm if I will change the pots with 15turns pots)


Jrk config setup:

PWM frequency 20Khz
Actual duty cycle = 599/600
Actual accelleration = 599/600
Brake duration = 50
Max current = 0 (no limits)
Current calibration = 255

PID configuration = 4/2 - 0/3 - 0/0 (I think not my best PID setting and sure this one don't push the motors to their max speed.. next tests will use a best PID!)
PID period = 33ms
Integral limit = 10000
Feedback dead zone = 25

Abs Max = 4013
Max = 3693
Min = 400
Abs Min = 80


In the very end of time test of today I get a new never seen problem (lucky I think will be easy to solve!)
Please take a look to my spring after a total of 3 or 4 test days:



For this new spring, I avoided to put the welding to block the spring in the up and down attachment points. This mean that using my platform I obtained the spring rotate in his attachment point producing this bad situation!.
I notice in the last test that on coil touching the cylinder blocking for some moments the motor and giving an amps peak to my jrk.
Today I will work to repositioning the spring to avoid this bad situation and probably I will to put 2 welding points.

:hi:

hi aldoz, great job!!!, it is very good :cheerleader:

Thank you very much Christian!

Awesome movement!

Not that it's anything to do with you spring problem but I do think your pid calculation at 33ms is a little slow, I can clearly see that from the action on your LCD the motion effects are maybe slightly delayed. A time of 16 ms is considered average for race style motion simulation your body can interperate motion signals faster than your eyes can translate the motion effects. As you are using 3 individual axis and 3 controllers each can interpret a motion signal at the same time with little effort than 1 controller interpret 3 axis. If you can with the pololu try bring it down to below 16ms this will feel alot better and you car control will improve also. Not being critical but if you want a race simulator with great feedback this is the key.
I don't know what to suggest for the spring solution possibly a semi height cylinder to keep your spring in a central position.

Hey Barts, its good that you can tell the difference between 33ms and 16ms, by the way , is that in the profiler? Should Aldoz account for the 25ms rate in the JRK utility as well? Maybe he should reduce this?
You sound like you understand the JRK boards well, maybe you can suggest a PID rate he can use.
Its also good that you know the winch motors and their behavior as well, and the way profiles react on a simulator.