Obscure practical math problem

[DavidU (Dave)]

Originally Posted by ballaratdragons

Fred,

the sigmoid curve speed function can be extended and smoothed with little, but useful, distortion of the curve but the 3N-dimensional configuration must be balanced thus:
i \hbar {\partial \over \partial t} \Psi(x_1,...,x_n,t) = \hbar^2 (-{\nabla_1^2\over 2m_1} - {\nabla_2^2 \over 2m_2} ... - {\nabla_N^2\over 2m_N} ) \Psi(x_1,...,x_n,t) + V(x_1,..,x_n,t)\Psi(x_1,...,x_n,t). \,

but to be Time independent, you cannot use Rally's suggestion of Y-c = (x-b)/sqrt(1+(x-b)^2).

To be Time independent AND achieve proper smooth transitions between speed steps this must be the resultant configuration:
\psi_{-|E|}(x) = C_1 e^{\sqrt{2m|E|/\hbar^2}\,x} + C_2 e^{-\sqrt{2m|E|/\hbar^2}\,x}.\,

If you end up with a backwash effect from any form of Time dilation you will need to run a discrete delta potential method scenario to test it.
Here is how:
Φ(s) = ∑ G(s,ai)V(ai)Φ(ai) + γ(s)

Good luck.
Glad to see you have plenty of time on your hands to attempt this project
With all this rain, I suppose there's not much else to do

[renormalised (Carl)]

Second that motion, Dave!!!!.

[AndrewJ]

Gday Freddy

"If you want to modify just the red portion, then break it in 3: first and third curves from a lookup table, the second (red) is a linear function ds/dt = constant".

Brilliantly simple and doable http://www.iceinspace.com.au/forum/....es/happy04.gif.

Another thing to look at is whether parts 1 and 3 of the function
are symmetric.
If so, you can use just one lookup table and hence crib some space or expand the resolution of the tails.

Andrew

[DavidU (Dave)]

It reads like a Bert solution to a sigmoid curve speed function solution.

Originally Posted by renormalised

Second that motion, Dave!!!!.

[Bassnut (Fred)]

Originally Posted by AndrewJ

Gday Freddy



Another thing to look at is whether parts 1 and 3 of the function
are symmetric.
If so, you can use just one lookup table and hence crib some space or expand the resolution of the tails.

Andrew

Yes, thats a good idea Andrew

[rally]

Fred,

What are the contents of the look up table
How many fields, and how many data sets ?
Can you post it in its entirety ?

You are asking for a solution without giving anyone much information - and then feeding it out in dribs and drabs as each solution fails to meet some new constraint !

[Bassnut (Fred)]

Rally, sorry.

There is one fixed lookup table, 255 numbers between 0 and 65000 scaled to a sigmoid curve (loaded from exel as a text file, a string of comma seperated numbers). I pre-scale the time variable input used as the table lookup position (can be from 1min to several hrs) to 0-255 and pre-scale speed variable input (stepper motor tick difference between start and end) to 0-65000.

I then look up the converted curve speed in the table and rescale back to the original input format. Its course and rough, but suprisingly smooth on playback. The controller is a pause move device, so theres plenty of time to do all this on the fly during pauses.

Since the PIC is integer only, I can only really do simple +-*/ math, and also resolution is a big problem. Luckely there is a function that shows the remainder after a / on big numbers (//) so with some mucking around I can still get full 16bit resolution on divides.

The simplest way is to scale with eg ^2 to distort the curve to increase the area, but I cant do that.

If I split the curve into 3, then I can linearly scale the 2 ends differently and just connect the middle with a straight line with simple +-*/ math.

Im not big on math generally, this part of the project has been a challenge for me, I cant even describle properly what Im doing, but in a simple way it works in the end.

[Danack (Dan Ackroyd)]

"Im thinking a simple non linear offset to the vertical scale would be the go, but I just cant find it testing in excel," - So it's okay to just suggest things that will allow a new table to be generated in excel?


I think you just need the two functions bias and gamma below to tweak your curve...

function smoothCurve( float x){

return 1/(1+EXP(-x))

//I prefer this as a smooth curve:
//return t * t * (3.0f - 2.0f * t);
}


function bias(float value, float bias){
return Math.pow(value, Math.log(bias) / Math.log(0.5));
}

function gamma(float value, float gamma){
return Math.pow(value, gamma);
}


float gammaValue = 2.2;
float biasValue = 0.75;


for(x=0; x<=255; x++){
float value = x / 255.0f;
value = smoothCurve(value);
value = bias(value, biasValue);
value = gamma(value, gammaValue);

//store value in your table.
}



The bias function makes the curve more 'steep' or less 'steep'.
The gamma function keeps it closer to the x-axis or further away.

An integer PIC cant do any of the functions you describe to recalculate the curve live.

*raises single eyebrow*

Is that....a challenge?

[alistairsam]

Hi,

wasnt too sure what to make of this thread, but intriguing to say the least.
are you trying to generate a speed ramp for stepper motors for acceleration and deceleration?
are you using the pic or the picaxe?
not sure if this is relevant, but i've written some crude code for the picaxe to accelerate and decelerate steppers based on pwm.
link here, post #56
http://www.picaxeforum.co.uk/showthr...eration&page=6
not very elegant, but does the job.
could you give some details on what you're trying to do, apart from going back in time!!
it'd be interesting to see how you generate the accel or decel profile in realtime as the pic's and picaxe's have finite execution overheads that throws the timing a bit off.

again, not sure if relevant, but i found this to be a very interesting article on the subject of accelerating steppers
http://fab.cba.mit.edu/classes/MIT/9...i0/doc8017.pdf
the math can be adapted for mcu's that can only do 16 bit integer math.

[alistairsam]

hi,

have a look at 2:12 from this video, the example with a martini glass i presume. shows what the deceleration profile needs to be like. http://www.youtube.com/watch?v=2pbYb5HNJ2M

generally, profiles are trapezoidal, but as you say, the sigmoid curve would result in very smooth transitions, much like the glass example above.
the vibration dampening actually softens the lowest segment of the curve to avoid abrupt stops.

you mentioned you solved the issue by breaking the curve into three segments. what function did you use to generate values for the curved segments.

thanks

[Bassnut (Fred)]

Rally, here is the lookup table. (Manually jigged a bit at the ends)
(64950,64850,64700,64650,64563,6454 5,64526,64507,64487,64466,64444,644 21,64397,64372,64347,64320,64292,64 263,64233,64201,64169,64135,64099,6 4063,64024,63984,63943,63900,63855, 63809,63760,63710,63658,63603,63546 ,63488,63426,63363,63297,63228,6315 7,63083,63006,62926,62842,62756,626 66,62573,62477,62376,62272,62164,62 052,61935,61814,61689,61559,61424,6 1284,61140,60989,60834,60673,60506, 60333,60153,59968,59776,59578,59372 ,59160,58941,58714,58479,58237,5798 7,57729,57462,57187,56904,56611,563 10,55999,55680,55351,55012,54664,54 306,53938,53560,53172,52774,52366,5 1947,51518,51079,50629,50169,49699, 49219,48728,48228,47717,47197,46667 ,46128,45579,45021,44455,43880,4329 6,42705,42106,41500,40887,40268,396 43,39012,38376,37735,37090,36441,35 789,35134,34478,33819,33160,32500,3 1839,31180,30521,29865,29210,28558, 27909,27264,26623,25987,25356,24731 ,24112,23499,22893,22294,21703,2111 9,20544,19978,19420,18871,18332,178 02,17282,16771,16271,15780,15300,14 830,14370,13920,13481,13052,12633,1 2225,11827,11439,11061,10693,10335, 9987,9648,9319,9000,8689,8388,8095, 7812,7537,7270,7012,6762,6520,6285, 6058,5839,5627,5421,5223,5031,4846, 4666,4493,4326,4165,4010,3859,3715, 3575,3440,3310,3185,3064,2947,2835, 2727,2623,2522,2426,2333,2243,2157, 2073,1993,1916,1842,1771,1702,1636, 1573,1511,1453,1396,1341,1289,1239, 1190,1144,1099,1056,1015,975,936,90 0,864,830,798,766,736,707,679,652,6 27,602,578,555,533,512,492,473,454, 436,300,250,200,150,100)

Alistair,Dan

Im useing the PICAXE Basic, not C. Cringe worthy, but for very good reasons, it was much easier and faster to code than C. The built in LCD and other hardware drivers are simple one word commands that would have taken huge effort to code in C. But there are other limitations of course.

I already have speed and accel/decel well sorted, its just the sigmoid curve manipulation left to do. BTW the PWM command in PICAXE is far too fast for half stepping , so I used pausesus and pulseout, works a treat.

Excecution overhead is not a problem, because this is all for a timelapse controller pause-move-pause action. ie the total distance travelled is divided by the number of exposures (pauses) into "slices" of motor movement, each calculated on the fly to give the illusion of smooth motion in the final sped-up video production.

So, this motion control and its accell/decell is done and not an issue, its the overall "change distance over a given time and at a given start speed to zero, smoothly" that is the problem. The sigmoid look up table already works well and is easy to use if speed and time are the only input values.

At the start of this, I couldnt even find a way of scaleing in exel, just to see what might be required to change the area under the graph, the answers in the thread fixed that, but leaves me with math I cant use in the picaxe, so it became obvious (short of mutiple lookup tables and extrapolating between them, which is still an option) that I need to manipulate the curve in other ways.

Splitting the curve into 3 doesnt look too good now as its hard to make the transition from the 2 end curves to the straight line smooth after scaling so ive thought of a few other ways.

Although I didnt want to touch the low res time axis, its seems that modifing it might be the easiest way, simply sliding it sideways, or adding time "slots" to the beginning and/or end. Or multiple table read outs of the tails in a 1,1,1,2,2,3,4,5....... 252,253,253,254,254,254 fashion to distort the curve ends without lowering resolution. Some testing showed large changes in area this way.

Dan, I cant use functions such as float, log and exp in picaxe basic (the log function is very low res), but yes, theres a challenge, scale the curve using only integer +-*/ .

Im sorry if this has become a bit scatterbrain and seemingly impossible with all the inane restrictions, I do appreaciate the effort that has been put into replies, they have helped me understand the process with testing in excel.

Im convinced now that curve modification can be done, but by sort of "physical manipulation" rather than directly by math scaling.

[alistairsam]

Hi,

have you had a look at the trinamic IC's?
they generate S shaped or linear ramps on the fly, can be interfaced to the picaxe. just send distance, speed, accel values and it calculates and generates the ramp.
this removes most of the complex math processing requirements,
http://www.trinamic.com/tmc/render.php?sess_pid=444
http://www.trinamic.com/tmc/render.php?sess_pid=480
i think element14 have started stocking these chips.

but if you have it working with just the picaxe, thats even better. i love the picaxe's, so simple and versatile.

what expression did you use to generate your lookup table values?
wouldnt the start and end values for the next move vary based on elapsed time and distance?

[Bassnut (Fred)]

I used 1/(1+EXP(-x)) to generate the curve in excel, although others are possible.

Those Trinamic ICs look very interesting, hadnt seen them, but you see each move "slot" between pauses has its own seperate accel/constant/decell speed/distance routine (easy to do), with the overall step speed/distance calcs generating each slot values, so a dedicated continous motion IC would not be suitable, or at least just as difficult to control as the picaxe code. It would need constant parameters fed to it which need pre calculating anyway. I dont think just constantly pauseing a step speed profile it self generates would work.

Yes, the start/end curve speeds depend on the previous/next steps elapsed time and distance. Thats done (each step has seperate inputs). They are calculated automaticaly on just time/distance input. Speeds are a non inputed result.

The single exception is ramp to zero where there are 3 inputs, time, distance and end speed, hence the need to distort the curve for a non linear speed profile. Its even possible to need to go faster than the start speed during the ramp to zero profile, to cover a long distance with a low start speed. I havent started to tackle that, might be too hard.

[alistairsam]

i found a qbasic program to generate a sigmoid curve here. will be interesting to see if the math can be modified to use functions available in picaxe's basic interpreter.

http://users.computerweekly.net/robm...al/sigmoid.htm

I saw your timelapse videos and noticed the camera panning right and up, continues right, and then right and down.
are you trying to generate this curve to generate x,y positions for your camera head?
are you trying to move your camera to follow an s curve in the timelapse video?

how did you manage accel and decel?

you got me thinking of how i can use the picaxe to generate values that follow a curve for generating ramps. in my case, the speed is quite high, so pauseus is too slow, lookup tables are also slow, so i have to calculate pwm values.

[Bassnut (Fred)]

Interesting link, some of the integer manipulations are handy but I cant see much there the picaxe could handle overall. Again, I have the table sorted and tested so im not keen to revisit the curve generation.

My videos were pretty rough, but the machine then only had linear ramps. Phil Hart also has a machine and uses it to much better effect.

Yes, the controller is 2 axis, it controls an EQ mount, although Phil and I also have trolly systems for different movement effects. The S curve is a recent addition. In short, yes, the mounted camera will follow an S curve in timelapse videos.

Accel/decel code is a simple for-next loop controlling the delay between pulses. b2 is start/end speed. You can use a variable for the step size to alter the accel/decel rate. Pauseus (instead of pause) would be faster of course.

;Accelleration (simplified)

for b0=b2 to 0 step-1
pulsout B.6,4
pause b0
next b0

;Decelleration

for b0=0 to b2 step 1
pulsout B.6,4
pause b0
next b0

Look up table use is even easier.(simplified, no scaling)

For b0=0 to 255
lookup b0,(65000...............0), B1
pulsout B.6,4
pauseus b1
next b0

(or 65000-b1 for decel)

Useing PWM command you would alter period in the loop with the stepped variable, but thats not that simple because to get a wide speed range the command uses counter scalers, so you would need several loops with different scalers, or nested loops with more variables.

Linear ramps are easy with for-next loops, and lookups arnt hard either for curve following.

If you want top speed, I would have thought the "table" command (different to "lookup") would be the go, ie direct memory addressing.

BTW, the 28*2 (and others) is now 64mhz, they are so fast calcs on the fly have nowhere near the overhead they used to, specially for stepper control.

[alistairsam]

hi,

I realize you won't need to regenerate your curve, I provided the links for reference.
your sigmoid problem has indirectly given me a few good ideas.

I need to get pulses at upto 25khz, so even at 64mhz, pauseus doesnt help, i'll look at dma again.
curve accuracy would depend on how instantaneous speed is measured.

thanks