Mooting idea: hydraulic tracking mount.

[NickK]

I know hydraulics are a pain but they can deliver an exceptionally smooth transition unlike pneumatics which would suffer from bounce.

I've been attempting to source small components which will work at about 50psi. For example - you can get an electrically driven gear pump that provide oil for the turbos for racing drag bikes. These are 12V and operate at 50psi with a smooth delivery which would be more than enough for a telescope!

The pump and power pack can be placed a distance away from the mount with only the out and return pipes connected to the mount.

Deep sea subs use a bladder to even out the flow further - hydraulic fluid is an incompressible fluid so if the pump flow rate varies then the flow rate through the entire system would vary if it's not controlled.

How to control that pressure! Well there's three options here:

a) use electrically-operated variable ball (or gate) valves to control the flow rate (and thus the tracking rate). This results in a very analogue control over a small flow range.

use a set of electrically-operated on/off valves in parallel with different flow constrictions to provide different movement speeds. Open a small valve for a preset flow rate, open a large valve for a larger preset flow rate. This is very digital and works for a series of stepped larger flow ranges. The danger is that this square wave would cause telescope bounce or warping of the tube.

c) use a combination of a & b. If you want to move quickly then open a large bore on/off valve. When you want to move slowly then use a small ball valve.

A further switching valve can then define which direction the cylinder would move (simplifies the design). Naturally this could throw the telescope around as if it was a rag doll, so we would need to program the controller to be soft start & end using the ball valve. This would reduce the stresses. We may be able to use a single flow controller for both cylinders to reduce cost.

Next up - pistons. Small pistons are rather rare too but both realistic model makers use these however I think the best performance would be from large surface area cylinders. This would smooth out the pressure further and would allow very accurate transitions.

Why pistons? Well you can get rotary actuators but the majority are rack and pin with pistons moving the rack. Some are finned. We're attempting to get away from errors caused by gaps between the gears/worm or rack. So it's possible to make a plate and attach a couple of pistons to it - the axis drives the scope. With a controller it's possible compensate for flow rates to provide a smooth transition.

So, in theory, it's possible to maintain a constant flow to provide constant accurate tracking without gear error.

It's still possible to use encoders to provide an accurate feedback. If safety was an issue then putting a proximity sensor to kill movement (and a full pressure release button in case anything gets trapped).

As a controller - well there are so many options. You could use a basic microcontroller but another option is to directly couple a Blackfin 537 to a camera and then allow the blackfin to perform optical flow and feature tracking, control a set of servos to manipulate the valves and monitor the encoders. A single blackfin would be overkill for this but hey..

The blackfin boards I have are a bit over kill, each has an omni vision camera, 32MB RAM, 4MB EEPROM and a blackfin 537 (500MIPS).

Attach it to a MatchPort WiFi chip and you've got a 2Mbit connection for offloading images and control.

Hmm.. the ideas...

[Photosbykev]

If I were designing a hydraulic system I would go down the Master/Slave setup with the whole system pressurised on both sides of the piston. This would remove any backlash during changes of direction and smooth out the motion. Linear movement of the master cylinder could be driven by a stepper motor and could be scaled down and replicated by the actuator cylinder for the Ra movement. The biggest problem would be getting the range of Ra movement required, for a 6 hour run you would need 6 x 15 degrees = 90 degrees of movement, this would need a fairly long stroked cylinder coupled to an actuator arm.

From the Blackfin and Matchport reference it sounds like you have one of the small tracked vehicles with onboard vision that I have lol

[RustyM]

Hi Nick,

I think your onto a Great Idea.

The motion would be smooth, accurate and backlash free…like butter.

(I love Hydraulics....one of my favorite methods for moving stuff.)

Here is a bit of what I know of hydraulics and controls*.

Ramble Warning: I'm just going to brain dump. You might want to leave now.

Most of these notes go to "controllability" where many small errors can accumulate...often resulting in "uncontrollability" i.e. Tracking errors.

- Fluids are incompressible....mostly.

Hydraulic fluid will have ~2-3% entrained air that will give cylinders a very small bit of "softness". Obviously this becomes more pronounced has cylinder volume increases but it is always there. Hoses, pipes and plumbing all expand and contract as a function of temperature and pressure...all adding a bit more softness to the actuator.

- Cylinders have slip-stick and they leak internally (by design).

Cylinder pistons must both move and provide a seal between the rod and cap ends of the cylinder. In moving, a thin film of fluid must be allowed around the seal as a lubricant or the seal, O-rings, will be destroyed. In sealing, a tight fit is required to prevent pressure passing from one end of the cylinder to the other. Bit of a Catch-22. Some amount of “break-away” force will always be required to overcome the outward pressure of the piston-seal-cylinder relationship. For slow, smooth motion it is very important that the break-away force not be much greater than the force required to move the piston once in motion. Large force deltas will cause start/stop stuttering at low speeds and limit the minimum controllable speed of the actuator. Keeping the force delta low is a function of outward seal pressure…low outward pressure gives a lower minimum speed but also allows more pressure across the seal which adds more softness to the actuator…fun, fun. Oh…don’t forget the rod end seal….it has the same effect on performance…more fun.

- Fluid flow (volume) controls actuator velocity.

Flow is the control variable in hydraulic systems. Pressure and fluid velocity are seldom actively controlled, they are really just design parameters. This can be a little brain twisting….for example: Given a pump that supplies 1000psi to a valve that is used to control a 3” cylinder and a load of ~1413 lbs. then 200psi (1.5” x 1.5” x pi x psi) would be needed to move the load, therefore pressure in the cylinder would be 200psi. For the pressure in the cylinder to be 1000psi the load would need to be ~7068 lbs. i.e. You can only do as much work as there is work to do…no more, no less. So…what happens with the extra 800psi of energy the pump is producing ? It gets dumped via a pressure relief valve that is set at 1000psi (also producing heat and a bunch of noise).

Now here is the important bit: The valve controls flow by changing the size of an orifice between two ports: P for the pump side port and A for the cylinder side port. So we have 1000psi at P and 200psi at A. This give us a pressure across the valve, P - A, of 800psi (deltaP). It is the deltaP that determines the volume of fluid that will flow across a given orifice in a given amount of time… not the size of the orifice itself. Temperature induced fluid viscosity changes will also directly impact flow across a given orifice (as the night gets cooler less fluid will flow).

As the speed of the actuator is in direct proportion to this flow; Flow ends up being the primary control variable.

You’re killing me…why is this important ?

Good question….For the actuator to move the mount in RA a linkage will be required to translate the cylinders linear motion into an elliptical motion. This linkage translation will cause the load on the actuator to be constantly changing. When the load changes the deltaP changes. When the deltaP changes the flow across the valve changes. When the flow across the valve changes the speed of the actuator changes. So…If the actuator needs to travel at a precise rate and the load variations can never be zero: Control of the valve needs to be fine grained both in orifice sizing and frequency response. It will take very little load change for minor oscillations to develop…. Resulting in same type of tracking errors you get with gear driven systems.

If you like we can get into closed-loop control and the like at another time...

Assuming my insane ramblings don't get me excommunicated first.

Ramble Off

The BlackFin with a fast valve and high resolution position feedback should handle all but the most glaring hydro-mechanical issues with ease....Probably run multiple rigs, handle temperature control and make coffee (or tea) without breaking a sweat.

Again, Great Idea. I'd love to assist in anyway you like.

Rusty.

*I design and build software and hardware for multi-axis motion control systems for the Theatre...Broadway, West End, Las Vegas… From 35ft tall, 60ft wing-span, 24-axis hydro-mechanical Dragons to single axis electric curtains controls. I can’t believe they pay me to play with the toys.

[NickK]

Thanks Rusty, taking in what you've said, it looks like I should be treating hydraulics in terms of force and loading (as if the pump is providing force and the valves providing an opposing force).

With a counter balance, the only force required is to overcome it's current state of equilibrium and then continue moving (still requires power) and then finally the amount of force required to bring the scope to a stop.

The impact I see on this is that the valves available would have to provide very small amounts of force (ie high deltaP) depending on the cylinder and radius where it's attached.

I think the sticking point would be a challenge although I think this may be more of a problem on initial start/stop, however on a continuous track the telescope's own momentum may help (although this drag would cause lack of smoothness).

I think the technique would work and it may be worth building a single axis to learn from. Load it with a dummy counterbalanced load and see what it can do.

I also see that the system would have to effectively learn a complete force mapping each time the setup is changed (ie changing equipment and if the scope is reattached differently).

I think this could be done as a startup test (whilst the scope is cooling down before viewing). The mount could perform a set of movements to gauge the initial loading and it's impact on tracking. It would still have to sweet tune and continuously alter based on the changing conditions in realtime.

I have an idea for providing a exceptionally hi res positional feedback, so I see that as the easier part. Optical mouse sensors provide high resolution optic flow analysis without contact. These can be used on the plate where the cylinders attach. Gaming mice can be up to track at 4000 per inch. How that translates into arc sensitivity depends on the distance from the centre of the plate. The natural grain of the metal would be enough to track against.

Also I wouldn't just use feedback on the mount itself for tracking - star tracking is really the only accurate way of doing it so it would have to have some feed back too.

Once again - thank you for your suggestions.

[Beyond_Vision]

Interesting idea but would changes in ambient temperature cause any issues?

Regards

Kevin

[NickK]

Interesting idea but would changes in ambient temperature cause any issues?

Yes. Temperature changes and the effects on the system would be factored in continuously. The hydraulic fluid temperature would vary due to the pump and valve pressure changes causing changes in temps too.

There's two ways to do this:

a) complex, measuring all the known variables to make a completely predictable system (way way way too many variables and things to sense).

super simple by understanding that there is a natural slow deviation and then compensate on the fly. As the system is simple the speed can be very quick to correct deviations. The problem is that you need to have a very precise measure of the result. You measure the delta Rate and compare against the expected (and desired delta). If the force is too high, reduce it a small amount. If it's too low then increase it.

When this simple logic is applied in rapid cycles causes the system to naturally solve itself. This places a requirement on how fast the valves can be altered (rate of change) and the speed of the program.

An initial calibration exercise would just allow the mount to have basic starting point. The down side is that the mount would not be good if it remained static (ie not tracking) for periods of time as the degree of error on starting to move would be slightly higher initially.

[Earl]

Can i chuck an idea in.

Make it a IP address controlled device with a nice 1gb network port.

[Earl]

Also there has to be fluids that don't change viscosity until super low temperatures.

lets face it you don't need to go below -20 for even the most hardy.

[NickK]

Interesting idea but would changes in ambient temperature cause any issues?

I was going to edit it but it locked out the post..

An initial calibration exercise would just allow the mount to have basic starting point. The down side is that the mount would not be good if it remained static (ie not tracking) for periods of time as the degree of error on starting to move would be slightly higher initially.

For example the initial calibration manoeuvre would be a slow inital min, max move to find the limits (have an optical switch for the limit of movement). Once we know those we know the position using the optical flow sensors to track movement velocity and time. This means we know the axis positions. This allows the system to measure the change in axis position given changes in the valves.

Next basic move would be to seek, slowly to the centre point and then perform a ever increasing spiral to get a good feel for the rate changes for the values.

There's another option for hydraulics which is to have a balanced pilot to allow fluid to circulate and movement comes from an imbalance in the forces (ie the push-pull Kev pointed out). This keeps the entire system at a similar temperature and helps reduce thermal errors (although it has balance drift if not accurate).

[NickK]

Can i chuck an idea in.

Make it a IP address controlled device with a nice 1gb network port.

The standard blackfin does do an interrupt driven ethernet port (although I think it's 100Mbit). However (for size reasons) the blackfin board I have doesn't break this out to the edge of the board. What the board has is a UART which can be connected to the matchport WiFi. The max speed is about 2Mbit.

It's possible to get other development boards with a full set of breakouts. However for now we can live with this limitation. The main communication would be commands and state info which should work fine on 2Mbit with a few tracking pictures for debug.

[HD-AP]

Hi nick

Just a thought ,if you look to the world of radio controlled jets their are small but very powerful hydraulic pumps cylinders and rams used for retract /undercarrige systems with electronic control built in.

regards

clive

[NickK]

Avionics are usually pneumatic due to weight. Stahl, who make scale trucks, sell hydraulics separately - this is where I thought I'd source the components if they're suitable.

The next step is to get a pen, paper and calculator and check out the forces required to make a design. Then I have a better idea of suitability.

[RustyM]

Yes. Temperature changes and the effects on the system would be factored in continuously. The hydraulic fluid temperature would vary due to the pump and valve pressure changes causing changes in temps too.

There's two ways to do this:

a) complex, measuring all the known variables to make a completely predictable system (way way way too many variables and things to sense).

super simple by understanding that there is a natural slow deviation and then compensate on the fly. As the system is simple the speed can be very quick to correct deviations. The problem is that you need to have a very precise measure of the result. You measure the delta Rate and compare against the expected (and desired delta). If the force is too high, reduce it a small amount. If it's too low then increase it.

When this simple logic is applied in rapid cycles causes the system to naturally solve itself. This places a requirement on how fast the valves can be altered (rate of change) and the speed of the program.

An initial calibration exercise would just allow the mount to have basic starting point. The down side is that the mount would not be good if it remained static (ie not tracking) for periods of time as the degree of error on starting to move would be slightly higher initially.

Nick....I love you, man.

Most see things in the exact opposite way. When there are many variables that should be considered....the number is always higher than you think....The usual approach is to try and reduce the variables considered and solve the reduced set. While this is perceived as simplifying the problem. In reality the excluded variables still exist and will bring complexities that can seldom be resolved. Your super-simple method is vastly superior terms of results and violently more simple in implementation.

The geek name for Nick's super-simple approach is: Closed-Loop.

Warning: Geek Ramble: On

Closed-loop motion control systems compensate for variables, like temperature, that introduce errors in how an actuator tracks a set-point....like position or velocity. Here's a classic example...

A long time ago auto makes hit on a great idea: Cruise Control. The first implementations used throttle position as the set-point value; held steady when the driver flipped the cruise switch. Cool...works...better than nothing on a long trip....sorta. There are some obvious problems with this "open-loop" solution...The actual speed of the vehicle changes with changes in conditions...hills, wind, temperature, etc. and it wasn't long before a six year old girl, looking for relief from motion sickness induced by these constant changes in speed on long trips, wrote the automakers demanding a solution... "or else". In light of this veiled threat the automakers used the speedometer position as the set-point value and the throttle position as the control variable. In this "closed-loop" arrangement the actual position of the speedometer, sampled at some constant rate, is compared to the set-point value and the difference, the error, between them is used to adjust the throttle position. Thus, compensating for changes in external conditions that would otherwise cause changes in the vehicles speed. Cool, the little girl was pleased.

The difference between the closed loop algorithm in your car's cruise control and the one that controls the gimbal positions of the Space Shuttle's three main engines ...the ones that hold the Shuttle on trajectory while compensating for all the external factors encountered in accelerating from zero at 4,400,000 lbs to 17,320 mph at 240,000 lbs... ?

Cost.

They perform the same function, use the same math and can be written in less than 50 lines of code.

For the RA cylinder's position control a basic Proportional Integral Derivative (PID) loop should do nicely. It is robust, extend-able and amazingly simple. The PID loop math is executed at some constant rate....say 100 times a second (a 10ms sample rate the BlackFin will laugh at)....and looks about like this...

error = desiredCylinderPosition - currentCylinderPosition;
integral = integral + (error * sampleRate);
derivative = (error - lastError) / sampleRate; 
commandToValve = (Kp * error) + (Ki * integral) + (Kd * derivative);
lastError = error;

Really. The three gain constants (gains)...Proportional Gain (Kp), Integral Gain (Ki) and Derivative Gain (Kd)... are determined during a "tuning" phase that would take place for each system. For most systems only Kp is needed with Ki and Kd left at zero. Large changes, like going from a 5lb to a 50lb OTA, will require different gains. Simple look up tables and self calibration can be used to automate gain changes with very little, if any, user intervention.

General Rules of Thumbs*

- The resolution of the position feedback should be 10 times greater than the maximum allowable error. i.e. If you must within 1cm of the desired position at all times the position feedback device should have a resolution of 1mm or better.

- The frequency response of the valve should be at least 2 times the sample rate. i.e. For a 10ms sample rate the valve should be able to change the cylinder direction every 5ms.

*Deciding to bend the rules is deciding to hit your thumb with a hammer.....you might miss....rarely.

Geek Ramble: Off

What is the schedule for the first prototype ?

Rusty.

[NickK]

Well to get an idea of what we're looking at, I think we need to look at some design parameters first:

Accuracy

Manufacturer| Model   | Accuracy
SkyWatcher  | HEQ5   | 0.144 arc second resolution (not error!)
Vixen           | AXD     | RA 1 arc min, DEC 10 min
10 Micron   | GM4000  | Positioning ±2 arc min, tracking ±3 sec
Meade        | 20"     | Periodic 5 arc sec, pointing 1 arc min
Takahashi   | EM-3500 | 2.5 arc sec

Tak's is their observatory mount. *dreams* but in reality I think if I'm as good as the Vixen or getting towards the Mead then I'd be happy. We'll leave the tak for v2 (air bearings?)

The error of accuracy exists from:

a) the mount main baring play

both cylinder baring play

c) compression

Let's target 10 arc sec tracking for the mount itself.

Maximum payload

A Vixen VC200L is ~6Kg. Add 5Kg for a refractor, imaging paraphernalia (2Kg), basic target scope 1Kg.. 14Kg so far..

Lets say a maximum of 20Kg balanced payload (±2Kg deviation as it won't be a perfect payload). We may not need this much but we do need an initial target for v1.

Speed

I'm happy for this to be relatively slow to seek at the moment. It'll have masses in reserve anyway.

I think initially we should stick to one axis - RA, solve that then we can reuse what we know for DEC.

So the next step is to:

a) design the sensor system to cope with the accuracy (taking your rule of thumb this will need to detect 1 arc second RA (or 0.25deg).

design a hydraulic movement system to be able to deliver 1 arc second with a 20Kg payload.

This is going to be hard..

[RustyM]

The error of accuracy exists from:

a) the mount main baring play

both cylinder baring play

c) compression

Let's target 10 arc sec tracking for the mount itself.

Good point. Bearing and other mechanical slop can be a killer.

Should the use of two cylinders mounted in opposition (pushing against each other slightly) be considered ? This would "pre-load" the compression and mechanical slop.

An opposing gas shock (from a car hatch back, say) might be better...cheaper, simpler.

I think initially we should stick to one axis - RA, solve that then we can reuse what we know for DEC.

Divide an Conquer.

Always a sound strategy.

This is going to be hard..

Be bold and mighty forces will come to your aid.

On parts and such......

I live in Dallas and work from home for a company based in Las Vegas (we also have a shop outside London). We do all our manufacturing in Vegas where we have a machine shop and an electrics/controls shop. I'm going to be working in Vegas for two plus months starting ~15 January. During that time I will have unlimited access to the shop and its tools. So....If we come up with some parts designs in the next few months I can make them

There is a huge aerospace junkyard/surplus store in Los Angeles. They might have some useful goodies....valves, cylinders, etc. I might have a buddy that could go have a rummage or I can go myself while I'm in Vegas (only ~250 miles from Vegas).

If we can find somebody in the Seattle area....there is the Boeing surplus store (never go there with a credit card or more cash than you are willing to part with). They might also have some good stuff at a good price.

Cheers,

Rusty.

[NickK]

Grr just wrote a long response and lost it (should make it open new threads on new tabs and not replace the current!).

I've got the blackfin compiler chain set up in a VM with ubuntu 10.10. It's easier keeping linux self contained in a VM. I know this works as I've done this in the past. This means I can write the firmware for the blackfin in C with a little hook of blackfin assembler to get the thing working. It also allows me to get a concept star tracker up and running too. I have a servo based tracking gimble which is good enough for testing light dots reflected on a wall but not for carrying a load).

I've been researching the optical sensor. Mouser.com allows orders from 1+ pieces however for the more sensitive sensors they're asking 600-1000+ minimum! I'll have a look at what mice can be hacked too. Avago is the main component manufacturer I've found - the good thing is that they have a complete data/command reference for their chips on their site.

The problem is that the mass produced mice are now system-on-a-chip (SOC) devices that interface directly using USB. Great for attaching to the PC/Mac but not for latency (or a far more complicated interface to the blackfin).

So we may have to go for accuracy by making the radius from the axis longer so the lower quality sensors have a chance to track the small movement. The problem is the track speed is lower too which slows positioning tracking.

Junkyards would be great, the only problem is you have to go with an idea of what you're looking for, find bits that match the requirements and finally then alter the design to fit what you have. Not a problem as such, it's just we need to have a design first..

I've found FreeCAD may suit our needs for this. It's free, opensource and platform independent - for Mac/Pc/Linux. It can import/export a wide range for CAD formats too.

[NickK]

Back after the christmas break. I have researched the sensor as it would be stupid to start if we couldn't sense as accurately as we'd like.

I'm happy to say the Avago ADNS-9500 sensor has interesting stats:

Resolution: 5000 counts per inch (cpi)

Framerate: 11,750 frames per second

Highspeed motion detected at 150 cpi with 30G acceleration max.

Max speed: 200 inches per second

So, it can sense 1/5000 inch change in position every 11,750th of a second. Holy cows.

It can connect via a serial SPIO bus @2MHz using 3.3v which would match the blackfin's levels nicely.

Lastly the datasheet is readily available from Avago (I have it already). The datasheet contains all the physical characteristics, standard circuit design, hardware register definitions and SPIO commands to manipulate the registers.

Oh, and it's found in the G500 gaming mouse which retails at £35... now where's my soldering iron.

[NickK]

Just to do some simple maths*, an arc second is 0.25 degrees and if the sensor is placed 4 inches from the axis centre then our resolution will be:

atan((1/5000)/4) = 0.028274 degrees.

So that means we can sense 1/10th of an arc second change if I have done my maths right..

So I think we have found our sensor.

* - ie not making any compensation for the circular movement as the point of measurement should make this as close to be linear anyway..

[NickK]

I'm wondering if you could display the guide scope image onto the mouse sensor itself. The speed of motion sensing would make for a very very sensitive guide sensor too.

[acey]

You might be interested to know that Lawrence Parsons constructed a "water-powered drive" for an 18" reflector built in 1866 that was used alongside the 72-inch Leviathan. This fact is mentioned without source or further elaboration in Steinicke, "Observing and Cataloguing Nebulae and Star Clusters" (p307).

[FraserClarke]

Just to do some simple maths*, an arc second is 0.25 degrees

An arc second is 1/3600 of a degree...

1296000 arc seconds in a full revolution.

[NickK]

An arc second is 1/3600 of a degree...

1296000 arc seconds in a full revolution.

Edit.. windows calc is playing silly.. I'll do the maths once at home.

I still think we can quite happily hit the 10 arc sec target

Ok.. pen & pencil, that works out at 41.2529" (~104cm) for a 1 arc sec accuracy. So ~4" will give us 10 arc secs, ~8" will give us 5 arc secs.

I could use a non-loaded gearing system to increase the acuracy however that would ruin the purity of it Another way is to actually drive a second disk with a solid link between them. The position of the pivot pin on each disc is different allowing the main axis disk to drive the second disc at a faster rate thus replicating gearing with having less play between the teeth (only the minute play in the bearing).

Hmm 41"... long stoked cylinder.. Now there's a possibility.

[NickK]

I'm expecting the G500 to arrive next week, I can then give it a once over and see if I can get it and the blackfin talking.

[NickK]

The G500 mouse is in transit according to UPS, I should get it tomorrow/thursday if I have to collect it after work..

[NickK]

Hehehe...

The G500 certainly does have an Avago ADNS-9500

It's just arrived, took it out and checked it worked via USB then took the screw driver to it and opened it up.

So this weekend, if I have time, I'll see if I can jerry-rig the 9500 and the blackfin together.

edit: this is going to have to wait till next weekend (sofa due feb is arriving early).