What's a Robo-scope ?
Any telescope that can be driven from the comfort of your lounge computer !
Main features are :-
1) Wireless 'GoTo' controlled from your main PC
2) Astro-camera controlled from your PC (with results 'immediately' available at your computer screen)
3) Optional - some sort of self-contained auto-guiding at the mount
What are the advantages & disadvantages ?
The advantages should be obvious - no more shivering under the clear but cold UK night time skies !
The main disadvantage is that you are not present to spot the mount wrapping cables around protrusions and stop it ripping out connectors - or running the telescope / camera into the tripod legs
This is less of a problem if you have a 'pillar' mount - but even then I suggest you watch the 'GOTO' movement until the 'target' position is reached and imaging starts ...
What's needed to build one ?
Modern GOTO telescopes typically come with PC software that is already capable of 'remotely controlling' the mount. Older GOTO's (and build-it-yourself motor drives) do not.
There was a time when building your own 'GoTo' would have been impossibly expensive = however with the arrival of the Raspberry Pi, this sort of task is now well within reach !
Older GOTO's typically came with a 'serial port' (using some sort of 'custom' plug, presumably to 'force' you to pay $$$ for the mount manufacturers 'custom' cable) that allowed direct connection to the standard 9pin serial port found on older computers. More modern ones use USB ports.
Over the years the control protocol's have been 'un-picked' by cash-strapped owners and Open Source control software written. Software such as Stellarium running on a computer can now act as a graphical interface to control the mounts 'GoTo'
How are the GoTo commands sent to the 'remote' mount ?
'All' that is necessary is to provide a 'wireless' link from your PC (running Stellarium etc) to your mounts 'serial link' (or USB) cable socket.
Using Bluetooth
The simplest method of connection (other than a physical cable) is 'Bluetooth'. Whilst desktop PC's typically lack built-in Bluetooth, a USB<>Bluetooth 'dongle' need cost no more than 99p.
The Bluetooth<>serial unit needed at the mount end is rather more expensive. You can start with bare-bones a £10 Bluetooth<>serial 'master' unit from eBay (and box it yourself) or go for the rather more expensive off-the-shelf 'Bluetooth to serial' self-contained (battery driven) units (typically in the £30 region) - at which point you might as well start to consider using a Raspberry Pi (with another 99p USB<>Bluetooth dongle) since the Pi will then be available for camera control
Bluetooth has the disadvantage of being short range and essentially 'line of sight' - which is fine if there is nothing between your desktop PC and the telescope other than your patio doors (or a window) = but much less fine when the Bluetooth dongle is plugged into the back of a floor-standing PC with the PC itself, your legs a wall or two and sundry piles of telescope parts between it and the mount !
Using WiFi
The longer range & more 'robust' alternative is WiFi. This has the advantage that you will already have a WiFi Router in your house - so 'all' that is necessary is to provide WiFi<>serial support at the mount. However, unlike Bluetooth, WiFi is a rather more complex means of connection - you 'really' need some sort of computer at the mount to 'connect' to WiFi and pick up the 'serial' commands
Of course, you also need a computer at the mount to control your camera ... and the 'cheap' choice is to search the attic for your old laptop.
Most Open Source / Freeware Camera apps. like 'DSLR Shutter' will run just fine on older Operating Systems (such as Windows 2000 - and maybe even Windows 98 !) so if your 12 year old laptop is running Windows 2000 in 256Mb of RAM don't bother trying to 'upgrade' it to Windows XP. One disadvantage of really old laptops is that they lacked built-in WiFi - or WiFi was an 'optional extra' charged at a premium (i.e. extortionate) price (so was never purchased)
If you have an ancient Laptop without WiFi, check if it has (or will take) a WiFi PCMCIA card, however be aware that older PCMCIA WiFi cards & drivers typically supported only WEP encryption (and not the more secure WPA-2 that you should be using on your home WiFi network). If your laptop has USB but no built-in WiFi, a USB WiFi 'dongle' is likely to be the cheapest option (however now you will need to be running Windows XP as Windows 2000 USB support was always 'flaky' at best)
The more adventurous choice is, of course, to use a Raspberry Pi. It will need a USB<>WiFi 'dongle', however 'WiFi<>serial' pass-through software already exists. You will need to 'buffer' the Pi's serial output to drive the mount (using a MAX3232 chip board - approx £2 from China).
How do I control my camera ?
If you have an old laptop computer at the mount, you can use 'DSLR Shutter' via the parallel port (since the serial is being used to drive the GoTo) = see my Using your Camera - Parallel port control page
The Raspberry Pi also makes a good camera controller - in fact, all the code is already written to both take photos & transfer the image from the camera (via camera USB to Pi RAM) and transmit it to a PC via WiFi ! See here for camera control and here for a list of cameras that can be controlled via USB.
How do I link "serial to WiFi to serial" ?
The Open Source utility 'com0com' can be used to 'invisibly' transfer a 'serial port' from a local PC to a remote one. This app. creates 'virtual' ports (eg com3) that can be used 'as normal' by an application on the local PC (eg Stellarium). However instead of passing the data to a physical COM port & cable on the local PC, data is sent via WiFi to a remote PC. On the remote PC, data is then passed to a physical COM port and cable to the telescope mount.
There are dozens of 'serial via TCP/IP', 'serial via WiFi' etc. utilities 'out in the wild'. Most fail to 'launch' (because they are relying on MS .NET or similar 'library' components that don't exist on your PC) or fail after 'launch' (typically because they rely on MS Serial drivers that are not present on a PC with no COM ports at all). The ONLY one I've found that actually 'works as advertised' is com0com
Because USB ports are 'seen' as 'COM' ports by software, com0com can be also used to send the 'serial commands' to a USB controlled mount (see below).
What's needed on the 'local' PC ?
Start by downloading the com0com.exe and the hub4com .zip package.
Unpack and copy just the hub4com files into the C:\ 'root' of both the local and remote computers (hub4com contains 'batch' files and 'command line' utilities .. it will be a lot easier to 'pick them up' if you don't have to 'navigate' up some folder 'tree')
On the local PC (only) run the com0com.exe installer and let it create a single 'virtual COM port' pair (Pair 0 = CNCA0 + CNCB0).
On the local PC, launch com0com and in the GUI 'Setup for com0com' window that appears, under CNCA0, check the two options 'use Ports class' and 'emulate baud rate'. CNCA0 will be 'converted' into a 'real' COM port (eg 'COM3' - so you will now see 'real' COM3 is 'linked' to the 'virtual' Com port CNCB0).
COM3 is now 'connected' to CNCB0
The just created 'real' COM port (eg COM3) can now be selected for use by your local application eg Stellarium
To start the 'transmission', on the local PC open a 'Command Prompt' and 'cd ..' as often as needed to reach the 'root' ('c:\>'). Type "com2tcp-rfc2217 \\.\CNCB0 {IP address of remote PC} {port number to use (must be >1000)}" - for example, if the remote PC is TCP/IP address 192.168.0.10 and you decide to use port 7000, then type :-
com2tcp-rfc2217 \\.\CNCB0 192.168.0.10 7000
CNCB0 is now 'connected' to the PC at 192.168.0.10 via UDP 7000
Needless to say, the Firewall on your local PC has to permit the com0com application to access the LAN (and the destination address) and your WiFi Router has to 'route' traffic between your local computer and the remote one
What's needed on the 'remote' PC ?
Make sure the hub4com components have been copied into the root (c:\) of the remote PC, then open a 'Command Prompt' and type 'cd ..' as necessary to reach the 'root' ('c:\>').
Then type "com2tcp-rfc2217 {actual physical COM port} {UDP port number chosen at local PC}" - for example, if the remote PC is linked to the telescope mount via COM1 and you are using UDP 7000, type :-
com2tcp-rfc2217 COM1 7000
UDP 7000 is now 'connected' to COM1.
The result of these links (COM3<>CNCB0<>UDP7000<>COM1) is that applications (eg Stellarium) using COM3 on the 'local' PC will actually be using COM1 on the remote PC (and be unable to tell the difference).
If your mount is controlled via USB, insert the USB 'com port' number in the above command instead of 'COM1' (for example, if USB port is com5, then type "com2tcp-rfc2217 COM5 7000")
How to 'auto-guide' a remote telescope ?
In essence, you just 'bolt' a web-cam to the 'spotter scope' (or a co-mounted small refractor) and 'feed' the images to 'correction' software. The only difficult bit is getting this to run 'remotely'
Windows
You 'control' your remote PC from a 'window' on your local PC, via WiFi, using the Open Source standard ‘remote desktop' VNC software (or the similar Team Viewer). On the remote PC, you just run the 'Windows standard' auto-guiding software PHD ('Push Here Dummy').
You start by using VNC to link the mounts serial line (at the remote computer) to the local computer using the 'com2tcp' command (above). Once the local computer has sent the 'goto' commands (and moving to the 'target' is complete), you use VNC to 'disconnect' the serial line from com0com and use it with PHD instead
Raspberry Pi
Although the Pi 'camera' has been available for a good few months, 'auto-guiding' using the Pi is still in it's infancy, with 'frame rates' in the 'multi-seconds per correction' range.
Indeed, currently it's (much) faster to get the Pi to act as a dumb 'web-cam' sending the auto-guide image 'stream' to a PC (and have the PC, running PHD, do the 'processing' and send the 'corrections' back). Hopefully this will change in 2014