Start a new topic

Trisynchronous Motion

Welcome to the PTZOptics forum(s)!


This thread has been created for end users to discuss the topic of PTZOptics working on Trisynchronus Motion for preset recall.


Please make sure to respect the experience level(s) of all users at all times when posting within our forums or your account may have access removed.



Currently PTZOptics provide a very standard form of robotic camera movement when recalling presets.


Please provide any thoughts or feelings on the potential addition of a camera, or cameras, with the capability to provide a form of trisynchronus motion for preset recalls.


7 people like this idea

Hi Mark,


No worries it's hidden pretty well to be honest :-)


So the new "speed range" for MotionSync is, sort-of, a common denominator situation between the P/T/Z speeds available.

Unfortunately the current ranges are a limitation of what the motors can offer before they begin mis-behaving.


While this is not truly a fix, and actually somewhat of a bug, currently MotionSync will listen to speed adjustments made to the Zoom Preset Recall.

You may find that slowing this action down, depending on your total movement, may actually provide the slower appearance you're looking for.

As this is unintentional and can cause the MotionSync to become out of sync you may witness the Zoom finishing before or after your motions once adjusted.

If things are "close" this may be worth trying though.


This is something we're continually evaluating better ways to implement towards that goal of a beautiful single production capability.


If you have any questions, ideas or general curiosities please don't hesitate to come back to the forums!





Thank you Matthew, I assumed since it was 'beta' it required an update. I should have looked more carefully at the OSC menus!


So I have experimented with both of these features (Call Preset Speed and Motion Sync) for the last 2 weeks of broadcasting our church services. My conclusion is that the speed of preset motion without Motion Sync is nicely controllable, but the path it takes is usually not good e.g. it may zoom in before panning - not a good visual effect.


Motion Sync provides a much better visual effect (path), but even at it's slowest setting it is still much too fast. For some reason the minimum value I can set is 185 (no idea what the units are, clearly different than the Call Preset Speed). Even at that minimum value the movement is much too quick. Would it be possible to provide some slower speed settings for Motion Sync?


This is so close to being prefect for our 1-camera live broadcasting...


Thanks!

Hi Mark,


Sorry to hear that you are disappointed in your current interactions with your PTZOptics camera.

I believe the instructions below will help guide you to where you can make the adjustments to the camera(s) that you are looking for.


OSD Adjustment for Preset Recall Speed 

Applies to PT12X-XXX-XX-G2 / PT20X-XXX-XX-G2 / PT30X-XXX-XX-G2 model(s)


As it sounds like you have the ability to use the IR remote and view the feed at the same time you can make the adjustment to Preset Speed Recall via the OSD, On Screen Display, as shown below.



OSD Navigation Instructions

This section can be reached by pressing the "MENU" button on your IR Remote

Navigating down to the "P/T/Z" section, using the down direction button on the IR Remote

Clicking the "HOME button on the IR Remote to enter the "P/T/Z" adjustment section

Navigating down to the "Call Preset Speed" section, using the down direction button on the IR Remote 

Now using the left and right direction buttons on your IR Remote adjust the number shown to your desired speed.

Note: 1 is the slowest possible option while 24, default, is the fastest.

Now use the "MENU" or "Return" buttons to exit out of the OSD Menu.


Note: If you do NOT see this option available in your OSD Menu you will need to upgrade your firmware to gain this feature.

Please find the correct firmware for your camera, along with instructions, by using the PTZOptics Firmware Finder


Enabling the experimental "MotionSync" technology for more synchronized P/T/Z movement

 Applies to PT12X-XXX-XX-G2 / PT20X-XXX-XX-G2 / PT30X-XXX-XX-G2 model(s) 


As it sounds like you have the ability to use the IR remote and view the feed at the same time you can make the adjustment to enable the experimental "MoitionSync" via the OSD, On Screen Display, as shown below.



OSD Navigation Instructions 

This section can be reached by pressing the "MENU" button on your IR Remote

Navigating down to the "SETUP" section, using the down direction button on the IR Remote

Clicking the "HOME button on the IR Remote to enter the "SETUP" adjustment section

Navigating down to the "Motion_Sync" section, using the down direction button on the IR Remote 

Now using the left and right direction buttons on your IR Remote adjust if the feature is "On" or "Off"

Once "On" navigate down to the "Max_Speed" section, using the down direction button on the IR Remote 

Now using the left and right direction buttons on your IR Remote adjust the maximum speed allowed for Pan or Tilt movement

Note: Typically higher speeds being allowed for movements with an extreme pan or tilt will help with the ability to operate

Note: The latest firmware has removed the Min_Speed as it was deemed to have no valuable impact

Now use the "MENU" or "Return" buttons to exit out of the OSD Menu.

Note3: This is an experimental feature and may not always operate as you expect... 

if planning to use this feature in production we recommend setting up all shots ahead of time to ensure your are able to achieve the desired effect.


Note: If you do NOT see this option available in your OSD Menu you will need to upgrade your firmware to gain this feature.

Please find the correct firmware for your camera, along with instructions, by using the PTZOptics Firmware Finder


I hope the above instructions on adjusting Preset Recall Speed and enabling the experimental MotionSync feature via the cameras OSD is helpful towards achieving your desired production.


If you have any additional questions, please do not hesitate to come back and we'll do our best to assist.




1 person likes this

"rough example as discussed prior is available in firmware"


How could we get this firmware for our PT20X-SDI-GY-G2?

I would be happy if the current preset motion was just SLOWED DOWN! The hardware is capable because I can set a slow speed in the camera's web app and the arrow keys make a nice slow sweep. But when I select a present it goes way too fast - even though I set slow speeds in the web app (seems the speed settings don't apply to the presets... why not?).


We bought this camera to use in our church for live streaming - partly because the presets make it dead easy for a novice operator to frame the pulpit, or the choir, or any other preset we setup. I was hugely disappointed to find that the presets are almost useless for live streaming because it moves much too fast, it leaves the viewer dizzy.


And now I find that setting a slow "arrow" speed in the web app does not slow down the motions made from the remote arrow keys. Another pitfall - the remote is part of that 'dead simple' concept essential for church volunteers. Adding a computer, display, and keyboard requirement to run the camera is another big bunch of stuff to learn and go wrong.


This camera hardware is completely capable of being a very easy to use system for live streaming, but the firmware is not quite right for it.

Hi Tim & Brian,

So the rough example as discussed prior is available in firmware as we received enough requests for it's availability in the current state they saw.


Unfortunately we have not been able to handle the lack of precision in our motors using the scaled method as Tim had kindly presented... yet.


As we evaluated our efforts there versus looking at designing a platform that could properly support this, and more, we have shifted our focus towards a higher precision platform.


That being said the method associated for our current generation of cameras is something I am continuing to work on in the evenings in hopes of allowing it to handle the movement more like Tim had suggested.


We definitely recognize this as a very important aspect to further the production capabilities of the PTZOptics platform.


Tim I hope to still reach out to you if I feel like I have a semi-working implementation of your low-res model in hopes of seeking suggestions on refinement :-)




1 person likes this
I would love to get an update on this topic.

Any new developments in this area?

Thanks.

Hi Tim,


You definitely have some good experience with this :-)


You have a few variations on the concept from what we have been testing with that will be very interesting to trial on the hardware.


Give me a few weeks, I'm hoping, to look at re-designing the code to play nice with the rest of the currently operating system using these variations.


I'll be happy to report back here as we progress.



I greatly greatly appreciate you taking the time to not just shoot over some equations but rather provide some nice explanations alongside.


I look forward to attempting to implement this per the notes above; if I hit a road block I'll definitely take you up on your very kind offer to chat about this directly.



If anything else comes to mind I'm all ears... or eyes in this case.

Sample math example with low resolution:


X, Y precision is limited to 20 x 20.


We wish to go up 80 and right 45 in 5 steps (per axis).

 

80/20=scale 4:1

45/20=scale 2.25:1

Must use smaller scale of 4

 

Virtual commands

U16, R9,

U16, R9,

U16, R9,

U16, R9,

U16, R9

(Add up the montions and end is 80 higher and 45 right of the start)

 

Simple application of the scale

16/4 = 4, 9/4 = 2.25 (which rounds to 2)

Remainder is always the unrounded movement minus the actual rounded movement

 

Actual application of the scale and rolling remainder:

Physical Commands

U4, R2 ROUND((9/4)+(0)) = 2.25 rounded to 2, remainder= +.25, we are short .25

U4, R3 ROUND((9/4)+(.25)) = 2.50 rounded to 3, remainder= -.50, we are now .50 too far

U4, R2 ROUND((9/4)+(-.5)) = 1.75 rounded to 2, remainder= -.25, we are only .25 too far

U4, R2 ROUND((9/4)+(-.25))= 2.00 rounded to 2, remainder= 0, we don't owe anything

U4, R2 ROUND((9/4)+(0) = 2.25 rounded to 2, remainder= +.25, we are short .25 again


The final result of the physical movement is U20 and R11.

Since actual steps must be integer amounts, this is ok and expected. 


The goal of 45 virtual to the right divided by a scale of 4 would be 11.25 steps, so we ended as close to perfect as possible.


Any variance is spread across the entries, in this case to the second command pair.


If you cycled another 5 step pairs back toward the start (even in a curve) you would end up with 0 remainder once you reached the origin - so long as you always add the remainder to each calculation.


Finally, as you can increase the scale the little jogs or variance between the steps becomes progressively less noticeable.  The key is to carry and the then re-add that remainder so you always end up where you planned without a big jump at the end.


1 person likes this

Matt,

The progress is promising. A more typical Stage/HOW sample might be helpful, but the dramatic moves are probably more useful for diagnosing what doesn't quite work.


Of course I'm not aware of the details of the motor limitations, but I presume it has to do with the precision of the steps.  Let me share some ideas based on programming work I did decades ago "sketching" house diagrams on an 80x24 unix terminal.  I don't know, but maybe it will help.


For each axis, identify the low-limit, the high-limit, and the step precision available.


Calculate a scale based on how far you need to move(or what fits within the limits).

If the scale varies between the various axis, choose the smallest scale and apply to all axis math going forward.


For the first "step", divide the distance desired by the scale.  Store the rounded integer component of the result in one field (this is how far we will move this time). Add the remainder (positive or negative decimal) to a carrying field for that axis.  The key is to apply the lost precision to the future movements.


For each additional step, divide the distance by the scale again, but  add the carrying remainder field before rounding.  Move the integer amount, but calculate a new offset based on the ongoing remainder.


In my case, as we measure around a house we always end up where we started, and addition of the remainder to each step (plus or minus) ensures all lost precision is spread across the intervening movements and not left to the end.


Now I wasn't dealing with speed, but perhaps you can apply a T (Time delay) variable to the XYZ movements a carry a similar remainder/offset for the fourth dimension.


If you would like to discuss this directly by phone, don't hesitate to reach out.

Hi Tom,


Thank you very much for your feedback.


Speed control is handled as a minimum and maximum range, what you are currently seeing is the slowest options available for the movements requested.


The video with the larger movement is moving approximately 200 degrees horizontally from point A to point B


If I were to make another video showcasing objects in closer proximity, as one might find on a stage, the motion is noticeably slower due to the difference in position requested.


If this is of interest let me know and I can generate a new video this week.


While the math as has been described in this thread is rather easy to implement into a function it is not so easy to make affordable motors perform as well as that function.


Currently due to hardware limitations of our more affordable motors, when compared to the models linked in the video, we are unable to perform at that same level for now.


We are working on ways to improve the smoothing that should allow for finer control in future releases.


Our current goal is to provide "better" movement and with time to perfect this movement.


Please keep the feedback coming as it all goes into my development notes :-)




3 people like this

It seems that the primary purpose of tri-synchronous motion is to be able to stay "live" on the camera while the motion is happening.  If that is indeed the case then the speeds probably need to be slowed down significantly.  If the image is blurry and moving 100 miles an hour, it really isn't going to matter if you're going directly there or not.  If the zoom speed is the limiting factor, then you probably should slow down all the other servo motors so they don't arrive before the zoom is finished.  Whichever axis is going to take the longest to reach it's final position should drive the speeds of all other axis.


Here are two examples of tri-synchronous motion in another vendor's camera:

More "shorter" movements with a short X movement causing the camera to revert to robotic style showcased at 19 seconds into the video.

mp4

"Beautiful" Long sweeping Motion Sync

mp4
Login to post a comment