ok, here are some updates on all of this...
1) I managed to setup the stepper control code so that you can run both motors at the same time, with varying directions and number of steps for both the horizontal & vertical axes separately.
So, from the command line, i can currently do something like this:
$ stepper [speed] [horiz_step_count] [horiz_direction] [vert_step_count] [vert_direction]
*NOTE:
By using this method, it's not possible to have different speeds for each axis;
simultaneous movement in both directions requires that only one speed be used.
Once I manage to get a device driver built, Im thinking that ideally you should be able to open up the device file, '/dev/pantilt', and write some kind of command string.
Perhaps something like:
// control string format
// [r|a:][p:][+/-]horiz_offset;[r|a:][p:][+/-]vert_offset;speed
// +/- value for offset indicates direction
// offsets can contain a modifier [r|a:val] => relative or absolute offset
// if not specified, defaults to relative offsets
// *absolute offsets must be positive
// *direction will be ignored for absolute offsets
// *x 'origin' is at right-most limit (facing towards camera) of horizontal range
// *y 'origin' is at bottom of vertical range
// percent offsets can also be specified by adding 'p:' modifier
// example: to center camera, use absolute 50% offsets, 'a:p:50;a:p:50'
// So, the following string
char *camCTL = "-30;a:20;600";
// would move the camera:
// - horizontally CCW 30 steps (relative to its current position)
// - vertically to the absolute position of '20' steps from the bottom
// - at a speed of '600' speed units (speed still needs to be worked out)
//now write to device file
int fp = open("/dev/pantilt", O_RDWR);
write(fp, camCTL, strlen(camCTL));
// reading from the device should provide status messages
// on the current speed setting, x,y ranges & positions
// So, doing something like the following...
char buf[BUFSIZ];
read(fd,buf,BUFSIZ);
printf("%s\n",buf);
// would print something like:
// speed:600
// x-range:500
// x-position:125
// y-range:80
// y-position:20
2) I also set up some 'calibration' routines that pan/tilt the cam through its entire range of motion in order to calculate the size of the horizontal & vertical ranges and to then 'center' the camera (while at the same time keeping track of the current position in both the horizontal and vertical directions). This will make it possible to perform movements to 'absolute' positions, which also leads to cool stuff like being able to have preset, user-defined 'camera patrol paths'. It also adds a little bit of a safeguard/protection for the stepper motors; since the current positions & movement ranges are known values, the motor control logic will not allow a user to try to run past the lower or upper boundaries of the valid x,y motion ranges (thus preventing the motor from being overworked or damaged due to having the motor 'banging' against the boundary limiters).
The only issue with this so far is that it's not 100% reliable, since the camera's position can be 'disturbed' by something or someone 'altering' the camera position, either with their hands or by some other outside mechanical force. If that were to happen, it would require that the calibration routine be run again. I guess this would require some kind of 'boundary checking' routine that will periodically verify that the calculated boundaries values are still valid? dunno, need to think about this some more...
3) slow speeds are still an issue, and it doesn't appear to be fixable until I can actually get a driver going that works and can leverage the lower latency available in kernel-space. Assuming that we *can* in fact go high-speed within the driver, it will certainly help a lot with the calibration routines (which are currently painfully slow).
...and that's all for now; questions/comments/feedback are welcome...
Menu
Account
Topic: controlling stepper motors - solved (Read 45959 times)