Thoughts

So a couple of things that need mentioning:
The workspace needs to be limited to about 3-5 cm in height and maybe 10 cm width, 10 cm isn't really necessary but it's possible
but the height is very much limited to that range
The motor can move in a straight line now, and effecetively move in any shape we have the coordinates for.
George isn't gonna give us that list though, not until we sort some stuff out.
for example, the motion of the motor is not very smooth on the return to the intial position, that is bad because if it's not very smooth,
it's not gonna be very accurate. During testing yesterday, i saw that the motor returns to an intial position slightly different from it's
starting point. That is bad as it makes us loose track of where the motor is. The reason as to why it isn't smooth is: it makes a jump to
the last position, to negate that we need a function that I ask you to write. This function gets 2 points x and y, then creates an array 
of points forming a straight line connceting these two points, you can copy and paste the point function included in "Trial_1"
This function is useful as it might make the motor's motion more regulated and thus more percise.
I will update this later on today, with more ideas that I had and that you should keep in mind




Nov27update_above >>>>>>>>>>>>>>>>>

As to which configuration we're using for the inverse kinematics, we're definitely using the +- configuration (bottom left corner 
diagram in the paper), we're restricted to using this particular one as our motors cannot move in the other ways, those are restricted
to setups that have full 360 range for the arms. So that might simplify things a bit. As to implemting a way for the motor to move,
provided I know where the motor is gonna start I can tell it how and where to move. The basic idea is having a 'point' class that holds
an array of points each has it's own x and y coordinates, this array is then passed to the function i've written and keeps running 
N number of times where N is the number of points, implementaion is gonna be a bit tough tho, but the underlying concept is simple:

                 angle to move through=angle of new position - angle of last position
                 
This value is then passed to the loop that moves the motor the appropriate number of micropsteps on whichever direction. At the end, we 
move the motor back to it's intial poistion via the same process except that the "angle of new position" is a constant that we're gonna
set ourselves.

tomorrow I'm going to the AIM lab to make some measurements, all of which are gonna be posted in a document, this document will hold:
      -size and location of workspace
      -length of arms
      -some diagrams if i can upload pics, i think i can.
      -intial (x,y) point or the 'origin' if you will
      
The last value needs to be included as all our x,y coordinates will be offset by the difference from that intial point to our workspace,
if I'm not making any sense right now, I'll make the measurements and explain using some diagrams.



Nov21update_above>>>>>>>>>>>>>

The answer to question 1 I think is rather simple - to re-initialize the motor positions after every operation 'set' so that it always
goes to a certain position. The way to implement it would be to use a global variable or a class variable (maybe?) which keeps track of
the motors' positions in the number of steps - positive clockwise and negative anticlockwise, for example. It then performs a function to
bring the motor to 'zero' position.
I think using an object might not be a bad idea because we have Motor1 and Motor2 which are both same functions, anyway.
Moreover, we can use a destructor function to return the motor position to zero.
I'll try this by Friday.

Question 2 is actually kinda hard, because I totally forgot that the motors have to move together. And smoothly, too.
Likely we have to employ some kind of speed control later on as well, which complicates the matters.
Maybe not? If there are enough points? Who knows. Then we need a mathematical way to determine which of the four motor positions
will be accepted (inverse kinematics paper says that there are four ways to get to the same position. the program must be able to
make a decision which one to get to).
We can either have a program do a calculation for the nearest movement... or just restrict left motor to positive position only.
That might be easier.

Anyway, I think inverse kinematics is a bit harder than expected, especially because we need to figure out a way for the motors
to move simultaneously now. Let's aim to get that working before inverse kinematics... by Sunday.


Nov15update_above>>>>>>>>>>>>>>>>>>>>

a couple of things i've been working on:
1. A way to initalise the position of the motor in the beginning of the loop (still don't have a good solution)
2. a way of implementing the inverse kinematics

I still don't have a good solution to the first problrm, feel free to discuss, but the second problem is doable, the basic concept is this:
we set a constant number of intervals for every letter in the alaphabet (e.g. for the letter L there will be 40 dots to connect, thus the
motor needs to be programed to move the magnet across those dots.)This part can be purely hardcoded as i can't think of a function that
does that, hardcoding shouldn't be too much of a hassle though. we then develop a function that takes in those 40 dots' x and y coordin-
ates, and spits out an angle for both motors (this is done soley using the inverse kinematics formulas we got from george.) These angles
will be stored in an array corresponding to each of the letters. These arrays are going to be what represents each letter for our motors
we then develop a function that calls itself (recursion) this function takes as it's input the two arrays generated (2 as there is an array
for each motor) and it's last position (angle of the motors) then it moves the motors by the corresponding angles. The function stops once
a certain counter matches the number of points (i.e. this function stops when for the letter L that counter reaches 40.) 

A couple of things we need to do before that is figure out how to intialise the position of both motors, the one idea i had was to make
them move in a certain direction a certain number of steps that i know exceeds their maximum range of motion but that might damage the 
motors (that's why it's a bad idea) and i can't figure out other solutions that don't involve a sensor, I'll ask George for his input maybe
he has some ideas.

another thing we need to know is the size and dimensions of our work space, there's a section in the pdf George sent us about that. This
is a simple matter of making measurements on the actual hardware and doing some maths,shouldn't be difficult, knowing the size and 
position of our workspace should help with position control and tracking (for example since we know that the motor can't exit the 
workspace we'll have a range of the angles the motors can be in)

as to how we'll keep track of the motors during run-time, we'll have 2 variables that are constantly updated with every movement.

more comments: we need to adjust the code such that the motors move sequentially (both at the same time or one after the other) they can't
move independently.

I think that is it in regards to the inverse kinematics portion, if you have other ideas post them here and tell us on the group so that
we're all up to date, I'll be working on the code that moves the motors (the recursive function that takes in the angles and moves the
motors accordingly.) I'll test out said function on either thursday or wednesday put ill post it when im done with it.