Speed of a scissor mechanism

[Zatnikitelman]

I've run into a slight problem creating some solar arrays. Like the ISS arrays, the panels themselves are accordion-folded and they have a "cap" that translates away from the storage boxes. My problem is synchronizing the cap and panels, since the panels gain their linear distance by unfolding, their speed is variable, generally being fast at the beginning of the animation, and slow at the end while the cap's translation speed is constant. I'm having a problem trying to determine an equation for the linear speed of the panels. I've gotten as far as being able to determine the linear position since it's just a function of the angle, but I can't seem to make the leap from position to speed. I know the angular velocity of the panels' rotations about their axes, but I'm trying to basically get the X-component of the rotational velocity in the X-Y plane as a function of time. Can anyone help me figure this part out?

Thanks,
Matt

 

[ADSWNJ]

It feels like this should be straightforward. Assuming the panels each fold outward into the X dimension, then their contribution to the distance out for the cap should be just PANELLENGTH * SIN(ANGLE) for each hinge.

 

[Ghostrider]

Never thought scissoring could be so complicated...:blush:

 

[Loru]

Just animate cap same way as panel segment - if you reverese rotation of it relative to last panel segment it should stay in position.

 

[Thorsten]

I've gotten as far as being able to determine the linear position since it's just a function of the angle, but I can't seem to make the leap from position to speed.

If you have the linear position as a function of time, then the speed is just the derivative of that function with respect to time.

For an accordeon structure, there are always parts above the reference plane and parts below, so the easiest way is to describe the unfolding as rotation around the zero-crossings.

Say there are n zero crossings of the zig-zag line seen from the side. The cap moves with a velocity v0, and the attachment point is fixed, then the first crossing moves with v0/n, the second with 2v0/n, the third with 3v0/n and the last (the cap) with nv0/n = v0.

If the distance between zero crossings is L, which has to be the length of a full panel in the end, the rotational speed is omega = dphi/dt, the x-projection of that is then dx/dt = L sin(phi) dphi/dt

so you end up with a relation connecting linear speed v0 and rotational speed omega as

v0/n = L sin(phi) omega

which you can invert to set your rotational speed to

omega = v0/(n L sin(phi))

I'm not sure specifying speed is easier here than position... but this is how the math works.

 

[Loru]

Ok - not sure if this is what you're trying to achieve (next time a drawing would be nice ), however here is something I made in 15 minutes

(ignore skipped zoom out in first deployment sequence)

Short panel on the left is parent to next one, second panel is parent to next etc. and so on. The only component used is rotation.

spacecraft3 and mesh for testing is in attachment (press K to extend panel)

 

[Zatnikitelman]

Thanks Thorsten and Loru. Thorsten, I'm still a little lost with your calculations. I'll keep trying but for now I've decided to link the cap animation to the panel animation by keeping track of its position. However, that's led to another issue. The problem is that the cap animation lags behind the panel animation by exactly one frame. It's not an issue with a decent framerate, but I don't want to give users with less powerful computers a bad experience either, the FPS dips quite a bit while the animation is in-progress.

Here's how I implement it:

setup(...)
{
   track = new MGROUP_ROTATE(LOCALVERTEXLIST, MAKEGROUPARRAY(trkpt),1,_V(0.885,0.0,1.5, _V(0,0,1),(float)2.0*PI);
}

clbkPrestep(...)
{
   double da = dimdt*.05;
   if(pos < 1.0)
   {
      pos = min(1,pos+da);
   }
   else
   {
      status = 0;
   }
   this->SetAnimation(panelanimation,pos);
   cappos = (trkpt[0].x-0.885)/(35.730157-0.885);
   this->SetAnimation(capanim,cappos);
}

The problem as near as I can tell, is the vertex isn't updated until the frame has rendered. The call to set animation changes it for the next frame. So the VECTOR3 reflects the old position, which is used by the cap animation to set its "current" position. I've tried shuffling things around a bit, but so far, I haven't been able to synchronize things. I almost need to look ahead, or delay the panel animation somehow to keep them synchronized.

 

[Zatnikitelman]

My final solution ended up being simpler than I was trying to make it. Instead of grabbing the position of the panel, I end up calculating it. If anyone else needs this, here's the solution.
I use half-panels at each end in order to space the main panels, as well as centering them vertically. I determined the X-position of the panel through simple trigonomerty. cos(theta)*halfpanellength. I also start at 90 degrees, and it rotates down to 0 degrees so cos(theta) goes from 0 at the start to 1 at the end. From this, it was easy to see that the X-position of each successive full panel was simply 2*len*cos(theta) since it's a symmetrical geometry. Since I have two half panels, 2*len*cos(theta) is then multiplied by the number of full panels plus 1. From this, it was easy to make the cap position equal to the position of the X-position. Here's the code that would run in pre/poststep:

//calculate panel pos like normal (not shown)
this->SetAnimation(panelanimation,pos);
double theta = (PI/2)-((PI/2)*pos); //gets the angle in radians
double a = 0.145*cos(theta); //a for adjacent side (soh cah toa) 0.145 is the length of the half-panel
double panelabs = (a*242.0); //I have 120 full panels, two half panels so 2*(120+1)
double capabs = panelabs/35.09; //The X-Position of the panel as a fraction of its final position
this->SetAnimation(capanim,capabs); //LET'S DO IT!

The code really needs to be cleaned up to be more efficient, but broken up like that is a good way to show how it works.