![]() |
|
|
|
|
|
||||||||||
|
| User list | Rules | You are not logged in.
I am open to whatever people wish, encoders are great and you can use dc motors instead of steppers. Servo systems are a little more complicated but the closed loop makes it better. Encoders like these http://www.usdigital.com/products/encod … ry/kit/e5/ can be put on the actual axis but controlling the servo motor using an encoder as feedback is beyond my knowledge. This also eliminates backlash error since it is reading the actual position. With quadrature reading you can get down to 0.072 degrees of resolution. These chips http://www.usdigital.com/products/interfaces/ics may be what are needed to interface the encoders to the Arduino. Like I say I'm the mechanical guy and you people are the software and electronics experts. One thing I would like to try and do is see how much off the shelf stuff we can use on this, the advantage of steppers is there are boards available that work with the Arduino. I haven't seen boards for encoders but they might be out there.
Last edited by Greg Nuspel (2009-10-09 00:50:31)
Offline
Arduino is just an avr with a different programming interface.
I use avr directly. Better control. But none are really multithreaded as they do not have an actual os.
I usually use protothreads though which is just a fancy switch method.
By adding ascii you are adding another layer of interpretation to the i/o.
Not only does the data have to be converted, but the results have to be range/sanity checked too.
I like to work in the µs range of lag/responsetimes not the seconds...
Offline
Also, I'd rather use a encoder with a stepper. It allows you to control accelleration much better than with a dc motor.
Not that much harder to control. In fact, parts are easier. DC motors do not provide holding-torque.
Here's a newer video of the pan/tilt btw.
http://www.youtube.com/watch?v=-Yu6nDVvPyA
The accell/decell works nicely now.
I am still drawing on the v3 board that will handle microstepping.
It's also the one I will put bluetooth in. Will still keep the µSD card though as it's great to be able to use it stand-alone.
I think I'll also add some sort of RTC so the logs and images dates and times match up.
Offline
We need to decide what type of motor are we going to use dc or stepper, if there will be encoders or not. If dc motors are used we can use standard rc servos with the electronics removed, backlash will always be an issue, but we can overshoot in reverse and always drive in one direction to the final position. RC servos and steppers also have the advantage of a standard footprint while dc motors come in all sizes and mounting configurations. I have to build the parts to some standard, custom brackets make everything too expensive.
I will leave what is best in the programing to the experts.
Offline
The easiest way to go is definitly servo-motors, like the ones Phil Warner used for its Panoduino. But they are not very accurate, unless you move the feedback potentiometer on the output shaft (but it will require some electronic modifications). The other issue is the lack of read-back position. Both problems can be solved by adding a simple incremental encoder on the output shaft, and make a second closed loop over the servo one.
Another solution is using DC motors, and incremental encoders on output shatfs: very accurate, but DC motors are not easy to drive, especially if the load changes. We should avoid this solution.
Then, stepper motors. They are very easy to use, as encoders are not needed with a good design (we must be sure that the load do not exceed motor capabilities, or there will be lost steps). Adding encoders over stepper motors is a little bit overkill. The issue with stepper motors is the current needed. They are also bigger
Phil is working on a servo-based panohead, with modified servos; but I don't know what he did so long.
What could be don is using standard servo-motors, with or without feedback encoders, depending on what you plan to do with the head. People shooting only spherical definitly dont need encoder, while high-resolution panos need them. If the mechanical design can receivre both solution as an option, it would be great.
As far as I remember, the Arduino can drive servo-motors without any additional electronic. you will only need it if you use encoders. In fact, without encoders, I would only use a polulu controller, which provide a ready-to-shoot solution.
KreAture, about ascii protocol, I don't think it is a problem with something like Arduino; you use high level routines which allow decoding strings very easily; binary protocols are not human readable, and should be avoided unless yo really need it (for speed or so, which is not the case here).
Offline
Maby you are right. I just hate the extra code.
It takes up space and makes me use more expensive chips.
Offline
Servo motors sounds like the best solution. Optional encoders are easy to implement and actually is not that big of an expense when considering the cost of most good photographic equipment. I have found the following sites on servo controllers:
http://elm-chan.org/works/smc/report_e.html
http://www.uhu-servo.de/servo_en/index.htm
http://members.shaw.ca/swstuff/dspic-servo.html
The last one actually has a board layout and would be easy to get made. The other two look interesting as well.
Even if the Arduino is overkill for standard RC servo I think it would be best to standardize on this unit since it is reasonably priced and is available with a built in USB interface, but most importantly I ordered one yesterday ![]()
Offline
I made a servo based unit first. It sucked.
That is why I went with steppers. I used large digital servos first time.
Offline
Saw the last site there. When I hear servo I think RC and such. Those are industrial servos and motors. HUGE difference (in size and quality, not to mention cost.)
Then they are bigger than steppers again...
Offline
I have RC servos in my mind, because they are cheap. But I agree that they can't be used as it for high-res panos; only for spherical.
Offline
Servo motors can be smaller, you can take the electronics out of a RC servo and install an encoder on the output shaft. Better is to get a gearhead motor and put an encoder on the rear shaft of the motor. This will give you very fine resolution and good control. You can either use a backlash value or always drive to the final holding point from one direction. The second option isn't acceptable on cnc equipment but for a camera mount it wouldn't mater unless you are trying to do panning with a video camera.
A motor like this http://www.robotshop.ca/lynxmotion-ghm- … motor.html with the encoder http://www.robotshop.ca/lynxmotion-qme- … der-1.html will give you a 0.00225 degree resolution in full quadrature. With a 2:1 final drive.
Last edited by Greg Nuspel (2009-10-09 18:15:18)
Offline
Phil used these servos:
http://www.servocity.com/html/spg785_pan.html
Offline
With this controller http://www.robotshop.ca/solutions-cubed … dge-2.html the total for two axis is $136.40 CDN about $130.00 US. Two of the servos from Servo City cost you $171.88 US. The encoder driven motors would be much better as far as positioning is. I have sent out emails to two of the servo controllers to see if they think their units will be usable for our low power system. The final output of course would use small mosfets but they have solved the problems of tuning the controller to the motor. My favourite is http://elm-chan.org/works/smc/report_e.html. The one unit is setup for just step and direction inputs and I thought we`d be aiming for goto xxxx position.
Offline
Oops made a mistake on the controller, you would need two of these. There are many other options like http://www.robotshop.ca/pololu-dual-mot … er-9a.html and all this is from one supplier.
Offline
Why not this one (adapted to the Arduino and ready for the 3 different types of motors ...)
http://www.robotshop.ca/adafruit-motor- … ino-1.html
Last edited by claudevh (2009-10-09 19:03:42)
Offline
The motor has a 3.6A stalled current draw. I'm not sure how high the current would go during a move, it could be safe I just wanted to error on the side of safety. These would only be needed if we use the Arduino to read the encoders, if we use another unit for reading the encoders and driving the motors we wouldn't need this. The Arduino would only be communicating to the 'servo' boards and coordinating everything. We might look at up loading complete move sequences so that you could start the device and leave the room/area as it shoots.
Offline
I have been chatting with Lawrence about his controller and he figures he can get something working for us if I send him a motor to test. It looks like it could be a real good option. So I am going to risk it and order two motors with encoders and see what he can do for us.
Offline
I used two of theese:
http://www.sparkfun.com/commerce/produc … ts_id=9238
And I used a set of pinions/gears for a big model helicopter as that was the only thing available to me at the time.
It only gave me about 8:1 gearing but the mesh is very tight giving no backlash or slop.
Ideally I'd like 20:1 or 50:1 but you can't get gears or belt/pully sets with so high ratio on one stage.
Using those motors with proper gearing and with some optical endstop detectors you'd be able to run to an end and know where the cam is after startup.
Then you would have a system of motors for $35 (2x $15 for motors and $5 for endstop detectors.)
I am running a ATmega64 on a board with about $10 in FET's and plan to use the $20 bluetooth dongle for communication and possibly with a $4 FT232R USB-serial chip to provide a wired alternative to bluetooth.
The ATmega64 can run 32 kHz pwm at 8 bit with 16 MHz external xtal, or 16 Khz pwm with internal 8 MHz oscillator.
That gives me 256 levels of pwm for use with microstepping using vector type control.
Offline
Small backlash in gearbox is the main issue: very difficult - so very expensive. And the more you increase the ratio, the more your panohead will turn slowly : don't forget that stepper motors are made to turn at low speed: as soon as you increase it, the tork falls down very quiclky, especially under low voltage. This is where DC motors are better.
Another way could be to use brushless motors, made for model cars. I don't know if they build some with internal encoders and all the electronic to work as servos (with closed loop control)... Brushlees can have very high tork at high speed.
Offline
KreAture wrote:
Ideally I'd like 20:1 or 50:1 but you can't get gears or belt/pully sets with so high ratio on one stage.
Why would you like 20:1 or 50:1.
With 10:1, you already got 1.8/10=0.18° angle precision.
isn't enough ?
May be for increasing final torque ?
Offline
If I can give my opinion...
Servocity servo's like Panodino are very expensive + the fact that they are not able to turn more than 300 to 450° ... except with the new one's give for max 630 ° http://servocity.com/html/spg785a-4_5_s … arbox.html
When you analyse the Servocity system, they are only original modified servos, the main modifications are :
- Gearbox
- additional "precision" potentiometer
Thats nearly all ...
If we want to use Servo's, I would suggest to have a look on servos dedicated to "Sailing RC model's" who are able to turn more than 360 ° or in continuous rotation like the HS-785HB ( 3,5 turns = 1260 °):
http://www.hitecrcd.com/servos/show?name=HS-785HB
This servo is used by Servocity into his new "SPG785A-4.5 Servo Gearbox"
The same type exist by Futaba... but less interesting and more expensive ...
i.e. http://servocity.com/html/s5801_sail_winch.html
Continuous rotation servo's also exist (Factory made) like HSR-1425CR (Continuous Rotation)
If we add a "encoder" to those servo's we can have a really very "high", "acurate", "reproductible" and "cheap" solution !
My last meaning is "if we can't reach a reasonable cost of such a system, the success will be very limited !" and we will never have the same interest like we have with PapyMerlin ! ![]()
I suggest also that we create a new "Poll" outside the present one ... ![]()
Last edited by claudevh (2009-10-10 12:01:19)
Offline
Hi all,
I forget the most important thing, MONEY ... ![]()
I thing that we have "big interest" to put a "TARGET" cost otherways we will continue to dream ... ![]()
My personal proposal is to fix a MAX target of "250 Euros = 375 $" - MIN target of "200 Euros = 300 $"
This is only a proposal and we can rapidly calculate if this is too optimistic or not !
Fixing a "accepted by all" target will avoid dreaming, waste of time and more important will induce "CREATIVITY" ![]()
I propose also to Fréderic to put a "sticky" specific topic with this target cost on top of the poll ... just as permanent remind ...
Offline
The main advantage of the Servocity servos is that they are very strong, and do not need additional balls bearing on the rotation shaft, or complex mechanical design (look at Phil Panoduino head), so a head can be build without the need of heavy tools.
What you suggest is to use servos as simple DC motors (but with the driver embedded). That's another way to go. And as Greg is able to make a good machnical design, this solution seems to be the best. The Arduino board will just require a little PCB with the encoder ship, as it can already drive the servo. Then the firmware will have to implement a PID regulation (or fuzzy logic, for fun).
Offline
claudevh wrote:
I propose also to Fréderic to put a "sticky" specific topic with this target cost on top of the poll ... just as permanent remind ...
It is already in the Main and usefull topics topic, which contains imortant posts.
Offline
claudevh wrote:
My personal proposal is to fix a MAX target of "250 Euros = 375 $" - MIN target of "200 Euros = 300 $"
Waow, target is quite low! Compared to NN MKII RD8 (310€) or a NN MKII RD16 (360€) which is quite more expensive would give less than a fully motorised pano head.
At this price, I should stop right now all my developements (or dreams
) and would be the first interested. ![]()
Last edited by kalain (2009-10-10 12:59:31)
Offline
Powered by PunBB
© Copyright 2002–2005 Rickard Andersson
|
CHOOSING KOLOR Why choose Kolor? Which solution to choose? Download a trial Where can I buy? Education |
SOFTWARE Autopano Pro Autopano Giga Panotour Panotour Pro XnView |
ACCESSORIES Training DVD Panobook PROJECTS Paris 26 Gigapixels Yosemite 17 Gigapixels |
COMMUNITY Forums YouTube channel Google+ |
COMPANY Blog About Kolor Resellers Contact Visit us |
PRESS Press center Press review TOOLS My account |
