1
\$\begingroup\$

We have a motion platform (camera - pan & tilt) that is controlled by a user using a joystick (so the demand inputs are pan & tilt velocities).

The platform itself uses stepper motors, so we have a control loop in our micro which handles the movement. It can either run towards the demanded speed (joystick) or move to absolute positions, in both cases taking into account accel/decel curves, speed limits/targets and movement limits (end stops).

What we want to implement is a record-and-playback of a sequence of movements executed by the user under joystick control. This presents a problem, as the user is giving us velocities (pan right 50% speed) at irregular time intervals and will expect the camera to smoothly replay the movement whilst also hitting the same positional targets they hit during the "recording" - at 50x zoom you have to be very accurate, a few steps off and you're pointing an entire screen away from what you're supposed to be looking at.

I believe this puts basic algorithms such as just recording changes in demand velocity & the time they occur as the potential for errors (especially cumulative errors on complex sequences) is too high.

There are a number of ways I can think of of achieving this, but they all seem quite cumbersome / inelegant and potentially memory-intensive for a small embedded environment (imagine recording position and speed 10 times per second for 60 seconds) and I have the feeling I'm missing something or going over old ground solving a problem that's already been solved 100x before, for example in industrial robotics.

Any thoughts, links, reading recommendations welcome!

\$\endgroup\$
  • \$\begingroup\$ IMU (tilt,compass,gyro) on the camera? \$\endgroup\$ – geometrikal Apr 24 '15 at 11:37
  • \$\begingroup\$ What would that gain us? \$\endgroup\$ – John U Apr 24 '15 at 11:39
  • 2
    \$\begingroup\$ Absolute position of the camera pan and tilt. Rather than record user input, record the IMU heading. e.g. It will give you camera 30 degrees down, heading 120 degrees. \$\endgroup\$ – geometrikal Apr 24 '15 at 11:41
  • \$\begingroup\$ We already know the position and speed of both axes, we count every (micro)step of the motors and have optical sensors for the end-stops. I'm talking about how to record the movement accurately yet memory-efficiently. \$\endgroup\$ – John U Apr 24 '15 at 11:50
1
\$\begingroup\$

Total re-worked answer:

The key is just make sure the data going to the motor controller is the same whether via the joystick or the memory. So as long as the data you store and the data from the joystick can be converted to an identical signal, which is then fed to the motors, it can't possibly do anything but give the same result.

One aspect that should be helpful, is given momentum of the motor, digital steps with a high enough resolution will virtually eliminate jittery camera movements. Plus you can also have circuitry to smooth out the steps.

So ultimately motors will need a signal which corresponds to a velocity. And the position of the joystick corresponds to that velocity. However, the signals between them can have an intermediate form, which could be acceleration, position, or velocity.

You say that memory storage will be a problem. But as a minimum you will need to store data which represents the position of the joystick. There is no way around that. If you want a sample rate of 10Hz, and the joystick has a high resolution, then it's going to need roughly 10 values recorded per second. But over 60 seconds, this only needs 600 words stored in RAM, which is comfortably available in low cost processors. For example, the AT91SAM3X8E (as used on the Arduino Due) has 96kB, which at 10Hz sampling of X and Y gives 80 minutes recording time.

\$\endgroup\$
  • \$\begingroup\$ Presumably we need to record positions and speeds though - it's one thing to arrive stopped at a given target position (we already do this for absolute positioning), it's another to pass exactly through that position at a given speed. \$\endgroup\$ – John U Apr 24 '15 at 11:52
  • \$\begingroup\$ Answer re-done - sorry, it was all over the place! \$\endgroup\$ – CL22 Apr 24 '15 at 12:01
  • \$\begingroup\$ I would like to point out that we are the motor controller, we literally generate the step & direction pulses in our software (interrupt driven, natch) based on a control loop as described in my question. The motors are driven by microstepping driver IC's, we can't add any hardware to achieve this. \$\endgroup\$ – John U Apr 24 '15 at 12:19
  • \$\begingroup\$ Ultimately, as long as the signal going to the stepper motors is essentially the same in recording and playback, the result will be the same (unless of course your stepper motors slip due to insufficient torque). So if you are sending identical discrete (digital) signals to the stepper motor ICs, movements during record and playback can only be the same. \$\endgroup\$ – CL22 Apr 24 '15 at 12:27
  • 1
    \$\begingroup\$ One way to approach it would be during recording as well as playback, send data to the stepper motor ICs directly from the memory. The only difference between recording and playback is during recording, the memory will be being populated "just in time", real-time. \$\endgroup\$ – CL22 Apr 24 '15 at 12:32
0
\$\begingroup\$

The approach becomes clear once you realize what the system actually does:

  1. Velocity input is given from the joystick.

  2. A trajectory generator takes the joystick input and generates position setpoints, with proper curves, etc.

  3. A position controller drives the motors so to follow the position setpoint.

When recording, save the output of (2). When playing back, substitute (2) with a recording. You can compress the data, for example by using hysteresis and run-length encoding.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.