Building a new Merlin/Orion internal controller  

Everything you need to motorize your head
User avatar
panoguy
Member
 
Posts: 106
Likes: 1 post
Liked in: 0 post
Joined: Mon Jan 25, 2010 3:55 am
Location: Bavaria
Info

by panoguy » Thu Feb 11, 2010 5:27 pm

odyssey wrote:One question is how do these current units report when you have gone past 360 degrees of rotation, and is it currently possible to ask for say '420 degrees'? Going past 360 is not important for stargazing, but it is for greater than 360 degree panoramas [i](overlap, looping past start point, timelapse stuff).
Jason

This is just a matter of hardware limitation and of course you can limit it in your software by purpose or accident.
Initially my 0 position was defined as 0 and I was counting the steps up or down, so I ended up in negative numbers. Which was not a problem until I wanted to implement this additional feature to be able to control the head via Papywizard.
Setting the 0 position somewhere in the 'middle' of the size of the data type you are using makes sense, but you may reach some data type limitations. On the other hand it is easier to handle a positive number only.
I changed my code and set the 0 position to 800000 hex. I do not use encoders but stepper motors and depending on the gear ratio, I can turn the head at least 50 turns before overflow.
odyssey wrote:Is there really an advantage to using 6-byte-hex high byte first in reporting axis positions versus just an integer, or is this just left over from the Orion controller and is it time to move on? (I can do it that way but for bus sniffing the serial port I would just assume have something my mind can instantly understand, I understand the value of not passing around floats, but what about a multiplier like 3600 which would include the 1/10th degree accuracy {these encoders actually have far to many ticks compared to gear precision})
Jason

I did not really understand the logic behind the shift of LSB and MSB bit, but sending Hex values makes sense for this large numbers as you can save some time in the communication protocol. Which I learned is very time critical ;-)
Converting dec to hex is not a big deal, so I adapted this in my protocol too.
Initially I did not expect Frederic would be so fast in developing a new plugin, and I tried to remain compatible with Merlin protocol. Which works in some cases but in some it did not work at all.

As I also mentioned to Frédéric, the intention was to have a simple protocol which could be used for any new controller and in the end it makes no difference for the protocol which hardware sits behind.
I will document the protocol and the logic behind my sub program as soon I get some time and publish it here.

User avatar
claudevh
Moderator
 
Posts: 1349
Likes: 0 post
Liked in: 0 post
Joined: Sun Nov 25, 2007 11:12 pm
Location: Mont-Saint-André (Belgium)
Info

by claudevh » Fri Feb 12, 2010 11:27 pm

Hello "odyssey",

The time for one 360 ° by the Merlin head is +/- 50 seconds without stops ...
Your 2 RPM will allready be a "real" improvement :)
:cool: Claude :cool:
Merlin + Papywizard on Windows 7 & Nokia 770 § N810 & Acer (Netbook) + PanoramaApp Androïd + Deltawave PapyMerlin BT + Autopano
Spherical Pano (180 x 360) with Canon 40D + Canon EF-S 10-22mm f/3.5-4.5 Zoom & Pôle Pano with Canon 5D MK2 and shaved Tokina 10-17 3.5-4.5 AF DX Fisheye
Gigapixel photography with Nikon D200 + Sigma 70-200 F 2.8 EX DG APO HSM

no avatar
shutterdrone
Member
 
Posts: 16
Likes: 0 post
Liked in: 0 post
Joined: Tue Feb 16, 2010 8:26 pm
Info

by shutterdrone » Wed Feb 17, 2010 11:26 pm

Hey guys, just chiming in here as I recently hopped on the forums, and it looks like y'all are working on something which I've had a bit of experience with *grin* (not pano, but the motion head software/engine).

If you're interested, I have a fully functioning arduino engine for steppers, which could easily be adapted to use pwm control - but I can talk about how I handled a few of the problems you mentioned.

First, about travel, direction, etc. I recorded two different values for each motor:

1) How many total steps it had taken during execution (needed for keyframes/actions) - just replace steps with 'encoder pulses' -- in this case, I used an unsigned long - making it, erm, billions of steps/pulses. (A whole lot of revolutions on my 192,000 steps/rev setup)

2) How many steps, and in which direction, from a reference point. For me, I use a reference point called 'home'. You track which the distance using a simple signed integer, negative means you have that many steps to go in the '0' direction to get back to home, and positive means that many steps in the '1' direction. I just add or decrement this counter every time I move. I saw that was referenced to above in an earlier statement about 180/0/-180 position.

It's important, unless you have reference switches, to note that 'degree of position' is meaningless with encoders unless your encoder has a reference line. Otherwise, all positions are relative to where you first started recording them. I'm not sure if you're trying to pick a position absolute in the physical world, or relative to where your sequence begins and ends... I'm also not sure that enlightening me would help y'all all that much so no worries there. =)

One thing I've experienced with serial protocols (been using UART and i2c for a few years now), is that adding a bunch more data ON TOP of the underlying protocol does not necessarily make any more of an effective encapsulation these days. Remember that the protocol is already encapsulated when using UART. So, you can add a known sixty-byte header to every command/response, and in the end you'll only increase your rate of errors and slow down data transmission. It's important to have a reasonable protocol and response situation, but truth be told - once you start getting errors, you're going to keep getting them until you eliminate the cause (usually environmental). I've chosen to forgo lengthy headers for simple sequences of known results (say, a NOOP command that returns no data, and therefore should have just 2 bytes in the buffer, each having this value).

If you need help writing the serial protocol in the arduino, let me know. I have a pretty extensive example in play already that shows a multi-layered protocol with write and read methods, supporting straight binary data (converting to ascii and back is such a waste of memory and cpu!), including setting individual bit flags in values, transporting floats (*grin*), and a client lib in perl (easy to see the templates to use in python for the same sort of protocol). This might help: http://openmoco.svn.sourceforge.net/viewvc/openmoco/OpenMocoComponents/TimeLapseEngine/branches/release-0.82/OpenMoco_Timelapse_Engine/OM_Serial_Com_Client.pde?view=markup

!c

User avatar
fma38
Moderator
 
Topic author
Posts: 5850
Likes: 2 posts
Liked in: 2 posts
Joined: Wed Dec 07, 2005 6:21 pm
Location: Grenoble, France
Info

by fma38 » Wed Feb 17, 2010 11:57 pm

Thanks for the tips! On the Papywizard side, it does not matter which kind of protocol us used: binary is as easy to handle as ascii; the last is just easier to debug using sniffer or so, but I agree it is not mandatory.
Frédéric

no avatar
shutterdrone
Member
 
Posts: 16
Likes: 0 post
Liked in: 0 post
Joined: Tue Feb 16, 2010 8:26 pm
Info

by shutterdrone » Thu Feb 18, 2010 12:52 am

Glad to help in any way I can =)

BTW, there's one minor mistake on my part - when I said "the protocol is already encapsulated," I presumed you're using the boards with FTDI driver. Looks like y'all might not be, and instead are using straight uart over serial port. The FTDI uses USB protocol between the board and the computer, so in that case you've got CRC on every data packet. If you're not going through the FTDI, you will likely want to use a CRC algorithm, rather than a known header -as all a known header will tell you is that the header isn't broken, it doesn't tell you anything about the rest of the data =)

!c

no avatar
GuzZzt
Member
 
Posts: 30
Likes: 0 post
Liked in: 0 post
Joined: Mon Jun 29, 2009 11:17 am
Location: Borås, Sweden
Info

by GuzZzt » Wed Aug 04, 2010 6:57 am

I have been occupied with other projects for a while and have not had time this visit the forum but I think this is a great project. Have anyone also thought about replacing the motors and/or gearbox to improve th speed or is that not possible?

User avatar
panoguy
Member
 
Posts: 106
Likes: 1 post
Liked in: 0 post
Joined: Mon Jan 25, 2010 3:55 am
Location: Bavaria
Info

by panoguy » Sat Aug 07, 2010 10:07 am

Before replacing the motor/gear you better build something from scratch.
I don't think you will find a replacement that fits without modification, cheap, strong and fast enough...
I do also believe the motor can turn a little faster.

Previous

Who is online

Users browsing this forum: No registered users and 2 guests

cron