Velocity control?

[drbitboy]

A query for the motion control experts:

I have an app where I measure the position (encoder ∝ K * angle) of a rotating device, and use that along with some trigonometric calculations to continuously set (vary) the velocity of that motion device. In other words, I don't care about controlling the absolute position of the device from moment to moment, but I want do want to use the measured position to continuously control its velocity (pulse/s ∝ K * radian/s) at any time e.g. sending target velocity updates at around, say, 10-100Hz.

Is that kind of control available e.g. with a servo or other positioner?

I apologize if I am using any wrong terminology here; if summat is not clear please ask.

 

[Ken Roach]

That sounds like a dancer or tension roller application to me.

Can you describe more about the mechanism and the machine and the general size of the motor you're controlling ?

Do controls exist for this system now ?

 

[drbitboy]

That sounds like a dancer or tension roller application to me.

Can you describe more about the mechanism and the machine and the general size of the motor you're controlling ?

Do controls exist for this system now ?

It's a controlling a mirror on a spacecraft during a planetary flyby; look for dThDt in equation [3] about 2/3 of the way down here.

The existing controls I don't know a lot about, but I do know for the current mission they control the orientation of spacecraft such that the nominal boresight points at wherever the auto-navigation says the nominal target is, and then run the mirror (servo) at the desired constant scan rate (dThDtTDI), but mathematically that is not correct. So I know they can set the velocity of the servo once, but the question is can that velocity be "continuously" varied. I put "continuously" in quotes because of course this is digital i.e. discrete process.

I forgot to add OT to the title.

 

[mk42]

So I know they can set the velocity of the servo once, but the question is can that velocity be "continuously" varied.

I won't claim to know the details of your application, but to your question, the answer is "probably yes, but the details depend on vendor, control scheme, etc".

In the (Siemens) equipment that I usually use, it essentially boils down to sending a new Move_Velocity command each scan, with the newly calculated velocity setpoint. There are built in jerk limits and things like that to try to make sure you aren't asking for anything too mechanically stupid. This would work whether it's a servo or a VFD, but ultimately when you step up from a Speed Axis to a Position Axis, you don't lose any Speed capabilities, you just get new capabilities.

There's a million vendors out there, I'm sure there's at least one with a positioner that only controls position and not velocity. But big picture, seems plausible, ask your vendor about the specifics.

Note: the drive probably won't be able to DO the math to calculate the new setpoint each scan, but presumably there's a PLC or some other kind of controller to do that.

 

[drbitboy]

I won't claim to know the details of your application, but to your question, the answer is "probably yes, but the details depend on vendor, control scheme, etc".

In the (Siemens) equipment that I usually use, it essentially boils down to sending a new Move_Velocity command each scan, with the newly calculated velocity setpoint. There are built in jerk limits and things like that to try to make sure you aren't asking for anything too mechanically stupid. This would work whether it's a servo or a VFD, but ultimately when you step up from a Speed Axis to a Position Axis, you don't lose any Speed capabilities, you just get new capabilities.

There's a million vendors out there, I'm sure there's at least one with a positioner that only controls position and not velocity. But big picture, seems plausible, ask your vendor about the specifics.

Note: the drive probably won't be able to DO the math to calculate the new setpoint each scan, but presumably there's a PLC or some other kind of controller to do that.

Thanks. One issue, I think, is whether sending a new velocity setpoint every dozen or hundred milliseconds, and it sounds like that is not an uncommon capability. Another issue is whether the comms capability exist on the spacecraft to transmit that often (probably RS-422 or summat). So it's plausible, but I'd have to check with the vendor and builder.

And yes, the calculation would be done by something other than the drive.

Thanks again!

 

[Gene Bond]

I have seen some servo/stepper systems that once you send the command, you must either cancel the current 'move' to give it a new velocity. I guess it's just a dump the command that way, and trust that the drive does what its supposed to. So, it probably is vendor specific if you can change velocity on the fly.

 

[Steve Bailey]

I think you should be looking for a motion controller that includes a "Move at Velocity" command in addition to the usual move to position at specified maximum velocity. And of course, you must be able to change the velocity on the fly. The controller I have hands-on experience with is a module in a GE PLC that interfaces to a Fanuc drive. There are three analog output addresses assigned to the module per axis for transmitting commands and associated data. Once you send the Move at Velocity command you can change the velocity as quickly as once per program scan. Doing so presumes that you can recalculate the desired velocity that quickly. If the recalculated velocity command is coming from outside the PLC that will likely not be possible. Of course the delta V from one scan to the next is limited by the commanded acceleration and the ability of the motor to supply enough torque to make it happen.

 

[Peter Nachtwey]

I don't under the problem. drbitboy says the mirror is turned by servo motor and he has the math done in great detail. I also don't understand why drbitboy is asking here. Nothing you can buy commercially is going to put on a space craft.

Most motion controller have a move velocity command. Issuing new velocity commands on-the-fly is not a problem. Most motion controllers can do the trig and the RK4 easily since nothing is going to change that rapidly. Generate the non-linear motion profile is not a problem since drbitboy has the equations worked ot.

Another thing I don't understand is what is drbitboy going to use for the initial state for the RK4? The encoder must have very fine resolution if it used to rotate a mirror to track an object. Also, drbitboy's equations use angle ( theta ) which I assume is the angle of the mirror.

I tend to always think in terms of position, velocity and accelerations since they are all related. If you know what the velocity should be you also know how the position ( angle ) has changed from the initial state. How does drbitboy use his equations without knowing the angles?

Can the mirror/camera be programmed to track the object using an image matching/tracking algorithm? Then the speed control isn't so important, but I still think the mirror must have very fine resolution to move at small angles slowly and smoothly. After all, nothing is changing that fast.

The RMC could do the motion control easily, but it isn't fit for space or aeronautics work.

 

[drbitboy]

Way OT!!!

Issuing new velocity commands on-the-fly is not a problem.

Thank you, that is what I was looking for.

The spacecraft has already launched; I was mainly curious about how these things are controlled.

TL;DR

I don't under[stand] the problem.

It takes a while; on the last mission I think that maybe a handful on the team fully understood it, although a lot more had a rough idea. Even the one person who first thought that something was amiss in the original planned approach only got there by intuition, and it took her over a year of asking questions trying to understand it before someone finally said "oh."

The instruments in question use an observation technique called TDI (Time Delay and Integration), which means they need to have whatever target is in the field of view (FOV) scan across that FOV at a constant angular rate, and the only way to control that is to control the angle Theta of the instrument boresight.

Theta is the inertial angle that represents vector of the scanning boresight over time relative to an inertial reference frame i.e. to the stars, in the plane of the trajectory of the spacecraft and the target. The angular velocity dTheta/dt needs to compensate for any rotational velocity of the spacecraft and the instrument pointing platform, but that is the easy part.

The spacecraft only has best estimate (model) of where the target is, plus uncertainties. The spacecraft trajectory (velocity vector, a.k.a. along-track) is essentially a straight line. Looking from behind the spacecraft, the cross-track uncertainties are small, but the uncertainty is much higher along-track, because that is based on parallax i.e. cotangent of a very small angle.

So the instruments need to scan through positions significantly uptrack and downtrack from the nominal estimate to ensure capture of the target e.g. 3σ+ (it would not be good to say "we spent all this money but missed the target because of measurement uncertainties.").

The solution currently in place is to calculate the angular velocity of the spacecraft-target vector in inertial space, using the nominal target position, and set the scan to move at a constant rate relative to that vector. That works fine when the scan is indeed pointing at that nominal position, but for scanning off-nominal positions where the target may be, it would yield degraded TDI data.

It turns out that the nominal estimated position of the target is a distraction from the actual solution to this puzzle.

As can be seen from the derivation of equation [3] in that Github repo readme, the correct angular velocity at any scan orientation is independent of the along-track nominal target position, and dependent instead on only (i) the angle theta itself, (ii) the along-track velocity of the spacecraft relative to the target, and (iii) the nominal flyby distance at closest approach. Item (ii) has a small uncertainty by orbital mechanics, and item (iii) has a small uncertainty as it is a cross-track value. Item (i) is measured by the on-board attitude determination system (star trackers) and also has small uncertainties.

Hey, I said OT and TL;DR, so if you read this far, you have only yourself to blame .

 

[Peter Nachtwey]

Thank you, that is what I was looking for.

OK, but I doubt they used velocity control on the mirror. I bet they used digital image processing. Think about this. What is the field of view of the camera? What would the resolution need to be to smoothly move the mirror and even then some digital processing would be required.

The spacecraft has already launched; I was mainly curious about how these things are controlled.

I doubt they were using speed control to move the mirror. From what you wrote I bet they used digital processing to figure out how the image moved across the mirror.


If you have a frame of an image and multiply it by pixel by pixel with the next frame and sum, you get a number. If the image moves and you do the convolution the number will decrease. If you try shifting the coordinates one pixel in each of the 8 directions and doing the convolution, you can tell which direction the image moved in the field of view.

Hey, I said OT and TL;DR, so if you read this far, you have only yourself to blame .

Ok, so you hooked a nerd. Are you proud?

But I learned what timed delay integration is. The same technique is used in sonar.

 

[drbitboy]

OK, but I doubt they used velocity control on the mirror. I bet they used digital image processing. Think about this. What is the field of view of the camera? What would the resolution need to be to smoothly move the mirror and even then some digital processing would be required.
...
But I learned what timed delay integration is. The same technique is used in sonar.

Sorry, I think you lose the bet, but you did ask the right question (in bold blue above)to understand why: the FOV of the detector is probably 5k+ pixels by 32 pixels, with each pixel being 10µradians square, but the FOV of each "camera" data sample is effectively 5k+ pixels by 1 pixel. Yes, "1 pixel" is not a typo.

The trick is to ensure each of the 32 rows of detector pixels have imaged the same terrain, each row at a different but sequential time, on the target when their summed result ends up in the 1 line of the sampled (measured) data.

If you learned what TDI is, then you know there is no frame-to-frame digital image processing, because TDI is in the end a fancy way to emulate a high-gain single-line imager, so each data sample is 1- not 2-dimensional, and 1 pixel of smear (minimum) is built-in to the measurement process. So we do need to control the mirror velocity to ensure the target image moves at a set angular velocity across the detector in a direction perpendicular to that single line of the imager.

To put it into a PLC context, with FIFO FFL/FFU instructions modeling the charge transfer process on the detector, and the row array modeling a column of pixels, this is what is going on in each of the 5000 columns, with row[1..32] being inputs of counts of photons at a pixel accumulated between each charge transfer step (chgxfrTON expiry), and with accum[1..32] accumulating the total photons from, and moving with, each piece of terrain as it moves across the detector:

   chgxfrTON/DN

-------]/[---------[TON            ]----

                   [Timer chgxfrTON]

                   [PT         20µs]

                   [ET            0]



   chgxfrTON/DN

-------] [-----+---[ADD            ]----+---

               |   [SrcA  accum[32]]    |

               |   [SrcB    row[32]]    |

               |   [Dest  accum[32]]    |

               |                        |

               +---[ADD            ]----+

               |   [SrcA  accum[31]]    |

               |   [SrcB    row[31]]    |

               |   [Dest  accum[31]]    |

               |                        |

               +---[ADD            ]----+

               |   [SrcA  accum[30]]    |

               |   [SrcB    row[30]]    |

               |   [Dest  accum[30]]    |

               |                        |

               |         ,,,            |

               |                        |

               +---[ADD            ]----+

               |   [SrcA   accum[1]]    |

               |   [SrcB     row[1]]    |

               |   [Dest   accum[1]]    |

               |                        |

               +---[FLL            ]----+

               |   [Dest    #row[1]]    |

               |   [Length       32]    |

               |                        |

               |                        |

               +---[FFU            ]----+

               |   [FIFO      accum]    |

               |   [Dest   sample32]    |

               |   [Ctrl    ctrlTDI]    |

               |   [Length       33]    |

               |   [Posn         33]    |

               |                        |

               |                        |

               +---[FFL            ]----+

                   [Src           0]

                   [FIFO      accum]

                   [Ctrl    ctrlTDI]

                   [Length       33]

                   [Posn         33]

​

 

[GaryS]

This sounds like a good application for an electronic line shaft
Here is a good link I think will help you
Electronic Line Shaft with Alignment GA800 Drive Software Technical Manual - Yaskawa

 

[Peter Nachtwey]

So what is the resolution of the encoder and how many counts per second is the typical velocity?

 

[drbitboy]

So what is the resolution of the encoder and how many counts per second is the typical velocity?

Haha yeah some expert put "export controlled" on that document so it's not easy to get.

I agree that it's important for the eventual solution, but at this point I don't think they are willing to send more than one velocity command per observation, and observations are typically of order 10¹ to 10² seconds, while doing it right would send updates at 10¹ to 10² Hz, so it's an implementation detail for now.

 

[Peter Nachtwey]

Haha yeah some expert put "export controlled" on that document so it's not easy to get.

I agree that it's important for the eventual solution, but at this point I don't think they are willing to send more than one velocity command per observation, and observations are typically of order 10¹ to 10² seconds, while doing it right would send updates at 10¹ to 10² Hz, so it's an implementation detail for now.

So what is controlling the velocity from millisecond to millisecond?

The trick is being able to follow a velocity profile as you show in your document where the angular velocity of the mirror is changing very slowly. At slow speeds the encode must have very high resolution or be geared down a lot so the velocity doesn't change in steps determined by the encoder resolution.