Developing a new controller, Papywizard compatible

[klausesser]

by klausesser » Tue Feb 02, 2010 11:57 am

And no, I don't manage the backlash. Be aware that it is not that simple, and mainly depends on the load. For example, on the pitch axis, you don't know if the load will put the backlash on the up direction, or on the down direction, depending how the camera/lens is balanced... The wind can also be a nice trap for the yaw axis

Hey Frédéric!

Yes - that´s a vital point. I suggest to keep the counter-screws (?) tightened - and not to move the head by hand.
I check that frequently - and have no problems regarding precision any more.

best to you, Klaus

[fma38]

by fma38 » Tue Feb 02, 2010 12:30 pm

Yes, but you can't do anything if there is some backlash in the gearbox; every direction change will loose a few degres before the gears are again in contact...

[panoguy]

by panoguy » Tue Feb 02, 2010 2:09 pm

And no, I don't manage the backlash. Be aware that it is not that simple, and mainly depends on the load. For example, on the pitch axis, you don't know if the load will put the backlash on the up direction, or on the down direction, depending how the camera/lens is balanced... The wind can also be a nice trap for the yaw axis

Hey Frédéric!

Yes - that´s a vital point. I suggest to keep the counter-screws (?) tightened - and not to move the head by hand.
I check that frequently - and have no problems regarding precision any more.

best to you, Klaus

And here we are, in that case I'm sure the Merlin compensates the backlash internally, as I expect such a low cost gear has at least 1.5° backlash.
I don't have a Merlin, but maybe one can confirm how far can you turn the head manually, before the encoder starts to rotate. You have to do this test in both directions.

Yes, but you can't do anything if there is some backlash in the gearbox; every direction change will loose a few degres before the gears are again in contact...

Sure you could, but seems you don't have to in this case.
The only thing you need to know is the backlash in ° and then you add additional steps to the first goto command when ever the direction of the head is changing. This practice is used even in CNC machines.

[Paul]

by Paul » Tue Feb 02, 2010 8:43 pm

may be interesting for simultaneous axis movement:
some people are working on multithreading on arduino-µcs

more infos: http://concurrency.cc/ and http://href.to/zJ5

[klausesser]

by klausesser » Tue Feb 02, 2010 9:52 pm

And here we are, in that case I'm sure the Merlin compensates the backlash internally, as I expect such a low cost gear has at least 1.5° backlash.
I don't have a Merlin, but maybe one can confirm how far can you turn the head manually, before the encoder starts to rotate. You have to do this test in both directions.

The very moment you move one of the head´s axis the encoders rotate. There´s no visible dead-time: it´s fixed at the gear´s axis.
Generally the precision seems to be very sufficient - it´s covered by the overlap of 25/30% anyway.

I use a 300mm sometimes - very narrow steps in portrait-mode. No problems so far.

best, Klaus

[panoguy]

by panoguy » Wed Feb 03, 2010 6:07 am

And here we are, in that case I'm sure the Merlin compensates the backlash internally, as I expect such a low cost gear has at least 1.5° backlash.
I don't have a Merlin, but maybe one can confirm how far can you turn the head manually, before the encoder starts to rotate. You have to do this test in both directions.

The very moment you move one of the head´s axis the encoders rotate. There´s no visible dead-time: it´s fixed at the gear´s axis.
Generally the precision seems to be very sufficient - it´s covered by the overlap of 25/30% anyway.

I use a 300mm sometimes - very narrow steps in portrait-mode. No problems so far.

best, Klaus

Klaus, maybe this was`t the best advise to test the backlash, if it is not noticeable that's fine but I still believe that such a low cost gearbox which it is used in this device has high backlash. I did study a lot of gearbox documentation prior starting this project and if you search for a low backlash gear you will pay the price of a DSLR and I'm not even talking about backlash free gears.
If you want to measure it correctly check out this article:
http://www.neugartusa.com/Service/faq/Gear%20Backlash.pdf

Nevertheless you are right, it may not be an issue with 300mm and 30% overlap. At this lens the moving angle is around 3.8° and if you "loose" 1° it is not an issue. Anyway you won't loose anything,
you gain 1° additional overlap at the beginning of each row between the first and second picture
and the last picture of the next row would end 1° shifted to the previous row.

But you could do this test with a 300mm lens and shoot a simple 4x4 or 6x6 mosaic and a plane front of a building.
If you don't see and shift between the first and last picture of the consecutive row then you have got a backlash free gear or the internal firmware does compensate it. The second option you usually get for free as it is very easy to implement.
Also I didn't want to start a theoretical discussion about backlash, but only clarify if papywizard or the internal firmware should compensate the existing backlash.

[Paul]

by Paul » Wed Feb 03, 2010 8:29 am

there is an easy way to visualize Merlins backlash

just define some driving patterns different in motion per axis
- steady going
- zig zaging

mount a laser pointer on Merlin bracket and do a long time exposure with a fixed cam while running the pattern

Merlins backlash is partly compensated via the inertia of the slipping clutch

[Greg Nuspel]

by Greg Nuspel » Wed Feb 03, 2010 12:18 pm

If you want to visualize backlash attach a laser pointer to your unit. Project this against a wall and you can see the amount of backlash easily.

[fma38]

by fma38 » Wed Feb 03, 2010 12:36 pm

I used a tele-lens, and glued some millimetered-paper on the wall... Very accurate! Then, atan() is your friend...

[panoguy]

by panoguy » Wed Feb 03, 2010 3:36 pm

Ok, here is a first version. Just put it in your plugins dir:
linux: ~/.config/papywizard2/plugins:
windows: C:\Documents and settings\<user>\Application Data\papywizard2\plugins\

Just got my first N800 and managed to install Papywizard.
The only thing I did not find in hurry, where do I have to copy the plugin on the N800 ?

I just read the documentation and I guess I found it /home/user/.config/papywizard2/plugins

Last edited by panoguy on Wed Feb 03, 2010 3:51 pm, edited 1 time in total.

[mediavets]

by mediavets » Wed Feb 03, 2010 4:37 pm

Ok, here is a first version. Just put it in your plugins dir:
linux: ~/.config/papywizard2/plugins:
windows: C:\Documents and settings\<user>\Application Data\papywizard2\plugins\

Just got my first N800 and managed to install Papywizard.
The only thing I did not find in hurry, where do I have to copy the plugin on the N800 ?

I just read the documentation and I guess I found it /home/user/.config/papywizard2/plugins

I installed the latest dev. version - 2.1.15-1 - this morning and it seems to include a 'panoguy' plugin:
http://www.papywizard.org/wiki/Download#Developementversions

Which version did you install?

[fma38]

by fma38 » Wed Feb 03, 2010 4:39 pm

Panogy, this is the correct path. But try the 2.1.15 release. As Andrew said, the plugin in now included.

[panoguy]

by panoguy » Wed Feb 03, 2010 4:53 pm

Panogy, this is the correct path. But try the 2.1.15 release. As Andrew said, the plugin in now included.

Wow, Thank you, Frederic you always exceed my expectations...

Yes sure, I did install the latest version now ;-)
But how do I replace the plugin if I need to change anything?
For some reason the connection is not working with the included plugin, it fails on axis 1.
I made a copy of the 'old' plugin and saved it under a new name. With that plugin the connection works fine, but I can't open the Shoot window.

Is there and difference in the new plugin?

Last edited by panoguy on Wed Feb 03, 2010 4:54 pm, edited 1 time in total.

[fma38]

by fma38 » Wed Feb 03, 2010 4:58 pm

There should not be any difference. Can you send me your version?

If you want to use yours, put it in your config plugins/ dir, as you did before, and change its name (NAME = "Panoguy" at the begining of the file). So you will get both in the menu...

Can you also send me the logs when it fails (for both cases)?

[panoguy]

by panoguy » Wed Feb 03, 2010 7:00 pm

There should not be any difference. Can you send me your version?
Can you also send me the logs when it fails (for both cases)?

Ok thank you, have send you an PM, is there a way to attach a file? I pasted all into the message body ...

[fma38]

by fma38 » Wed Feb 03, 2010 11:28 pm

You can post code using the 'post' tag, but it is better to send it in private, as you did, if it does not concern everybody. I will have a look at it tomorrow.

Do I rename it Gpb? What does it stand for?

[panoguy]

by panoguy » Thu Feb 04, 2010 8:40 am

Good Morning,
If you don't mind, you can name it GigaPanBot

[fma38]

by fma38 » Thu Feb 04, 2010 10:23 am

Ok, no problem! I will also update the title of this topic...

[Paul]

by Paul » Thu Feb 04, 2010 11:03 am

just to inform you:

Gigapanbot is already in use by Traugott Emrich for his pano robot

see:
gigapanbot.com gigapanbot.de

IMO you should not kidnap his name but find another pretty one

Last edited by Paul on Thu Feb 04, 2010 11:03 am, edited 1 time in total.

[fma38]

by fma38 » Thu Feb 04, 2010 11:11 am

Right!

[klausesser]

by klausesser » Thu Feb 04, 2010 12:14 pm

Gigapanbot is already in use by Traugott Emrich for his pano robot

Maybe it IS Traugot!?

best, Klaus

[panoguy]

by panoguy » Thu Feb 04, 2010 2:50 pm

Hi all, yes it's me again.
due to dropped email id I had to startup with a new account.

[panoguy]

by panoguy » Fri Feb 05, 2010 4:50 pm

Hi Frédéric
your last advise was very helpful:

The additional LF may cause some problems. Is it possible for you to only send CR?

I have changed the code to send a CR only at EOL instead of CR / LF (which is the default as long it is not suppressed).
Papywizard connects fine now and the communication handshake is much better.
The timeout and retry parameters also works fine and it looks much more promising now.
Will need to test some more details during the weekend ...

[fma38]

by fma38 » Fri Feb 05, 2010 6:06 pm

Good!

[panoguy]

by panoguy » Thu Feb 11, 2010 11:48 pm

Gigapanbot plugin description

The plugin is a simplified version of the Merin/Orion protocol as described on the developer page: http://www.papywizard.org/wiki/DevelopGuide
It uses a simple asynchronous, ASCII serial protocol.

All commands are always initiated by the master (Papywizard).
The controller of the Gigapanbot waits for incoming commands from the master and sends back a response to the last received command.
The slave controller could be busy with other tasks and in some circumstances not able to respond immediately to a command from the master.
In case the master does not receive a valid response from the slave, the master will repeat the last command for a predefined number of retries. The timeout value and the number of retries can be set in Papywizard, Hardware/Plugins communication tab.

There are 3 important parameters which controls the position and the movement of the motors.
1. The value of the encoder position at initial startup is set to 8388608 (this value is send to the master as HEX value = 800000)
2. The encoder or stepper motor (steps) the head will count for one 360° turn.
3. As we can have different encoders or gear types, the second parameter could be different for the tilt axis and the pan axis.

All commands send by the master starts with ':', and ends with '\r' (in Windows this is a CR only, no Line Feed)
The head controller response always starts with '=', and ends with '\r'. (CR only)

This is the structure of the protocol:
1. the first character is the command
2. the second character is the axis number, it is mandatory, 1=yaw, 2=pitch axis
3. the next characters (up to 6) are used only for some commands and are send as HEX value, optional but mandatory for some commands

Valid commands are:
j<axis> read axis position, return is a 6 char HEX value
f<axis> read axis status, return is 0=ready or 1=busy
L<axis> stop motors,
a<axis> get encoder count (steps) needed for a 360° turn, value is 6 char HEX value

G<axis><direction> Start moving to left or right, 0=increments (up/right), 1=decrements (down/left), this command is used to manually turn the head into a initial position.

I<axis><speed> Set motor speed, 3 possible dec values 0,2,4 (0=high speed, 2=medium speed, 4=slow speed)

S<axis><position> Drive to position, the position value is again a HEX value (ie. 8000A0) This command moves the head from his actual position (j encoder value) to the requested position.
For example if your head is at the initial zero position (HEX 800000) and receives a request to move to new position 8000A0, it will turn the stepper motor by exactly 160 steps to the right.

O<axis><state> Release camera, Shutter on axis=1, Autofocus on axis=2, ON state=1, Off state=0

e<axis> ask firmware version during first connect, max 6 char

F<axis><state> Connection status, state 0=not connected, 1=connected. The command is used to maintain the connection status at the slave controller.

Following (Merlin) commands are not used by now:
D not used
J not used

Last edited by panoguy on Mon Feb 15, 2010 9:59 pm, edited 1 time in total.