Linear Motion From Moving Lights

cdiamondz

Active Member
Here's an interest I've been having since the summer of 2015: making straight, "linear," movements from moving lights. I've always wanted to tackle this because moving lights move in an arc rather than going directly from one point to another. It's been a while since I've done a lot of trigonometry, however I have gone through the process of double checking that I remembered stuff correctly for this, and I believe I have figured out something to try and duplicate such a motion, however, with a few number of issues that should be solvable with logic if-statements in code if ever put into a console other than the Cognito console from Pathway Connectivity and a few others (AKA Eos). I found the website "Desmos" not too long ago and have been using that to help aid in the development of the formula to do this.

www.desmos.com/calculator/mgepybx7nw

For those that wish to be given a direct answer for the formula, here it is:
Code:
real_tilt = atan( tan(tilt + 90) / cos(pan - pan_shift) )

tilt going to fixture is 'real_tilt'
pan going to fixture is 'pan'

Simplified, it takes the desired tilt (when pan is 0 degrees), pan, and a shift in the pan when making straight lines that are not perpendicular to 0 degrees pan.

I hope some others can give some input into this concept and help maybe bring this concept to some decent consoles.
 
Last edited:
I think your base premise is incorrect. Indeed, if a light is going from point A to point B, with no time applied, its motion may end in an arc, but once a time value is applied, the light (Or console, depending on which device is computing the time) moves in a line. If a P/T cue has a time value, whichever axis has a greater distance to travel will move proportianally faster than the other axis, resulting in a line of travel. It works so well, that I have never experienced a problem with lights moving in an arc. Nor has any programer or designer I have ever worked with, so I can't see console developers devoting resources into putting this into a desk. (not to mention real world variables such as different models of lights having different ranges of travel, and thus different DMX scaling)

Just my $0.02
RB
 
@RonaldBeal, Unless you've programmed all your shows on an Entertainment Technology Marquee, Strand Light Palette or Pathway Cognito I find your observations hard to understand. In the mid 90's Hog II and MA Scancommander had methods of setting up and programming in XYZ space but you can't fall into that accidentally - it was labourious to setup and non-intuitive to programme in.
To understand what we did with Cognito, look at this white paper originally published in 2005 by Horizon Control.

This video shows what the average DMX console does with P/T vs. what we do. It's non-trivial math and does, as you suggest Ron, deal with "real world variables such as different models of lights having different ranges of travel, and thus different DMX scaling".

I hope some others can give some input into this concept and help maybe bring this concept to some decent consoles.
The 'big boys' have seen our linear movement working 12 years ago and we've been shipping it in our own consoles since then. Good luck getting it implemented into a 'decent' console. It's cool when it works.
 
There was a console several years ago that made a big deall about solving this "problem". I can't remember the name at the moment, but I think they were bought out by a larger company.
 
I think your base premise is incorrect. Indeed, if a light is going from point A to point B, with no time applied, its motion may end in an arc, but once a time value is applied, the light (Or console, depending on which device is computing the time) moves in a line. If a P/T cue has a time value, whichever axis has a greater distance to travel will move proportianally faster than the other axis, resulting in a line of travel. It works so well, that I have never experienced a problem with lights moving in an arc. Nor has any programer or designer I have ever worked with, so I can't see console developers devoting resources into putting this into a desk. (not to mention real world variables such as different models of lights having different ranges of travel, and thus different DMX scaling)

Just my $0.02
RB

This isn't a finished product by any means, and I am still looking further into it. I have, for now, just this example that moves only perpendicular to 0 degree pan. It will, of course, will be much more advanced than this to make it real-world practical. I'm just currently wondering about what others have been thinking about as for linear motion between point A and point B. It would be pretty cool if it was implemented into ETC consoles and other manufacturers' consoles. I am, currently, trying to solve the problem of obtaining the shift required in pan for points that are not perpendicular to 0 degrees. This would require much more math and much more time to solve to calculate it. I am still thinking of continuing to work in top-down with height above the ground surface being 1 unit below as this would theoretically work 100% of the time. I am currently having my right arms moved from their current unreachable position to somewhere else and I will eventually test this using my Element console with my laptop connected to it with OSC to output values. As for DMX scaling, I have found that at least ETC consoles allow you to set minimum and maximums for custom fixtures so you can change the scaling so that 1 unit on the console would equal 1 degree on the fixture. The number outputs are currently all degree values on my example calculator. I hope that this helps for those that are confused by a lot of left-out information.

EDIT: I also just remembered that you mentioned proportional speeds between pan and tilt. This is true, however, if tilt is unchanged, an arc is very apparent, especially when the projected circle is larger.
 
Last edited:
Ah, I see... Rob, the video is a good illustration of the issue. Thanks. I will, however re-iterate, that in 23 years of touring A light moving in an arc vs a line has never been an issue with programmers or designers. I'm sure there are some special use cases where it would matter, but today is the first time I was even aware that it was happening.
Regards
RB




@RonaldBeal...
This video shows what the average DMX console does with P/T vs. what we do. It's non-trivial math and does, as you suggest Ron, deal with "real world variables such as different models of lights having different ranges of travel, and thus different DMX scaling".

The 'big boys' have seen our linear movement working 12 years ago and we've been shipping it in our own consoles since then. Good luck getting it implemented into a 'decent' console. It's cool when it works.
 
The ability to do this exists in the Cognito console. Almost spec'd one as a sidecar on a recent show. Can't you do it on the MA2?

Anyways, if you want to cheat instead of figuring it out, here's how.

It is on the list for the Eos series.
 
T
Ah, I see... Rob, the video is a good illustration of the issue. Thanks. I will, however re-iterate, that in 23 years of touring A light moving in an arc vs a line has never been an issue with programmers or designers. I'm sure there are some special use cases where it would matter, but today is the first time I was even aware that it was happening.
Regards
RB
@RonaldBeal & @Rob: This is an excellent discussion you are having. Thank you!

First a disclaimer for the readers: I work for Pathway Connectivity so keep that in mind as you read what I have to add to this discussion.

Cognito was not developed for concert touring although many of us who work to support this product have that experience on our resumes. Linear movement - having been a feature of the Marquee and Palette - was already in the code base used for Cognito. What we have focused on here is to bring an enabling technology and user interface to a user group (teachers, volunteers, etc) who have never been trained to program lighting, let alone complicated multiple attribute instruments. To this group, they don't know why a lighting fixture should not move in line - to a position and back - when you push a fader up and down. We, the trained individuals, know that such a thing is almost impossible to do. The idea of Cognito is that for our targeted user group, the console should just do what the user thinks it should do. For example, to a drama teacher trained in acting & directing, the approach to lighting a play is going to be linear because blocking is linear. Actors move from right to left, upstage to down stage and diagonally across the stage. For the most part, blocking is not polar.

I hope that this discussion continues. Thank you for hearing me out.

Best Regards,
Pathway Connectivity


Van Rommel
Director Business Development
 
This video shows what the average DMX console does with P/T vs. what we do.
Near the end of the video, when the four lights in four colors move from SR to SL in a cue, they moved linearly. But when they reset to SR (<Back> button pressed?), I notice they go "polarly." Is this a fly in the ointment? Shouldn't there be a global default setting?
 
I would love to see this on ETC consoles. The tinkerer in me is wondering is something can be done with a raspberry pi and OSC in lieu of official console integration...
 
Near the end of the video, when the four lights in four colors move from SR to SL in a cue, they moved linearly. But when they reset to SR (<Back> button pressed?), I notice they go "polarly." Is this a fly in the ointment? Shouldn't there be a global default setting?
It's just because they move in zero time. The tilt doesn't move much at all where as the pan has to go almost 180°. When you do that in zero time it looks like an arc. If you look at the head when it is doing the linear move you will see it tipping down and then midway through the Q it will tip up. In a straight DMX fade from one percentage to another percentage that requires changing direction midway through the cue. This is not possible in zero time.

The other neat thing is the light moves at constant velocity, which means the profile on the fade is custom tailored to each head. That means if 10 lights go from A to B, regardless of where they are hung, there will be just one dot of (very bright) light moving on the stage.
 
Last edited:
I would love to see this on ETC consoles. The tinkerer in me is wondering is something can be done with a raspberry pi and OSC in lieu of official console integration...

ETC has more than enough horse-power (and brain-power) to implement this. We have always liked engaging users such as yourself (tinkerers), that is why our consoles have a lua interpreter. It allows you to script rather complex macros with if-then-else and math etc and call it at will. It was heavily used on the Palette, but not so much on Cognito. I expect its full capabilities will be explored as Choreo gets more and more popular with integrators.
 
grandMA2 does support XYZ positioning/linear movements based on this. It's actually remarkably simple to setup.

The biggest thing missing for this to work is for consoles to know where the lights are in 3d space. Once you know where the lights are, you can figure out where they are pointing and how to move/interact with this information. Then you can tie in something like Posistagenet or similar to respond to items moving in 3d space. I suspect we'll see these ideas make huge leaps and bounds forward over the next few years, MA has done a fairly good job of implementing it but I think ETC will make it more user friendly if/when they decide to implement it...
 
The biggest thing missing for this to work is for consoles to know where the lights are in 3d space.
When you say "for THIS to work" you mean XYZ programming (and setup). Our linear movement takes no setup and does not require you to define USL, USR, DSR and DSL (reverse kinematics) to define the location in 3-space.
For a TBT, the Hog II "Beacon" was cool. Did anybody else here ever see it work?
 

Users who are viewing this thread

Back