Back
[00:00:00] <z64555> not necassarily. the point of motion profiles is to get to your desired position as fast as possible
[00:00:24] <MarkX> but then i have no need for the pot, unless some calibration is required
[00:00:35] <z64555> no no, you still need the pot
[00:00:57] <MarkX> to get my start pos
[00:01:04] <z64555> to get your actual position
[00:01:23] <MarkX> hmm this still feels wrong
[00:01:23] <z64555> that is your only method of feedback. without it, you don't have an open system
[00:01:46] <MarkX> i was hoping for more polling actual position
[00:01:49] <MarkX> and adjusting as needed
[00:01:53] <MarkX> i guess that's more PID then
[00:02:22] <z64555> eh, kinda
[00:03:16] <z64555> well, yeah, precisely
[00:03:35] <z64555> the trapzoid profile in this case would be used to tune your PID to closely match the profile
[00:03:57] <MarkX> hmmm
[00:04:01] <MarkX> back to the PID then i guess
[00:04:06] <MarkX> luckily i didn't delete the code
[00:55:16] <rue_house> done your trapazoid profiler yet?
[00:56:09] <MarkX> rue_house: god no
[00:56:28] <MarkX> i'm seriously doubting myself right now but i think i have a plan
[00:57:34] <MarkX> originally i wanted to say "moveTo(motorNumber, goalPos)", i thought PID might be the answer for that but i stopped at the tuning phase when someone introduced me to motion profiles.
[00:58:28] <MarkX> the problem with the motion profile is, it's not really closed loop. you give it the startpos from the pot and let the physics work out the rest
[01:00:04] <MarkX> i just found a good write up though on how someone took a profile generator and basically fed its generated position desired into a PID control setup
[01:00:36] <rue_house> maybe I will beat you on the profiler
[01:00:39] <MarkX> which is a closed loop set up because it actually looks at its current position
[01:00:47] <rue_house> you been at it, like 3 weeks now?
[01:00:53] <MarkX> very likely. i'm very new at this
[01:01:01] <MarkX> ya about that
[01:01:31] <rue_house> my system is arbitrary time, you specify what the temporal step is and it tells you the position
[01:01:44] <rue_house> you can go forward or back at whatever resolution you want
[01:01:57] <rue_house> when I'm done I need to reverse it for my system
[01:02:03] <MarkX> see i don't even know what you mean by "temporal step"
[01:02:09] <rue_house> I need to know how much time between fixed distance steps
[01:02:18] <rue_house> time increment
[01:09:41] <MarkX> i see
[02:28:06] <rue_house> MarkX, :P did it!
[02:30:32] <rue_house> http://ruemohr.org/~ircjunk/images/haha-markx.svg
[02:30:59] <MarkX> LMAO
[02:31:06] <MarkX> congrats rue_house :)
[02:31:10] <rue_house> zippo:/files/programming/c/TrapazoidProf# gcc -lm main.c ; ./a.out
[02:31:11] <rue_house> start is 0, end is 36
[02:31:11] <rue_house> Amax is 3, Vmax is 6
[02:31:11] <rue_house> half the run is 18.000000
[02:31:11] <rue_house> Peak velocity is 6.000000
[02:31:11] <rue_house> acceleration time is (t1) 2.000000
[02:31:13] <rue_house> during acceleration, travel is 6.000000
[02:31:17] <rue_house> jogging distance is 24.000000
[02:31:19] <rue_house> jog time is 4.000000
[02:31:21] <rue_house> jog end time is (t2) 6.000000
[02:31:23] <rue_house> dt = 0.000000 ,0.000000, 0.000000
[02:31:25] <rue_house> dt = 0.125000 ,0.125000, 0.023438
[02:31:27] <rue_house> dt = 0.250000 ,0.250000, 0.093750
[02:31:29] <rue_house> .
[02:31:32] <rue_house> .
[02:31:34] <rue_house> .
[02:31:45] <rue_house> tStep = 0.125;
[02:31:45] <rue_house> accel = 3;
[02:31:45] <rue_house> velMax = 6;
[02:31:45] <rue_house>
[02:31:46] <rue_house> start = 0;
[02:31:48] <rue_house> target = 36;
[02:33:44] <rue_house> MarkX, ...
[02:33:53] <rue_house> for what its worth
[02:34:26] <rue_house> http://paste.debian.net/412663/
[02:35:13] <rue_house> your close, your mistake was that you forgot to make the accel - at the tail,
[02:35:30] <rue_house> and I dont know if you added the V0*t to the decel calc
[02:36:20] <MarkX> that accel was where i was having the most trouble yes
[02:36:22] <rue_house> its not optimized or broken into libraryness
[02:36:29] <MarkX> i should just do this on paper rather than googling
[02:36:39] <MarkX> i have my velocity, i have all my positions
[02:36:52] <rue_house> I based it all on time
[02:37:13] <rue_house> tStep controlls the resolution of the time steps
[02:37:48] <rue_house> if its a short move, it cant hit velMax, so it dosn't
[02:38:03] <rue_house> and it would skip the jog area
[02:39:16] <rue_house> oh, #define Min(X,Y) ((X) < (Y) ? (X) : (Y))
[02:39:32] <rue_house> thats the rouge include line of importance
[02:39:51] <rue_house> ABS(a) ((a) < 0 ? -(a) : (a))
[02:39:54] <rue_house> I used that too
[02:39:59] <rue_house> #define ABS(a) ((a) < 0 ? -(a) : (a))
[02:41:18] <rue_house> oops, I changed code, the printf %d should now be %f
[02:42:22] <z64555> soo. problem
[02:42:42] <z64555> what happens if the desired theta changes while all this happens
[02:42:53] <rue_house> ?
[02:43:19] <rue_house> its a trapazoidal velocity profile
[02:43:35] <rue_house> if you want to sync axies, its done at a different level
[02:43:58] <rue_house> you take the axis that has to travel the farthest, make it the master axis, and slave everyone to it
[02:45:46] <rue_house> gnight corry :)
[02:46:51] <rue_house> wow, the triangular velocity profile is so smooth you cant tell
[02:47:30] <z64555> :)
[02:49:50] <deshipu> Monday...
[02:50:24] <z64555> oh that reminds me, I need to fill the coffe maker
[02:52:06] <rue_house> wolfram alpha fails AGAAIN to take a whole pile of ugly algebra and reduce it for me
[02:52:19] <deshipu> no way
[02:52:35] <rue_house> what good are computers if I have to do all this work myself?
[02:52:45] <rue_house> x = (accel * t1 * t1)/2;
[02:52:45] <rue_house> printf("during acceleration, travel is %f\n", x);
[02:52:45] <rue_house>
[02:52:45] <rue_house> // how much distance do we have a constant velocity?
[02:52:45] <rue_house> jogd = (target-start) - (2*x);
[02:52:45] <deshipu> you don't have to
[02:52:46] <rue_house> jogt = jogd / vTop;
[02:52:47] <rue_house> t2 = t1 + jogt;
[02:52:48] <z64555> try the TI-89
[02:52:52] <rue_house> reduce to 1 line, t2=
[02:52:52] <deshipu> use a pastebin
[02:53:09] <rue_house> no, I dont ahve to use a pastebin
[02:54:13] <deshipu> right, you could also not paste any code at all
[02:54:40] <z64555> ...i have a bad feeling about your equations
[02:55:26] <z64555> oh so that's how its gonna be
[02:55:32] <rue_house> I ahve a hat that says its ok to paste in channel if nobody is talking
[02:55:38] <rue_house> so :P
[02:55:55] <deshipu> rue_house: who died and made you an op?
[02:56:08] <z64555> kinda childish, just saying
[02:56:15] <rue_house> hell yea
[02:56:31] <rue_house> you know this was wildmage's channel
[02:56:46] <deshipu> I didn't know you can own a freenode channel
[02:56:52] <rue_house> he handed it to us (tom)
[02:57:04] <rue_house> I am master of #avr
[02:57:06] <rue_house> :P
[02:57:12] <rue_house> ask chanserv
[02:57:20] <MarkX> heh
[02:57:22] <deshipu> I wonder how many complaints to staff would it take to change the ops :P
[02:57:42] <rue_house> apparently they dont do that... we'd tried in other channels
[02:57:56] <rue_house> I dont hang out in #electronics anymore
[02:58:09] <rue_house> used to be the main channel
[02:58:42] <deshipu> I hear you, we had that with #pygame
[02:58:49] <deshipu> but finally the trolls died off
[02:59:03] * rue_house glares at flyback
[02:59:06] <deshipu> in the mean time pygame died off too, though
[02:59:32] <rue_house> t2 = t1 + ((target-start) - (2 * (accel * t1 * t1)/2 ))/ vTop;
[03:01:46] <rue_house> I think they dumbed down wolfram alphas math abilities
[03:02:10] <deshipu> oh, Them
[03:02:21] <z64555> hey...
[03:02:26] <z64555> http://www.compumotor.com/whitepages/ServoFundamentals.pdf
[03:02:32] <z64555> This might be of some use, MarkX
[03:02:40] <z64555> and that rue_house guy, too
[03:03:03] <MarkX> thanks z64555 saved
[03:03:34] <z64555> it introduces a PIV controller, the latter being velocity
[03:03:34] <rue_house> no, the math is easy, implementing it on an 8 bit platform is tough, the numbers saturate easily and make it a nightmare
[03:03:54] <rue_house> getting around the saturations is a mess
[03:04:48] <rue_house> on my hexapod I stopped at PD
[03:04:59] <z64555> wha...
[03:05:02] <rue_house> nomatter what I did, I made it unstable
[03:05:13] <z64555> well, Yeah. that's what a PD tends to do
[03:05:37] <z64555> need at least a PI
[03:05:49] <rue_house> as PD its stable
[03:06:13] <z64555> stable as in oscilating?
[03:06:17] <z64555> yeah.
[03:06:29] <rue_house> no, stable as in underdamped motion
[03:06:53] <z64555> huh. interesting
[03:07:11] <MarkX> alright bed time
[03:07:20] <MarkX> thanks again for all the help guys
[03:07:30] <rue_house> remember, use the farce
[03:08:02] <MarkX> i'm currently trying to avoid your code as much as possible
[03:08:17] <rue_house> I didn't write it for you
[03:08:19] <MarkX> tomorrow i'm going to get a pen and paper and do the math myself
[03:08:26] <rue_house> I wrote it to prove it can be done in less than 3 weeks
[03:08:27] <MarkX> oh i know, i just mean even as a reference
[03:08:37] <rue_house> and to build a base for the code _I_ need later
[03:08:41] <z64555> lol
[03:08:42] <MarkX> lol!
[03:08:45] <MarkX> cruel
[03:08:48] <rue_house> :P
[03:09:02] <MarkX> in my defence, generally i have no idea what i'm doing :P
[03:09:15] <rue_house> it took me a day, thats BAD
[03:09:32] <MarkX> what did you read to make it?
[03:09:42] <rue_house> my mind
[03:09:52] <MarkX> heh
[03:09:55] <rue_house> and I got the formula wrong for x when accelerating
[03:10:00] <rue_house> so #math
[03:10:05] <MarkX> i see
[03:10:19] <rue_house> they pointed me to the wrong formula, but I figured it out
[03:10:45] <rue_house> X = V0 + 1/2*a*t^2 dosn't work units-wise
[03:11:24] <rue_house> and v0 is 0 at start, so that can be dropped till your de=-accelerating
[03:11:38] <rue_house> your code is close, if you make the accel - when your stopping it might work
[03:11:56] <rue_house> I cant tell if you have 1 or 2 errors
[03:12:05] * z64555 studies the PIV controller
[03:12:31] <MarkX> let me try it now
[03:14:16] <MarkX> i think there are 2 errors
[03:14:45] <rue_house> then you forgot the v0*t
[03:14:57] <rue_house> v0 is the velocity when you started the decel
[03:15:53] <MarkX> so basically the vmax
[03:16:05] <MarkX> because the velocity when decel is started is vmax
[03:16:06] <rue_house> if your trapazoid
[03:16:28] <rue_house> if your motion was too short, you cant hit the vmax
[03:16:37] <rue_house> and you get a triangle velocity profile
[03:16:48] <MarkX> yes but in my test excel i've made sure i have vmax
[03:16:51] <MarkX> in this case for 41ms
[03:16:56] <rue_house> ;
[03:16:58] <rue_house> k
[03:17:48] <MarkX> most of the moves in my case will be triangular anyways
[03:18:06] <rue_house> ok, well my code works everything out in 3 lines, so, good enough for the night
[03:18:40] <rue_house> vTop = Min(sqrt(accel * ((target - start) / 2.0)), velMax);
[03:18:40] <rue_house> t1 = vTop / accel;
[03:18:41] <rue_house> t2 = t1 + ((target - start) - (accel * t1 * t1))/ vTop;
[03:27:45] <MarkX> your method of calculating X is different from mine
[03:27:47] <MarkX> very different
[03:27:49] <MarkX> screw it
[03:27:53] <MarkX> i'll do it all on paper tomorrow
[03:28:16] <Jak_o_Shadows> yo
[03:28:24] <MarkX> evening
[03:34:15] <z64555> PIV is... interesting. in effect all the gains, integrations, and derivations are done on the output position
[03:34:41] <z64555> whereas with the PID it does some calculations on the input position as well
[03:36:58] <Jak_o_Shadows> PIV? Proportional, integral, velcoity?
[03:38:08] <z64555> yes, it's an oddity whose only mention is on a whitepaper by Parker
[03:38:13] <z64555> http://www.compumotor.com/whitepages/ServoFundamentals.pdf
[03:38:19] <z64555> *public mention
[03:39:07] <z64555> http://robotics.stackexchange.com/questions/1032/how-is-piv-control-performed
[03:39:19] <z64555> There's a good (albeit small) discussion on it
[03:41:03] <Jak_o_Shadows> Wait, so you have two variable things now that you're applying gains to?
[03:41:08] <Jak_o_Shadows> Veloctiy and osition?
[03:41:49] <z64555> velocity is a function of position, so actually just the one thing
[03:42:10] <z64555> presumably, this is operating as a velocity controller rather than a pure position controller
[03:43:08] <Jak_o_Shadows> well, yeah, but you're appying the gains to different variables?
[03:43:16] <Jak_o_Shadows> Sure, the variables are related - that's not my point
[03:43:45] <z64555> Kp's applied to e_x, Ki and Kv are applied to "v"
[03:43:51] <MarkX> UGH
[03:43:58] <MarkX> i think i found the problem
[03:44:20] <MarkX> in excel (A119 - $F$3 + $F$5) != (A119 - ($F$3+$F$5))
[03:44:24] <Jak_o_Shadows> yeah
[03:44:33] <MarkX> it does not take the value inside that cell, it takes the equation
[03:44:57] <MarkX> so if there was multiplication/division stuff in there, it would give 2 totally different results
[03:44:58] <MarkX> >_>
[03:45:47] <z64555> a PIV's transfer function is {x_in - (1 + (K_v * s^2 + K_i * s) / (K_i * K_p) ) x_out
[03:45:51] <z64555> }
[03:47:03] <z64555> vs. a PID's (x_in - x_out)(K_p + (K_i / s) + (K_d * s))
[03:48:54] <Jak_o_Shadows> Yeah. TBH, I'm not up to working through the maths at the moment.
[03:48:57] <Jak_o_Shadows> Too buggered
[03:50:01] <z64555> Ah, then it probably makes more sense to you than I at the moment :P
[03:52:07] <Jak_o_Shadows> Oh yeah, I have the basic theory, and I can follow along the maths.
[03:52:13] <Jak_o_Shadows> Like, totally up with lapalce transforms
[03:59:28] <z64555> the one thing I find kinda sketchy is where it subtracts velocity from the error signal
[04:02:38] <Jak_o_Shadows> units wise, how does that work you mean?
[04:03:22] <z64555> well, they call the sum as velocity error, but that's not the case
[04:03:47] <z64555> It may seem like that in discrete time implementation, but you have to remember that velocity has a "per second" factor on it
[04:04:15] <z64555> everything else seems to check out
[04:05:39] <Jak_o_Shadows> TBH, I'm not entirely sure what effect the laplace transform has on units
[04:05:45] <Jak_o_Shadows> sure, it goes into the frequency domain, but so what?
[04:06:24] <z64555> Laplace transforms are usually on time, so anything wrt time gets converted into some factor of s
[04:06:49] <z64555> postion, x, velocity x*s, acceleration, x*s^2
[04:07:12] <Jak_o_Shadows> yeah, makes sense.
[04:16:29] <z64555> I need to break out my control systems handbook soonish
[04:33:03] <z64555> DagoRed: any luck on finding what the R matrix should look like?
[06:38:19] <z64555> DagoRed: I've deduced that it is, indeed, a diagonal matrix. Reading up on covariance matrices supports this as it states element i_jk is the covariance between the left vector's element j with the right vector's element k
[06:38:22] <z64555> if that makes any sense
[06:39:23] <z64555> Since R is the measurement covariance of sensors, who presumably do not affect each other's reading in any way
[06:40:04] <z64555> it stands to reason that R is a diagnoal matrix with a variance per sensor along that diagonal
[06:40:27] * z64555 hopes he's right
[07:02:54] <veverak> aaand todo for this day:
[07:03:01] <veverak> find shortest path to export kicad into scad
[07:03:08] <veverak> meaning: shape of board + passtrough holes
[07:26:05] <jhylands> veverak, here'
[07:26:36] <jhylands> here's a hint - use Gerbv
[07:26:48] <jhylands> not the one that comes with Kicad - you need to install it separately
[07:27:08] <jhylands> http://gerbv.geda-project.org/
[09:26:45] <rue_house> MarkX, rrllly? you did that in excel?
[09:26:49] <rue_house> why?
[09:26:53] <rue_house> how does that help
[12:21:56] <veverak> fuuuuu
[12:22:02] * veverak doesn't like debian this time
[12:22:14] <veverak> jessie package of libpython2.7 doesn't have /usr/lib/libpython2.7.so anymore
[12:22:19] <veverak> which sucks because ros package needs it
[12:23:01] <deshipu> what does it have?
[12:23:20] <veverak> ehmm, nothing
[12:23:22] <veverak> it's moved
[12:23:31] <veverak> /usr/lib/arm-linux-gnueabihf/libpython2.7.so.1
[12:23:46] <veverak> will ask on #raspbian, don't want to make manual links
[12:23:54] <deshipu> just make a symlink
[12:24:02] <deshipu> or set LD_LIBRARY_PATH
[12:29:06] <veverak> !!!
[12:29:13] <veverak> i don't need that package from ROS for now anyway
[12:29:16] <veverak> better get rid of it
[12:49:35] <veverak> http://veverak.org/~squirrel/laptop/scad/beta2.png
[12:49:40] <veverak> on the left: source shape
[12:49:55] <veverak> on the right: after kicad mods
[12:49:57] <veverak> :)
[14:07:28] <rue_house> antoher walker?
[14:07:34] <rue_house> I thought the world was over them
[14:45:54] <z64555> s/over/taken over by
[14:50:57] <z64555> oy vey. now that I've figured out what the R matrix is, now I need to figure out how push quaternions through a kalman filter
[14:51:20] <veverak> z64555: use tractor
[14:51:44] <z64555> oh, so you want me to pull them through? ok
[14:52:06] * z64555 heads outside to borrow his neighbor's tractor
[14:53:27] <veverak> :)
[14:54:32] <z64555> yeah, I have no idea what you mean by that, and naturally the only thing google pulls up is farm equipment or some sort of DJ mixing software
[14:54:56] <z64555> :)
[14:55:38] * veverak ment the tractor part literally
[14:55:59] <z64555> orly
[14:58:56] <z64555> well, what I could do is treat the quaternion as a unit Vector3, assuming the real element is 0
[14:59:19] <z64555> And have the kalman filter operate on each of the elements in the vector
[15:01:39] <z64555> and once it passes through the filter, convert it into a proper quaternion
[15:06:10] <z64555> next would be to figure out how to vary the covariance for the axes when at certain angles
[15:16:54] <z64555> I think
[15:17:11] <z64555> what I should do for now is just focus on the accelo and gyro before expanding into the compass
[15:17:34] * z64555 isn't sure how to word that sentance
[15:24:46] <MarkX> rue_house: i wanted to understand the math behind the profile
[15:42:20] * veverak needs to clean project folter and git commit
[15:42:22] <veverak> nah
[16:28:51] <z64555> hm, another plus to using quaternions vs. Euler angles is that you don't have to worry about the angle overlowing
[16:30:33] <z64555> although this finding doesn't really help me at the moment
[16:45:56] <SpeedEvil> :)
[17:05:09] <z64555> what would be neat is if I could grab sensor data over USB and display it on the PC
[21:21:00] <rue_house> MarkX, did you get it yet?
[21:22:03] <MarkX> rue_house: get what?
[21:22:36] <rue_house> ITS BEN 3 WEEKS, DID YOU GET IT WORKING!?
[21:22:56] <MarkX> YES
[21:22:56] <MarkX> lmao
[21:23:03] <MarkX> after your final equation yes i did
[21:25:52] <MarkX> but now i'm gonna improve the PID, tune it, then feed the position determined from the profile into the PID
[21:27:18] <MarkX> on the plus side
[21:27:21] <MarkX> i understand the math though
[21:27:32] <MarkX> and coincidentally how the S-Curve works
[22:06:00] <anonnumberanon> z64555, Well that's a fun project to be doing so that won't be a pain in the butt at least.
[23:39:59] <rue_house> MarkX,
[23:40:17] <rue_house> float offset, t, tStep;
[23:40:18] <rue_house> trapMotion_t motion;
[23:40:18] <rue_house>
[23:40:18] <rue_house> tStep = 0.25;
[23:40:18] <rue_house> InitMotion(&motion, 1, 37, 3, 6);
[23:40:19] <rue_house>
[23:40:21] <rue_house> for (t = 0; (ABS(offset-37) > 0.01); t += tStep) { // this is to prevent lockups from differences ~= 1/infinity
[23:40:24] <rue_house> getPos(&motion, &offset, t);
[23:40:26] <rue_house> printf("%f, %f \n", t, offset );
[23:40:28] <rue_house> }
[23:41:18] <rue_house> its a library now
[23:41:26] <rue_house> or, close enough
[23:42:38] <rue_house> my axis interpolator outputs postions tho, so I need to invert this to work out the delays between pre-determined positions
[23:45:47] <rue_house> heh, I thought the editor said that was 1500 lines, it says 1500 bytes
[23:52:14] <rue_house> how can I best code while I'm asleep?
[23:57:25] <MarkX> heh
