4/13: Started project with plotter. We discussed what to do with the plotter-- high and low level functions and control mechansims. Took notes, set up program template and typed records-- and looked over the machine itself Machine-- two motors-- old mechanism for pen lifting-- sensors are rotary. What to do: readpt function-- read a point on graph relative to (0,0) (this is accomplished by finding what (0,0) is on the sensors and then converting it to what points we want. find how far motors can go-- their limits and make sure that it isn't overshot-- enter in motor program. (if past coordinates set point to be at edge of page? However, problems like graphing stuff off the page could be a problem...) Also-- turning on and off motors. Motor function-- readpt and send appropriate motor to point realative to 0,0 and stay there-- in 1 d each direction and also in 2 d. ?'s how to get it to go from pt to pt. idea: define as zero one coordiane-- could have problems though if not always centered. As for control-- ideas: friction? critical damping to imitate friction? lifting pen (pistions? other mechanisms?) distance function to slow motors? shut off motors? acceleration issues? Higher level: pictures-- geometric figures, (we want straight line function anv also arcs-- how to do each using control and possibly an umbrealla function to integrate it to a user friendly program) ( for that-- idea of stop points-- get it to read repeatedly before moving on-- vs curves-- read and move continiusly) convertible axes? instead of 1-100--> 300- 495? Other: need to document work-- record daily? keep tests/mistakes and how overcame them for future posterity. :) And lastly-- "Max wrecked the plotter"-- eric-- the strings are now weird but hey, I can write code anyways! Mere plotters cannot stop me! parenthetical mwh ha ha ha! So we are presently trying to hook it back up-- the inner workings of this beast we shall tame! ------------------------------------------------------------------------ 4/15: activities: writing up trial code, discussed stoppt and also readpt and control for the motor-- using speed/distance etc. Found upper and lower limits for x and y with sensors. new idears:to make arc? (I'm not sure what this will produce but...) run two seperate distance functions for each point. Also, straight lines? Should have function give off points along the line? developments: calculation of distance--> motor speed-- continuous function vs. ones that halve motor as 1/2 way there/ piecewise. testing to see which method works best. plus, motors quit of run too slow. function ideas: int x want, calculate distance, run motor according to some function of distance, whether that be distance alone or the percentage of distance travelled. Notes on plotter set up-- loop at bottom (-y) x runs backwards (must adjust for this) 3 prong motor is y axis and appropriate sensor is attached. Designate both upper and lower limits in program (so motor doesn't think it's farther than it is) and greater than / less than for which way to run the motor. -------------------------------------------------------------------------- 4/22: activities: writing more code, discussed/altered/ tested code on plotter and gathered data. new idears?: try different control methods. Find pen and way of affixing it (? clicker pen?) problems: pen's added friction's effect? eliminating overshoot (seems to oveshoot no matter what speed run it at...) programming: first, direct function of distance to speed. not acurate and didn't adjust for error, but did move fast. (error of 30-37 units away from destination.) So, broke up program into two parts-- run at speed d-s until d away (but this only worked right for one side. The motor kept running-- d-s could be a small negative or positive number. So although acurrate, the motor would run indefinitly.) Next tactic was to stop it at d-s away and run at d, however this only worked for one side, so changed code to deal with approcing destination from both sides (d<-s and d>s) This worked surprisingly well but isn't reliable-- it depends too much on how the coaster tends to decelerate with no friction. With a pen it could behave much differently. Next tactic was to use parameters to change and find out what worked. These worked darn well. Also added second "bubble" for the motor to run at a minimum speed (to help it decelerate) The motor behaved funny from one side, went to point then moved away. (this was due to a sign error-- once again only accounted for one side of the bubble) Experimented with various min speeds and bubble sizes-- overall conclusion-- large outer/ inner bubble from far away-- but need inner bubble when close--> try different control method, this one is too dependant on deceleration due to minimun friction. Also, couldn't hit spot exactly (ever) ______________________________________________________________________________ 4/27: activities: did more messing around with programs. gotox acted funny (this was later found to be due to the wrong negatives on the motors. Added safelim to prevent the motor from running into the side and also tested to see what size each bubble should be to minimize problems. More side notes: safe lim's: 3 pts in from one end- ist pt on other (as measured by center bar) also!! now motor may not run if too close to edges bizarre behavior-- sent it one way-- couldn't decide-- went back and forth. set "bubbles"= to 0 and nearly stopped, and continued on. This was caused by motor problems-- it diverged instead of converged-- negatives were in the wrong spots pos--> <-- neg x motor plugs in right on 0 motor slot only. tests: (x,s,p,a) (-- 0,0--)--> didn't stop--"while" never untrue. (50,10,5,20)-- great for small distance (error<~1) and fine from far away on rt but left way a tad iffy. (error ~9) To check error (and to keep myself honest) I added to the gotox program a return st the error is returned. Below is a chart recording this (a=20) (p const=5) s=10 s=20 s=40 (s const=20) p=5 p=10 p=20 left close -4 -3 -3 -3 5(-8) 6(-19) left far -3 -2 -1 1 (-3) 3(-8) 12(-18) rt close 3 3 3 2 (4) 6(8) 12(13) rt far 1 2 -4 0 (3) 2(7) 7(17) (these mean 75->50->200->50->75) (discrepancy(actual vs(reading) probably due to reading as still moving, will add sleep 1s) Looks like( from data) that s doesn't matter, but p=5 is the best. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Makeup for 4/29: activities: gotox looks good, so I'm copying it (for gotoy) and also setting s and p to 20 and 5 respectivly. Hmmm gotox looks like it isn't working, so I'm renaming it coastx() and writing a new gotox program. So, for this, I'm comparing d old to current d to see whether or not it will oscillate and stop. At first, this worked, but for farther distances it isn't working too well. Also, if I send this one to 200, then it coasts to the safe lim zone and stops. ** gotta be careful of this!** Ugh, so tried other stuff--- got it to oscillate but now it won't stop. Added printf to see where in look it has problems... but still oscillates. (even with min value-- need some mechanism to get it out of the loop.) Hmmm... well I tried adding a counter but now it won't oscillate! ______________________________________________________________________________ 4/30: move and stop-- the program would quit preamaturely. This was due to a couple little errors in the code. The major one we changed was forcing it to oscillate more by increasing the times it had to pass zero distance. also much better on one side--> due to friction (right side a bit slicker) Also, possible shift in sensor values !!! must change to def. Setting p= to zero eliminated the problem of it coasting past after stopping. I'm now going to type up a third version with c(the counter) as a parameter to find the best c (and possibly if there is any noticable change for s values. I will also find the best minimum speed) Using old program:(x values large and small) left rt s=60 -3 2 s=40 1 -1 s=20 2 2 s=10 -3 -1 s=20 looks like it is best-- albeit minimally. Of course, a and s are related-- so I'm kinda testing combinations thast decrease overshoot. However --the plotter is still being sticky ____________________________________________________________________________ 5/4: The lowest speed is 15.. so a will be set at 15. Also, set oscillation counter to 30 and shell (s) to 20. these can be modified. I'm now going to see how well this works for y axis... Yay!! it's alive!!! Ok, so now with a gotox and a gotoy in hand, I wrote up a square function and (yay!) it worked too!! (Must work on writing utensil attachment...) Am now writing up a line function... takes stepsize and figures out where to go from there. Ugh.... it seems to be working-- it is off, but hey, intilally this is a good thing. Problems-- doesn't know if at destination, and x axis does strange short then long stuff. Pen friction not accounted for and oscillates and doesn't necessarily start where it needs to (osciallates off pt it should start from-- hence small steps could cause great inaccuracy. ) Good points-- from distance is accurate and did indeed reach pt. ?'s possibly break up gotox so oscillations are optional... etc. eliminate oscilations by different constants in diff. programs... so, now I'll try to fine tune the y axis-- the x axis overall looks pretty good-- though because it's "sticker" it can have some problems.. ___________________________________________________________________________ 5/6: Indend to use testx for y (plug in appropriate motors) Unfortunatly, the wire and sensors are messed up on plotter... Max and Eric are right now trying to fix it.. Plans for the future of the plotter (and regrets about the plotter) ((a sum-up of this project in proper English... I hope!)) On how far it's come-- I'm very pleased with the progress I have made with the plotter; I have gotten it to draw despite all the problems with friction, the motors and the code I have written. :) On what I would like to do, given infinite time and brainpower-- I'd like to see it given a function and be able to draw it-- either crudely by tiny line approximations (already approximated by tiny x and y movemnts) or even just draw a straight line itself (have an internal function give it points and run both motors at the same time) Sigh... I don't honestly have any real regrets-- only the wish that I had the perfect plotter at my disposal. At the same time, part of (in fact most of) the joy of this job was overcoming the incessant barriers that keep cropping up out of the blue (which happens with a crusty old plottter :) Sure, I wish I could create the perfect code to make the motors stop on a dime, (and in fact that is what I aim for) but having to learn to tweak the code and install processes that will help make it more accurate (though at the cost of perfection) has been very interesting and fun. I have also learned more about how to develop code from what my abstract ideas about what I want the plotter to do. A overview of what I have done: (in case whoever's reading this can't wade through my broker sentences..) Brainstormed ideas about what I wanted the plotter to do (ideally) Learned about some control structures Adjusted the coordinate axes and wrote a readx() to read the x value of a point. Wrote up a gotox (1st draft-- renamed coastx()) and examined the behavior of it on the plotter (and tried to adjust acoordingly) gotox()(2nd edition, now testx()) and altered parameters to try to minimize error and have better control of the plotter. Created final gotox() and with it, a gotoy() Drew a square using code (square()) Tried approximating a line() with tiny movements up and over Trying now to improve line function by improving motion on the y axis That fixed-- spirals and such. (extra half hour!) ------------------------------------------------------------------------ 5/11: Showed off plotter for ESG lunch-- worked ok... Problems with square and spiral probably due to the random stickyness of x axis. Today-- ice cream? and finishing up stuff (evaluation... etc) ---------------------------------------------------------------------