Installing Canon EOS Utility on Mac without the CD

March 30, 2013, 8:14 am

≫ Next: Moving the mirror on the SkyWatcher 130M

≪ Previous: Raspberry Pi motion sensitive Trail-Cam

$

0

0

My second hand Canon EOS 1000D has arrived (intended for astrophotography), but without the manual or software CD. Canon provide this stuff to download on their website which is great, except that the software is intended only to update an existing installation originally made from the CD-ROM. That seems stupid on many levels - the only people interested in using this software will have a Canon camera. Practically speaking, I have neither the Canon CD-ROM, nor in fact even a CD-ROM drive. Apple don't believe in them any more ;)

Fortunately enterprising people have worked out how to hack the Canon software to install without the CD-ROM, both on Windows (e.g. here) and on Mac OS X. Canon don't support Linux.
The Canon EOS 1000D downloads page for Mac OS X 10.8 currently offers EOS Utility 2.12.3 Updater for Mac OS X (filename eu2.12.3x-updater.dmg.zip), but the tricks I found documented online to install this without the CD-ROM failed. Therefore we need to start with an older version which can be fooled.

There is a trick here (deleting file  Info.datx file) credited to FrancoisG for version 2.11.4 (filename EU211.4x-updater.dmg). I couldn't find that on the Canon websites anymore - it is listed on the Canon Asia site, Canon EOS Utility 2.11.4 Updater for Mac OS X, but the download link is broken. However I could find version 2.10 on the Canon UK site, and the hack here for version 2.9 still works.

Here's what I did to get v2.10 installed:

1. Download EOS Utility 2.10.2 Updater for Mac OS X, intended for Mac OS X 10.5 upwards but not 10.8 (filename eu2102x.dmg.zip).
2. Decompress the zip file by double clicking on it to extract the disk image, eu2102x.dmg
3. Mount the disk image by double clicking it, then drag UpdateInstaller.app to your downloads folder.
4. Right click on your copy of the installer app and select Show Package Contents, open folder "Contents", "Resources".
5. Right click on the SDI.bundle and select Show Package Contents, open folder "Contents", "Resources".
6. Delete the update.plist file and return to the downloads folder.
7. Run the modified installer application. It will ask for the administrator password.
8. Try to run the EOS Utility app, it will complain "Alert: Cannot be used with this version of the operating system"

Now, to update it:

1. Download EOS Utility 2.12.3 Updater for Mac OS X (filename eu2.12.3x-updater.dmg.zip)
2. Decompress the zip file by double clicking on it to extract the disk image, eu2.12.3x-updater.dmg
3. Mount the disk image by double clicking it
4. Run the updater, eu2.12.3x_updater.app, again it will ask for the administrator password, and this time it asked to restart the computer as well.

Now to test it:

1. Run the EOS Utility app.
   
2. Check the version via the main menu.
3. Connect the camera via the USB cable, and turn on the camera.
4. Click on "Camera settings/Remote shooting", and a tall this window appears - quite what all the icons mean is not immediately obvious, nor the counter.
   
5. On the main menu, I tried "Tool", "Test shooting ..." (Alt+Apple+S), which opened a new window and caused the camera flash to open and take a photo.
   
6. Next, I guessed that the round button on the top left of the remote shooting window was a remote shutter button.

There does not seem to be any help file included with the application which is disappointing, but I later realised there was an out of date PDF manual EOS Utility 2.11 for Macintosh Instruction Manual on the Canon 1000D website. I find it bizarre that Canon don't bundle this with the software.

Tip: The buttons shown in this application depend on the camera mode, use the ring dial to change this. In full auto mode (green square on the dial) then the yellow tool icon on the "Camera settings/Remote shooting" window is disabled.

Firmware Update


One of the reasons to install the EOS Utility is to update the camera's firmware - mine had v1.0.3 while the current Canon EOS 1000D firmware is v1.0.7 (oddly this wasn't on the Canon UK website). I've not done this yet as you need a spare SD card which will be reformatted.

Shutter Count

I couldn't find the shutter count via the EOS Utility, but the simple free app 40D Shutter Count seems to work and apparently when I got it my Canon EOS 1000D had taken only 7790 photos - so should have lots of life left in it.

---

Moving the mirror on the SkyWatcher 130M

April 13, 2013, 3:42 pm

≫ Next: Raspberry Pi Trail Cam - Update

≪ Previous: Installing Canon EOS Utility on Mac without the CD

$

0

0

My SkyWatcher 130M telescope needs a little help to reach prime focus with a DSLR camera (see also this great blog post). So I decided to move the primary mirror up the tube to allow my Canon EOS to reach focus when attached directly to the T-ring for prime focus astrophotography. This involved almost completely dis-assemblying it, playing with new nuts and bolts, then putting it back together.

I started by removing the spider and secondary mirror assembly, which are held by four recessed screws and nuts on the inside (which should not be dropped onto the primary mirror):

Four screws hold the SkyWatcher 130M spider	SkyWatcher 130M (SK1309EQ2) secondary mirror

By the time I finished, I realised it probably wasn't essential to remove the secondary like this, but it does make dealing with the four nuts at the other end of the tube easier! Once the four retaining screws in the curved side of the bottom piece are removed (again, taking take not to drop the nuts on the mirror), the whole mirror cell can be removed. This comes in two parts joined by the three collimation screws - separated by rubber 'O' rings (about 5mm as a pair):

SkyWatcher 130M (SK1309EQ2) ring for primary mirror, showing one of four tube attachment holes (top left) and one of three flanges for collimation screws	SkyWatcher 130M (SK1309EQ2) primary mirror, showing one of three mirror clips (right) and one of three collimation screws & locking screws

I'd intended to follow the method on this thread moving the mirror of the SkyWatcher 130P, replacing the collimation screws with longer bolts, and the rubber 'O' rings with 2cm long compression springs (specifically the SC229 springs from www.strutdirect.co.uk). However, once I'd taken it apart I realised the SkyWatcher 130M has a differently mounted mirror.

Here is my schematic of the original arrangement (left) and how I moved the mirror up the tube (right) by about 3cm. The basic idea is to put the mirror mounting plate (shown in blue) above the mounting ring (shown in green), allowing enough room for the four nuts used to attach the ring to the main tube:

Diagram showing SkyWatcher 130M (SK1309EQ2) primary mirror attachment.	Diagram showing modified SkyWatcher 130M primary mirror attachment, moving it about 3cm

The collimation screws' holes in the mounting plate are not threaded (although the neighbouring lock screws do have threaded holes), so I have put washers either side of this in the hope that when I turn the new longer collimation screw (35mm M5 thread) in the threaded hole on the flange of the mounting ring this will move the mirror. We shall see.

Simply reusing the existing rubber 'O' rings seems to work (they are glued onto the flange so must be carefully peeled off in order to use them on the other side of the flange). A very short spring might work instead...

Replacement collimation screw with rubber 'O' ring, nut and washer ready for the mirror plate...	Reassembled mirror cell post modification, filing by yellow tape aligns to the main tube's seam.

As my diagram tried to suggest, it is a pretty tight fit to get the mirror's mount disk inside the main tube. I had to file it down 1mm or so in places, and more at the seam of the tube. You can see this as the shiny edge in the photo above by the yellow marker tape - I may need some mat-black paint to cover this. Despite this, there is now a lot more light leaking into the end of the tube - a new cover might help?

And here's an exterior shot of the reassembled telescope tube - having moved the mirror like this makes it really quite easy to place the four nuts and bolts, but they do restrict the mirror placement - I've had to move it higher than I originally intended.

SkyWatcher 130M before modification, note the plate is flush with the ring.	SkyWatcher 130M after modification, note you can reach the ring nuts etc.

You might notice that I've left the old collimation lock screws in place - I'm intending to try using them like this with fingers/pliers to turn them. It might work?

If this alternative mounting doesn't work that well in practise, I'm now less nervous about the simpler option of simply cutting an inch off the end of the tube itself. With a suitable saw I think that would actually be more straightforward (but irreversible).

I'm waiting for a clear night to test this out, and attempt to re-collimate the telescope. Fingers crossed for some nice astrophotography results with my Canon EOS DSLR directly attached. From some daylight testing it does seem like I will need an extension tube for some of my eyepieces now - I really should have ordered one before.

I'll direct any discussion to this thread on the StarGazersLounge.com forum.

Update (21 April)

I did get a chance to test the initial modification, and took a couple of photos of the Moon and Jupiter, but it was too windy to really examine the performance on stars. Comments on the this thread reinforced my worry about too many moving parts with the extra nuts, so I'm trying out an alternative arrangement using springs. The trick here is I've cut a slot into the end of the bolts which can then be turned from the outside with a flat screwdriver for collimation adjustments.

Diagram showing SkyWatcher 130M (SK1309EQ2) primary mirror attachment (pre-modification)	Diagram of SkyWatcher 130M using springs for primary mirror attachment, moving it just over 3cm

Since I'd already bought them, I am using the SC229 springs from www.strutdirect.co.uk (as recommend for moving the mirror of the SkyWatcher 130P), but they are a little long for this setup in the SkyWatcher 130M. Maybe I don't need all the washers, but as shown the mirror is a few millimetres higher still.

Original SkyWatcher 130M modification re-using the rubber 'O' rings for the mirror	Revised SkyWatcher 130M modification using springs to mount the mirror

Again, please post any discussion on this thread on the StarGazersLounge.com forum.

Raspberry Pi Trail Cam - Update

May 13, 2013, 2:00 pm

≫ Next: Blue Tit eggs

≪ Previous: Moving the mirror on the SkyWatcher 130M

$

0

0

Its been two months since I posted the first set of photos captured by my Raspberry Pi trail-cam. Since the UK had some unexpected snow in March 2013 - during which the garden based Raspberry Pi continued to work just fine.

Pheasants in the snow

Bar missing some days where the SD card filled up, and a couple of occasions when for reasons unknown motion failed, the Raspberry Pi worked very nicely - despite the cold. There were a few more unexpected sightings in the last week...

We're not sure where this cat lives, but we have seen it in the garden before:

Bird Hunter

But this was a surprise - a pair of deer (judging from the full set of images) were in our garden at dusk on Saturday! I wonder if I left the gate open or they found another way in avoiding the camera?

Venison and Bambi?

Blue Tit eggs

May 29, 2013, 9:54 am

≫ Next: Blue Tit chicks hatched

≪ Previous: Raspberry Pi Trail Cam - Update

$

0

0

In addition to automatically monitoring my TrailCam, the garden based Raspberry Pi has continued to watch the Blue Tits in Bird Box III which have this year laid a clutch of seven eggs, averaging one a day.

No eggs	One week later, seven eggs

Here are some of the intermediate images:

The first egg, recently laid	Two eggs

Three eggs	Four eggs

Feather delivery	Nesting material

Five eggs	Seven eggs

Still seven eggs	Home delivery

More insulation?	Another week later, no advance on seven eggs.

These glimpses of the eggs are few and far between - most of the images are of one nesting Blue Tit moving on the nest, with only a handful of images with both parents visible.

With the default motion settings I was getting tens of thousands of images a day recorded - which was causing trouble filling up the Raspberry Pi's SD card, and occasionally failing with a read only file system. That required me to reboot and delete older images to make space. I've imposed a maximum of 5 frames a second for now...

According to the internet, the typical Blue Tit egg incubation time is around two weeks, so these should hatch about the start of June.

Update:

The Blue Tit eggs hatched at the end of May

Blue Tit chicks hatched

June 2, 2013, 7:14 am

≫ Next: Raspberry Pi XBMC infrared remote control

≪ Previous: Blue Tit eggs

$

0

0

Photos from Friday, six of the seven Blue Tit eggs have clearly hatched.

Food!	Broken egg shell to recycle

One egg unhatched	Two open mouths, one egg

Both parents squeezed into the box	Five open mouths, one closed beak

Food or a feather?	Six hungry mouths

Six hungry chicks competing	Six or seven chicks?

I'm not sure if the last egg hatched or not - I've not seen a clear image of seven mouths but in a couple of shots like the last ones above, there could be a seventh chick which happened to have its beak closed? We shall see..

Using the motion software, my garden based Raspberry Pi is still recording tens of thousands of images a day recorded - not only does this cause trouble filling up the Raspberry Pi's SD card, browsing the folder for each day makes my desktop struggle with the thumbnail images!

Raspberry Pi XBMC infrared remote control

October 14, 2013, 4:18 am

≫ Next: Roomba 620 infrared signals

≪ Previous: Blue Tit chicks hatched

$

0

0

I've added an infrared receiver to my Raspberry Pi, tucked inside a PiBow case with its clear top layer letting it receive the signals. This lets me re-use an old DVD player IR remote to control XBMC running on the Pi.

IR sensor and cable hiding inside PiBow case

Basically I followed this AdaFruit Tutorial for adding an IR receiver to the Raspberry Pi, but not being in the USA I had to substitute parts which I sourced via eBay instead. Despite much searching, the shortest suitable jumper cables I could find (one pin to one pin, 1P-1P, and female-to-female, F/F) were 10cm long - which is a bit much to coil up inside the Pibow case but easier than soldering.

Parts:

• 1x TSOP38238 InfraRed receiver (under £2 from eBay with shipping)
• 3x 10cm Dupont Wire  2.54mm 1P-1P Female/Female jumper cable (pack of 40 for £1 on eBay)

The three jumper wires (split off my ribbon of 40 as a triple) connect the three pins of the IR sensor to GPIO18, GND, and 3V3 respectively (pins 12, 6, and 1).

IR sensor and 10cm jumper leads to Raspberry Pi

Raspian Configuration

I just used the following to check the hardware was working:

$ sudo apt-get install lirc
$ sudo modprobe lirc_rpi
$ mode2 -d /dev/lirc0

This showed it received signals from my assorted working IR remote controls. I didn't go any further with this since I'm not actually running XBMC under Raspian at the moment.

OpenELEC

Then for XBMC under OpenElec, I followed the instructions here via SSH. Under OpenElec LIRC is already installed, we just need to enable it for the current session, add this to the startup script for future use, and then configure the remote control.

$ modprobe lirc_rpi
$ echo "modprobe lirc_rpi">> /storage/.config/autostart.sh
$ irrecord /storage/.config/lircd.conf

Running irrecord is a bit fiddly, but seems to work nicely. I found it helps to have looked at the output of this command which lists all the KEY_* names that irrecord understands.

$ irrecord --list-namespace

Remote control configuration tips for XBMC (see this HowTo):

• For navigating the menus in place of the cursor keys on a normal keyboard, define KEY_LEFT, KEY_RIGHT, KEY_UP and KEY_DOWN (at least that was easy).
• For navigating the menus in place of 'enter' on a normal keyboard, define KEY_OK rather than KEY_SELECT or KEY_ENTER.
• For navigating the menus in place of 'backspace' on a normal keyboard, use KEY_EXIT, none of KEY_BACKSPACE, KEY_BACK or KEY_CANCEL work.
• For the context menu reached via 'c' on a normal keyboard, none of KEY_C, KEY_MENU or KEY_CONTEXT_MENU work. However, KEY_EPG (electronic program guide) does.
• For media information reached via 'i' on a normal keyboard, defining KEY_INFO works.
• For changing the volume, KEY_VOLUMEUP and KEY_VOLUMEDOWN work fine. However KEY_MUTE appears to have no effect.
• For rapid scrolling through the menus I like to use Page Up/Down on my normal keyboard. Unfortunately KEY_PAGEUP and KEY_PAGEDOWN via the remote have no effect.

When I say things have no effect, they are being detected as you can monitor this live via SSH while running XMBC:

$ irw /var/run/lirc/lircd-lirc0

To rename a key, edit /storage/.config/lircd.conf and reboot.

This was done under OpenElec v2.95.6, which I then updated to v3.2.2 after releasing the automatic updates hadn't picked up the major releases.  The remote still seems to work (and seems to have fixed a playback glitch too). I may need to fine tune the repeat settings for best results...

Roomba 620 infrared signals

October 23, 2013, 3:14 pm

≫ Next: Raspberry Pi IR blaster and Roomba IR codes

≪ Previous: Raspberry Pi XBMC infrared remote control

$

0

0

Having been pondering it for a while, I recently bought an iRobot Roomba vacuum cleaner - the Roomba 620 which is the current entry model. For fun I took some photos with an infrared sensitive webcam (a trusty XBox Live Vision), and then measured some of the IR signal codes with my Raspberry Pi.

Note the four downward facing IR LEDs (cliff sensors)	Does the Roomba use IR illumination to follow walls?

Initially it might seem like the Roomba explores blindly until it bumps into things, but it does have some open space detection as you can obverse speed changes. Having seen how it lights up where it is going with four IR LEDs (and another four pointing down which I assume are the cliff detectors) this is less mysterious.

Roomba Home Base

I've already done some background reading, so I was expecting to be able to see three IR LEDs on the Roomba Home Base or "Docking Station" - the top one is a unidirectional emitter visible from all sides of the dock (and behind it) referred to as the "Force Field" which normally repels the Roomba. The other two emit angled beams used to guide the Roomba to its "Home Base" for recharging.

Roomba Docking Station, with three IR LEDs (and glare)
Roomba coming in to dock using infrared	From Roomba iRobot Create Open Interface

This works like the port and starboard (red and green) lateral buoys in used to guide ships into harbour. By keeping the "Green buoy" to port (left), and the "Red Buoy" to starboard (right), the Roomba can find its way home. Of course, here the LEDs are not different colours (although I'd guess the original prototypes probably were), rather they emit different pulsed signals - which I should now be able to detect and decode with my newly fitted Raspberry Pi infrared receiver.

Published Roomba IR Codes

I used iRobot Create Open Interface v2 (PDF) to compile the following table, specifically page 18 which has the above diagram, and which covers the remote codes indirectly when talking about the Roomba serial interface - iRobot have been very positive about people hacking their robots for technology projects.

Each of these remote codes is 8 bits (1 bytes) which can be represented as a decimal number, a hexadecimal number, or a string of eight bits (hereafter the first bit in the signal being the most significant bit in the numerical code).

Sent by	Dec	Hex	Binary	Meaning
Remote Control	129	0x81	1000 0001	Left
	130	0x82	1000 0010	Forward
	131	0x83	1000 0011	Right
	132	0x84	1000 0100	Spot
	133	0x85	1000 0101	Max / Dock
	134	0x86	1000 0110	Small
	135	0x87	1000 0111	Medium
	136	0x88	1000 1000	Large / Clean
	137	0x89	1000 1001	Pause
	138	0x8A	1000 1010	Power
	139	0x8B	1000 1011	Arc-forward-left
	140	0x8C	1000 1100	Arc-forward-right
	141	0x8D	1000 1101	Drive-stop
Scheduling Remote	142	0x8E	1000 1110	Download / Send All
	143	0x8F	1000 1111	Seek Dock
Roomba 400 Home Base	240	0xF0	1111 0000	Reserved
	242	0xF2	1111 0010	Behind / Force Field
	244	0xF4	1111 0100	Green Buoy (meaning Starboard, or Right)
	246	0xF6	1111 0110	Right Close / Green Buoy & Force Field
	248	0xF8	1111 1000	Red Buoy (meaning Port, or Left)
	250	0xFA	1111 1010	Left Close / Red Buoy & Force Field
	252	0xFC	1111 1100	Middle / Red Buoy & Green Buoy
	254	0xFE	1111 1110	Middle Close / Red Buoy, Green Buoy & Force Field

The IR codes from the Home Base make sense with a bit each for the "Red Buoy" (Port, right LED beam), "Green Buoy" (Starboard, left LED beam) and the "Force Field" (unidirectional close range LED).

It would be my guess that the composite signals are not actually broadcast explicitly, but are the overlap of the output from the two to three separate LEDs which must therefore be time synchronised. Time to find out…

Recording Roomba 620 Home Base IR codes

I recently setup an infrared receiver in my Raspberry Pi which can be used to record IR signals from remote controls. I was able to use the same procedure to record the signals from the each of the three separate LEDs of the Roomba Home Base by blocking the others with card and tape.

The IR codes are documented as emitted 940nm using a form of pulse-width modulation (PWM), modulated with a carrier frequency around 38KHz. Each code consists of a sequence of eight bits, encoded as:

• Bit 0 - 1ms on, 3 ms off
• Bit 1 - 3ms on, 1 ms off

I stated by watching just the "Force Field" LED, from the back (while Roomba was away in another room), it was clear that (with some variation in the long pauses), there was a simple repeating pattern. For example, where the numbers are in micro-seconds (1000 is 1ms):

$ mode2 -d /dev/lirc0 ... space 33098 pulse 2947 space 965 pulse 1016 space 2865 pulse 3086 space 826 pulse 1044 space 2869 pulse 1015 space 2894 pulse 1015 space 2868 pulse 1035 space 2873 pulse 2953 space 99558 pulse 2947 space 969 ...

(long pause) 1 . 0 . 1 . 0 . 0 . 0 . 0 . 1 (long pause) 1 .

This repeating pattern was 1010 0001, or 161 (decimal), or 0xA1 in hex, which is not is listed in the current iRobot documentation (see table above).

Decoding that by hand was tedious, so I wrote a little Python script to decode the Roomba IR codes for me:

$ mode2 -d /dev/lirc0 | python decode_roomba_ir.py 10100001 - 161 - 0xA1 10100001 - 161 - 0xA1 10100001 - 161 - 0xA1 10100001 - 161 - 0xA1 ...

Attempting to watch the "Force Field" IR LED only, from the back, gave a nice clean simple repeat. Using some tape to securely mask the two buoy LEDs I could get the same clean signal from the front of the dock:

• 10100001 - 161 - 0xA1

With just the right LED and the top LED, there were apparently two codes:

• 10100001 - 161 - 0xA1
• 10101000 - 168 - 0xA8

Just the left LED and the top LED, again I saw two codes:

• 10100001 - 161 - 0xA1
• 10100100 - 164 - 0xA4

All three LEDs from front, in some locations it was hard to decode the 5 and 6th bits - but usually there was a blend of 0xA4 and 0xA8 giving 0xAC as a recognisable code:

• 10100001 - 161 - 0xA1
• 10101100 - 172 - 0xAC

It seems that with the 600 series Roomba have changed the Home Base IR codes (compared to the Roomba 400 series). While the left and right IR LEDs seem to be synchronised so that when you see both their individual signals 0xA1 and 0xA4 overlap to register as 0xAC, I wasn't able to get them to blend with the "Force Field" LED as well - maybe my sensor is at the wrong height?

Sent by	Dec	Hex	Binary	Meaning
Roomba 500/600 Drive-on charger/Home Base	161	0xA1	1010 0001	Force Field
	164	0xA4	1010 1000	Green Buoy (meaning Starboard, or Right)
	168	0xA8	1010 0100	Red Buoy (meaning Port, or Left)
	172	0xAC	1010 1100	Middle / Red Buoy & Green Buoy
Roomba 500 Virtual Wall	162	0xA2	1010 0010	Virtual Wall

The first four bits match João Figueiredo's Roomba Virtual Wall (1010 0010, or 162 decimal, 0xA2 in hex), which seems to hint at a new scheme. Curious.

Update - More official documentation

I've now found the iRobot Roomba 500 Open Interface Specification online (alternative link), which confirms these codes - and indicated I should be able to get a blend of the three IR LEDs.

Raspberry Pi IR blaster and Roomba IR codes

November 11, 2013, 4:14 pm

≫ Next: A Japanese-style kotatsu made in Scotland

≪ Previous: Roomba 620 infrared signals

$

0

0

When I finally bought an iRobot vacuum cleaner, I went for the Roomba 620 which is the current entry model. This version doesn't come with any accessories like the "Virtual Walls" (infrared barriers), an infrared remote control, or handy features like scheduling.

However, all of the above ought in principle to be possible by transmitting infrared (IR) signals from a DIY circuit... or a Raspberry Pi? For example, with older model Roombas people have used LIRC and an IR Blaster to tell their Roomba to start cleaning by mimicking the remote control - with the computer handling the scheduling.

Raspberry Pi Infrared Blaster, using a P2N2222A NPN transistor, and two IR LEDs in series with 3.3V

Roomba InfraRed Signals

iRobot sell simple IR remote controls which cover the basic commands (like start cleaning) and even let you steer it. The IR codes are emitted 940nm using a form of pulse-width modulation (PWM), modulated with a carrier frequency around 38KHz. Each code consists of a sequence of eight bits, encoded as:

• Bit 0 - 1ms on, 3 ms off
• Bit 1 - 3ms on, 1 ms off

and terminated with ~4ms off. That means in total the code and the pause is about 36ms. The IR control codes are published in the iRobot Create Open Interface v2 (PDF), and see also my last blog post on recording in the Roomba IR codes.

Raspberry Pi IR Blaster

I recently setup an infrared receiver in my Raspberry Pi, but this time I need to hook up an infrared LED under GPIO control. And if you want to mimic a Roomba docking station, you would need three separate independently controllable IR LEDs.

According to the source code (see original pull request and the lirc_rpi homepage), the default Raspberry Pi LIRC settings use GPIO18 (pin 12) for input and GPIO17 (pin 11) for output:

/* set the default GPIO input pin */
static int gpio_in_pin = 18;
/* set the default GPIO output pin */
static int gpio_out_pin = 17;

So, too make life simple, I used GPIO17 (pin 11) to connect my IR transmitter. Since I didn't have any resistors handy I improvised and uses two IR LEDs in series and the 3.3V supply (pushing the LEDs a little over the rating but it works for now in my solder-free test rig).

LIRC Codes

Some kind soul posted a LIRC configuration for the Roomba Remote Control (dated Oct 2007), with codes for clean, spot, max, power, and pause. Here's a cut down version showing just the clean button (the most important button).

# Excerpt from a config file which was automatically generated # using lirc-0.8.2(default) on Sun Oct 7 19:28:15 2007 # # brand: iRobot # model no. of remote control: Standard Roomba Remote # devices being controlled by this remote: Roomba Discovery/400 Series # begin remote name iRobot_Roomba flags RAW_CODES|CONST_LENGTH eps 30 aeps 100 ptrail 0 repeat 0 0 gap 91790 begin raw_codes name clean 2831 886 972 2709 944 2711 943 2710 2743 893 958 2723 931 2722 927 19304 2811 897 954 2726 927 2726 927 2726 2747 889 966 2714 942 2710 941 end raw_codes end remote

The LIRC Configuration File Format Technical Details tells us these numbers are in micro-seconds, so we'd expect to see patterns of 3000 (3ms) and 1000 (1ms) but what was measured were on average ~2740 and ~930 instead. Was the calibration slightly off?

We expect each code to send eight bits, each either 3ms on 1ms off or the other way round (then an off pause) which would be 15 numbers (16 if you include the final off). However, all the button recordings had 31 numbers so clearly this captured double singles - with a gap of about 19000 (or 19ms) in between.

$ sudo mv /etc/lirc/lircd.conf /etc/lirc/lircd_original.conf
$ wget http://lirc.sourceforge.net/remotes/irobot/Roomba
$ sudo mv Rooma /etc/lirc/lircd.conf
$ sudo modprobe lirc_rpi
$ sudo /etc/init.d/lirc start
[ ok ] Loading LIRC modules:.
[ ok ] Starting remote control daemon(s) : LIRC :.
$ irsend LIST """"
irsend: iRobot_Roomba

$ irsend send_once iRobot_Roomba CLEAN
(watch flash via IR camera!)

A single send didn't work. Four or five (in a quick loop) do. Range 4m+ (although harder to get the line of sight).

Generating a configuration file

Using this Python script I generated a complete set of Roomba IR codes for LIRC, based on the above example entry and the documented codes:

$ python make_roomba_lirc.py > Roomba_LIRC.conf
$ sudo cp Roomba_LIRC.conf /etc/lirc/lircd.conf
$ sudo /etc/init.d/lirc restart
[ ok ] Stopping remote control daemon(s): LIRC:.
[ ok ] Loading LIRC modules:.
[ ok ] Starting remote control daemon(s) : LIRC :.
$ irsend list iRobot_Roomba ""
irsend: 0000000000000001 left
irsend: 0000000000000002 forward
irsend: 0000000000000003 right
irsend: 0000000000000004 spot
irsend: 0000000000000005 maxdock
irsend: 0000000000000006 small
irsend: 0000000000000007 medium
irsend: 0000000000000008 largeclean
irsend: 0000000000000009 pause
irsend: 000000000000000a power
irsend: 000000000000000b forwardleft
irsend: 000000000000000c forwardright
irsend: 000000000000000d stop
irsend: 000000000000000e sendall
irsend: 000000000000000f seekdock
irsend: 0000000000000010 virtualwall

It isn't very easy, but pairs of commands like this worked to drive the Roomba:

$ irsend send_start iRobot_Roomba forward
$ irsend send_stop iRobot_Roomba ""
$ irsend send_start iRobot_Roomba forwardright
$ irsend send_stop iRobot_Roomba ""
$ irsend send_start iRobot_Roomba right
$ irsend send_stop iRobot_Roomba ""
$ irsend send_start iRobot_Roomba stop
$ irsend send_stop iRobot_Roomba ""

I can see why people have hooked this up to web interfaces to control their Roombas.

Anyway, with a careful positioning, and a cron job, I could use the Raspberry Pi IR blaster to automatically trigger the Roomba to clean the house on a rota. It would be an expensive way to do it, but I think the Raspberry Pi could also mimic a Roomba Virtual Wall as well.

---

A Japanese-style kotatsu made in Scotland

January 8, 2014, 5:20 am

≫ Next: GY-80 orientation sensor on a Raspberry Pi

≪ Previous: Raspberry Pi IR blaster and Roomba IR codes

$

0

0

Traditional Japanese wooden houses don't have central heating - instead some rooms have air conditioning (イアコン), the toilet seat is usually heated, while the living room often has a kotatsu heated table (炬燵, こたつ). Modern kotatsu heaters are compact electrical units mounted on the underside of a low table, which is then covered with a quilt hanging down to the floor to trap the heat. Family life in winter is centred on the kotatsu, for watching TV, eating dinner, etc - with everyone sat round the table with their legs and lower body nicely warm.

A kotatsu heater is probably my best souvenir purchase from Japan to date. The heaters are small enough to bring back in a suitcase (unlike a complete kotatsu table unit), maybe even in hand luggage? To create a kotatsu here in Scotland I've attached the heater to an Ikea Lacks coffee table, and added a large duvet and voltage transformer:

The kotatsu is a welcome addition to the traditional stone-built Scottish cottage where we live, which is hard to get warm in winter - despite retro-fitted central heating with radiators. If this winter gets really cold, we'll move the kotatsu in front of the open fire place...

Electric Kotatsu Heaters

Nowadays kotatsu heaters are electric units, usually mounted under the table surface within a frame which is covered by the quilt which the table top rests on top of. The main manufacturer selling replacement heaters seems to be Metro Denki Kougyou (メトロ電気工業, or Metro Electrical Manufacturers) whose products also seem to be available as OEM rebadged versions like Yamazen (山善). Metro have a nice English page about their heating elements and their kotatsu heaters.

The current Metro kotatsu heater range are 600W units: MSU-600E(K) with a quartz heater, MHU-600E(K) with a halogen heater, and the MQU-600E(K) with a red quartz heater. These all have U-shaped heating elements with a fan, and have temperature control on the cable itself which is very convenient and an improvement on the older 400W and 500W models like the MS-400HS(K) and MSF-500H(K), where this was on the heater itself - hard to reach under the table.

There are also variants of the current 600W Metro/Yamazen units with more advanced controllers featuring a timer, but I didn't see any of these in stock at the shops I visited.

I bought the MQU-600E(K) with a red quartz heater while in Japan, and brought it back in my suitcase. The unit is designed to fit in a 29x29cm frame, and comes with spacer bars for a larger 31cm frame, and four thumb screws to attach it. According to the label on the back, it was made in Malaysia.

Metro MQU-600E(K) red quartz kotatsu heater kit	Small 'wart' on the red quartz heating element

I was a little worried that there was a defect on the red quartz heating coil - there is a quite visible 'wart' about 2mm in size on the right hand side of the U-shaped coil, especially noticeable once glowing, but apparently this is just a manufacturing artefact.

Note the Metro kotatsu heaters expect the Japanese standard of 100V. Most of the links below are to people running them in USA or Canada (120V) without a transformer, but the heaters probably require a step-down transformer to run in the UK with 230 to 240V. Better safe than sorry.

Other DIY Kotatsu Builds

Super Sailor Mars' kotatsu used a small Ikea Lacks table with the legs cut down (finished version). Similarly Silver Skeeter's kotatsu and Annie's kotatsu project used a large Ikea Lacks table.

Chronicles of a Sleepy Rabite's kotatsu used two Ikea Hemnes tables, 90cm by 90 cm, legs cut down from table being 45cm high to 40cm high. I liked how they made an actual frame for holding the heater - and wondered if this would be possible using the shelf parts from a single Hemnes table instead?

As a final example, Count-Down-Zero built his own kotatsu table from scratch!

Table & Quilt Sizes

Although you can get round kotatsu tables, browsing in-store and online most are 40cm high and either square (75x75cm to 80x80cm) or rectangular (75x105cm to 80x120cm). Ready made kotatsu quilt/futon sets assume this (up to 190x190cm for the square tables, 190x240cm for the rectangular tables), although international postage costs makes buying them online unattractive (and slow).

Cover for square kotatsu table	Cover for rectangular kotatsu table

Based on these sizes, the Ikea Lacks square 78x78cm coffee tables should work well with a standard double bed duvet (200x200cm), even if kept at 45cm high. Going for this smaller square table would therefore have made things quite a lot cheaper as we could have reused existing bed linen.

Instead we opted for the larger Ikea Lacks rectangular 78x118cm coffee table, and therefore needed something bigger for the quilt. Sadly even a UK King sized duvet isn't big enough. However, at 220x240cm the European King sized duvet works - and conveniently Ikea sell these and duvet covers too. I found with the table at its original 45cm height the duvet was only just long enough to touch the ground along the short edges. In addition, I found the table uncomfortably high, so cut the legs by 6cm bringing the effective table height in line with the expected Japanese norm - and ensuring the duvet fits much better.

My Kotatsu

Parts list:

• Kotatsu heater, Metro MQU-600E(K) (5490 Yen, about £35)
• Four corner braces as mounting brackets (£4)
• Screw hook to hold cable in corner of table (£1)
• Table, Ikea Lacks 118x78cm coffee table (£23)
• Duvet quilt, Ikea Euro King "Mysa Stra" 220x240cm, 10.5 tog (£30)
• Duvet cover, Ikea Euro King "Lyckoax" 220x240cm (£50)
• UK to Japanese voltage stepdown transformer, Airlink 750W model (£82 including postage)

As in the Ikea Lacks examples above, rather than having a removable tabletop above a frame holding the heater, this approach mounts the heater directly to the original thick (5cm) table top - and uses what would normally be the coffee table's shelf as a thin (1cm) second table top above the quilt. This works, but to make it more stable a heavier tabletop could be used - or a thinner quilt?

Following the other blogged examples linked to above, I looked for suitable right angle brackets in our local DIY stores. For a flush mounting I wanted a hole about 12mm up, and managed to find a set of 4cm zinc corner brackets which worked perfectly - any larger and they would have stuck out above the heater.

Thumb screw provided with heater, added corner brace	Kotatsu heater attached with four corner braces
Testing the Metro Kotatsu heater, mounted in place	Metro kotatsu heater mounted under Ikea Lacks coffee table

Without the shelf in place to prevent this, the Ikea Lacks table legs are prone to rotate. To prevent this I reused the little right angle brackets Ikea include to attach the shelf to instead lock the table legs in place (see photo below).

Ikea Lack shelf support reused to prevent table legs rotating	6cm offcuts from the hollow Ikea Lack table legs

Note if you do cut the Ikea Lacks table legs, on mine the lower parts are actually hollow with only a thin capping piece inside (see photo above). Perhaps it would have been better to cut off the top, and re-drill the screw hole... hard to say. By cutting the table legs from 40cm to 34cm, this made the final table height 39cm, or including the former-shelf table top about 40cm (plus the quilt), matching most ready made tables on sale in Japan. This also ensured the Euro King duvet touched the ground easily on all sides.

View from under the kotatsu blanket at full power	The bulky step down transformer to run the heater in the UK

The weather so far this January has been quite mild, but we should be ready when it gets colder :)

GY-80 orientation sensor on a Raspberry Pi

January 10, 2014, 3:54 am

≫ Next: Instrumented Telescope with Raspberry Pi and orientation sensor

≪ Previous: A Japanese-style kotatsu made in Scotland

$

0

0

As I don't yet have a "Goto Mount" for my telescope, I've spent a frustrating amount of time trying and failing to find objects of interest by star hopping. Perhaps I just need more practice, but if accurate enough, an orientation sensor might give me a shortcut by telling me where my telescope is pointing? (Update - see next blog post.)

There are plenty of guides from people using I2C interface sensors from a Raspberry Pi, so this seemed worth a try. I bought a GY-80 on eBay for £7.50 shipped from China.

GY-80 sensor attached to Raspberry Pi

The GY-80 is tiny, only about 27x17mm in size, and has following I2C sensors:

• HMC5883L (3-Axis Digital Compass), I2C Address 0x1E, datasheet
• ADXL345 (3-Axis Digital Accelerometer), I2C Address 0x53, datasheet
• L3G4200D (3-Axis Angular Rate Sensor / Gyro), I2C Address 0x69, datasheet
• BMP085 (Barometric Pressure / Temperature Sensor), I2C Address 0x77, data sheet

Buying an all-in-one unit may allow a more accurate orientation sensor, but I was also intrigued if the digital compass would be helpful for polar alignment of my equatorial telescope mount?

Raspberry Pi I2C Setup

The Raspberry Pi's I2C interface is disabled by default - and also they switched things round a little in the B revision. See configuring I2C for Raspberry Pi (by Adafruit).

$ sudo emacs /etc/modules

Add the following lines (and reboot for it to take effect):

i2c-bcm2708 

i2c-dev

Check if the I2C modules have been disabled,

$ more /etc/modprobe.d/raspi-blacklist.conf

# blacklist spi and i2c by default (many users don't need them)

blacklist spi-bcm2708

blacklist i2c-bcm2708

If they have (as above), edit the file to comment out those blacklist entries by adding a leading hash.

$ sudo emacs /etc/modprobe.d/raspi-blacklist.conf

Install the I2C tools,

$ sudo apt-get install i2c-tools python-smbus

This checks the driver side of things - there are two potential I2C Linux devices:

$ sudo i2cdetect -l

i2c-0i2c       bcm2708_i2c.0                   I2C adapter

i2c-1i2c       bcm2708_i2c.1                   I2C adapter

Now let's check if there are any I2C devices detected - the exact command differs between the older Raspberry Pi model B with 256MB RAM and no holes,

$ sudo i2cdetect -y 0

     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f

00:          -- -- -- -- -- -- -- -- -- -- -- -- -- 

10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 

20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 

30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 

40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 

50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 

60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 

70: -- -- -- -- -- -- -- --

Or the newer Raspberry Pi revisions with 512MB RAM and two mounting holes:

$ sudo i2cdetect -y 1

     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f

00:          -- -- -- -- -- -- -- -- -- -- -- -- -- 

10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 

20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 

30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 

40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 

50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 

60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 

70: -- -- -- -- -- -- -- -- 

This says that there were no I2C devices found, on either of the possible Linux I2C devices (zero /dev/i2c-0 and one /dev/i2c-1). Which makes sense as I've not connected anything yet.

To avoid having to use sudo all the time to access the I2C device, I did this (log out and log in again for it to take effect):

$ sudo usermod -a -G i2c pi

Hat tip to David Grayson's documentation for his Raspberry C++ code for the MinIMU-9 sensor which is similar to the GY-80.

Hardware

I'm using four jumper cables (red, brown, green and yellow) to connect the GY-80 IMU to the Raspberry Pi GPIO pins (as in the photo above):

• VCC_IN <--> Raspberry Pi GPIO pin 1, 3.3V
• VCC_3.3V <--> Unused
• GND <--> Raspberry Pi GPIO pin 6, Ground
• SCL <--> Raspberry Pi GPIO pin 5, I2C serial clock (SCL)
• SDA <--> Raspberry Pi GPIO pin 3, I2C serial data (SDA)
• M_DRDY (interrupt from HMC5883L magnetometer) <--> Unused
• A_INT1 (interrupt from ADXL345 accelerometer) <--> Unused
• T_INT1 (interrupt from L3G4200 gyroscope) <--> Unused
• P_XCLR (clear BMP085 barometer) <--> Unused
• P_EOC (end of conversion for BMP085 barometer) <--> Unused

Labelled back of GY-80 board	Chips on the front of the GY-80 board

I soldered the pins I was using on the GY-80 board (without this you don't get any connection), and then my Raspberry Pi could detect the four I2C sensors:

$ i2cdetect -y 1

     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f

00:          -- -- -- -- -- -- -- -- -- -- -- -- -- 

10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- 1e -- 

20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 

30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 

40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 

50: -- -- -- 53 -- -- -- -- -- -- -- -- -- -- -- -- 

60: -- -- -- -- -- -- -- -- -- 69 -- -- -- -- -- -- 

70: -- -- -- -- -- -- -- 77

As expected, four I2C devices found, with the published hex identifiers :)

• HMC5883L (3-Axis Digital Compass), I2C Address 0x1E
• ADXL345 (3-Axis Digital Accelerometer), I2C Address 0×53
• L3G4200D (3-Axis Angular Rate Sensor), I2C Address 0×69
• BMP085 (Barometric Pressure / Temperature Sensor), I2C Address 0×77

Data Access

From the very nice Adafruit tutorial for using BMP085 with Raspberry Pi, let's download and run their example Python code:

$ git clone https://github.com/adafruit/Adafruit-Raspberry-Pi-Python-Code.git

Cloning into 'Adafruit-Raspberry-Pi-Python-Code'...

remote: Reusing existing pack: 461, done.

remote: Total 461 (delta 0), reused 0 (delta 0)

Receiving objects: 100% (461/461), 155.96 KiB, done.

Resolving deltas: 100% (196/196), done.

$ cd Adafruit-Raspberry-Pi-Python-Code/Adafruit_BMP085/

And now use Adafruit_BMP085_example.py to access the BMP085 chip's temperature/pressure sensor:

$ python Adafruit_BMP085_example.py 

Temperature: 14.60 C

Pressure:    999.04 hPa

Altitude:    118.99

Those numbers look about right - it is quite cold in this room (thus my wish for a kotatsu in Scotland), atmospheric pressure is about 1000 hPa and my analogue barometer says 997 millibars or hPa, while the altitude isn't far off either.

Adafruit also have example code for the ADXL345 (3-Axis Digital Accelerometer), Adafruit_ADXL345.py on GitHub, I moved the sensor while this was running and the numbers changed:

$ cd ../Adafruit_ADXL345/

$ python Adafruit_ADXL345.py 

[Accelerometer X, Y, Z]

[0, 0, 0]

[42, -31, -269]

[41, -31, -272]

[41, -30, -271]

[41, -31, -273]

[35, -32, -257]

[40, -43, -282]

[28, -27, -253]

[15, -25, -273]

[14, -24, -273]

[16, -26, -274]

^C

Traceback (most recent call last):

  File "Adafruit_ADXL345.py", line 114, in <module>

    sleep(1) # Output is fun to watch if this is commented out

KeyboardInterrupt

I briefly tested the gyroscope using a little test script gyro.py from bashardawood on Github, which gave small numbers at rest, and big numbers when I moved the sensor:

$ python gyro.py 

         7          6         -6

        11          2         -4

         8          4         -5

         9          3         -5

         6          2         -1

        11       -252         -7

         7          1         -3

         7          0         -3

         5          2          1

         6          4         -3

         6         -1         -2

         6          0         -3

         9          0         -5

         6          1          1

        11          4         -3

       114        202        -97

     -3180      -3039        740

     -2965      -4777       1272

       874      -2551        601

      -188      -2221        101

      -833      -1531         93

       363        774       -347

       758       1450      -1096

^C
Traceback (most recent call last):

  File "gyro.py", line 56, in <module>

    sleep(0.02)

KeyboardInterrupt

I also gave the compass a quick test by following Andrew Birkett's blog post on using the HMC5883L. He has some other nice posts on the MPU-6050 gyro and accelerometer and HMC5883L compass, including combining the MPU6050 and HMC5883L for pitch, roll and yaw where he says he hopes to expand this code (on GitHub) to also cover the ADXL345 (accelerometer), the L3G4200D (gyroscope) and the BMP085 (pressure sensor) (Update - Andrew has bought a GY-80 for his Raspberry Pi too.).

Update:
My next blog post talks about using the GY-80 to measure telescope orientation.

Instrumented Telescope with Raspberry Pi and orientation sensor

January 26, 2014, 11:50 am

≫ Next: Curious Rover Tracks at Space Expo 2014

≪ Previous: GY-80 orientation sensor on a Raspberry Pi

$

0

0

A "Push To" telescope mount is like a fully automated "Go To" telescope mount, but without the motors. You must manually move the telescope, but because the telescope knows where it is pointed, you get live tracking telling you where it needs to go.

I'm using a Raspberry Pi with a GY-80 orientation sensor to turn my basic SkyWatcher EQ2 mount into a computer assisted "Push To" telescope - which can pass this information to planetarium software like SkySafari on my iPad/iPhone. To do this I've written a little Python script (telescope_server.py) which runs on the Raspberry Pi, and translates the orientation sensor information into RA/Dec angles. The Raspberry Pi listens to Meade LX200 (or Nexstar) serial protocol commands received over TCP/IP, and responds with the orientation information.

SkySafari Plus v4, showing telescope direction from a Raspberry Pi

Indoor testing has gone well so far... I can rotate the Raspberry Pi and watch the blue cross-hairs on SkySafari change position. The locations look sensible (and drift naturally due to sidereal rotation). There is a bit of jitter which may need some smoothing.

Part of the idea came from reading how easy it is to have SkySafari talking to telescope via a Raspberry Pi running a WiFi to serial port bridge (similar blog post), mimicking SkySafari's expensive but neat SkyFi box. I was also impressed with Simon Box's instrumented Dobsonian telescope (measuring altitude-azimuth angles directly) connected to Stellarium, and Leon Rozengarten's project building an Arduino telescope controller using the HMC6352 and ADXL345 sensors (video, code).

This project meant integrating lots of different stuff - serial communication protocols, I2C sensor chips, Inertial measurement unit (IMU) / Attitude and heading reference system (AHRS) calculations, quaternion mathematics for rotations, sidereal time, angle conversions, etc. Here are a few notes... my Python script telescope_server.py is on GitHub.

Mounting the Raspberry Pi

Because I wanted a case with some form of external mounting, I went for the Cyntech "BerryBlack" Raspberry Pi case - plus the optional SD card cover.  The red and green logo RPi stands out nicely, and the light pipe for the LEDs is very well done. I was able to mount this quite stably to the telescope tube via a piece of wood attached to the camera screw thread on the O-rings.

Two screws ready to hang the Raspberry Pi on	Raspbery Pi attached to SkyWatcher telescope tube

However, for outdoor use, note the Cyntech case is not air or water tight - for a start the slot for the GPIO cable is wide open. Also the two screw slots on the back are not fully enclosed - there is an air/water gap to the back of the board. I may have to do something about this to avoid dew getting inside...

Meade LX200 Protocol

This is a well established and widely used protocol for communicating with a computerised telescope using serial commands. It is also well documented, see Meade Telescope Serial Command Protocol (2010), see also Meade Telescope Serial Command Protocol (2002) and this alternative page (sometimes clearer).

The commercial SkySafari SkyFi box seems to use a standard approach (RFC 2217) for transmitting serial connection data via TCP/IP (i.e. a normal network connection), which can be done in software using ser2net on Linux. This means writing code to listen on a network port for Meade LX200 commands was actually quite straightforward. In my code I focussed on implementing enough of the commands for Sky Safari Plus v4 to connect, set the time and location, get the orientation - and behave nicely if any of the goto or slew commands are sent. SkySafari also handles alignment by sending a sync command to the (Raspberry Pi pretending to be a) telescope.

Celestron Nexstar Protocol

Celestron have released the Nexstar Protocol documentation. It is a similar serial protocol, and works over TCP/IP in the same way. In some ways it seems better designed than the Meade LX200 protocol - for example the RA/Dec angles are always sent as pairs.

Since Sky Safari Plus v4 can also connect using this protocol, I tried this too. Surprisingly SkySafari only uses a small handful of the commands and interestingly does not send sync commands to the telescope - it seems to do a local calibration itself instead. I'm sticking with the Meade LX200 protocol instead (see below for more details).

Measuring the Celestial Angles

The telescope communication protocols use two important celestial angles: the right ascension (equatorial axis) paired with the declination, which must be calculated from the local altitude and azimuth angles taking into account the latitude, longitude and time. See for example sidereal.py for how this works.

I'm using a combined gyroscope/accelerometer/magnetometer orientation sensor. Without caring about the telescope mount type etc, this can give me the altitude and azimuth angles - although most relevant documentation instead talks about yaw, pitch and roll angles.

IMU and AHRS code

Using the axis terminology for planes there are three rotational axes: roll (rotation about X-axis, direction of flight), pitch (lateral rotation about Y-axis), and yaw (rotation about Z-axis). In general planes fly horizontally, so the yaw is typically a compass bearing and maps to the telescope's azimuth. Similar the roll can be interpreted as the rotation of the eyepiece/camera, while pitch would be the  telescope's elevation (i.e. the altitude angle).

For the yaw, the accelerometer is useless (the values don't change, gravity is just down) so we must combine the gyroscope and compass data. For the most part the Earth's magnetic field is nearly horizontal, but I suppose in principle the compass data is also of some limited use for the pitch when pointing roughly North or South. However, for the pitch and roll, it is normal to just combine the accelerometer and gyroscope data.

See for example this page on how a quadcopter can get its orientation, Raspberry Pi AHRS by David Grayson (core code in minimu9-ahrs.cpp), and FireTail AHRS software (for Arduino) based on this (core core in ahrs.cpp, FireTail is an autopilot for RC aircraft). There are lots of cool hobby projects out there using these kinds of sensors!

For the angle calculations I decided to play with quaternions, this page on IMU maths with quarternions was very helpful - as was Christoph Gohlke's Python quarternions code. I'm currently using a simple complementary filter putting 98% of the weighting on the gyroscope, and 2% on the accelerometer and compass. There are more advanced IMU approaches including Sebastian Madgwick's IMU/AHRS sensor fusion algorithm.

Using SkySafari Plus

Here's my SkySafari v4.0.1 telescope setup on the iPad or iPhone:

• Scope Type: Meade LX-200 GPS (see note below)
• Mount Type: Equatorial Push-To (see note below)
• Auto-Detect SkyFi: Off (I'm currently testing via ethernet)
• IP Address: The Raspberry Pi's IP address, or helpfully just the host name
• Port Number: 4030 (default, but must match the Raspberry Pi setting)
• Set Time & Location: On (see note below)
• Readout Rate: 4 per second (default)
• Save Log File: Off

SkySafari Plus v4 on iPad, telescope connection settings	SkySafari Plus v4 on iPad, connected as "Push To" telescope

SkySafari Plus v4 on iPhone, telescope connection settings	SkySafari Plus v4 on iPhone, connected as a "Push To" telescope	SkySafari Plus v4 on iPhone, connected as a "GoTo" telescope

The exact mount type does not seem important, only if it is "Push-To" or "GoTo". If you select "Push-To" then the "GoTo" button and rate control are inactive. If you select "GoTo" these controls are live, and additional Left/Right and Up/Down buttons appear on the side of the screen. Since the iPad/iPhone is multi-touch, you can use these together at the same time. If you did have motors on the telescope connected to the Raspberry Pi, it should be possible to extend telescope_server.py to control the telescope this way.

In order to do the angle conversion, the Raspberry Pi needs to know the location (latitude and longitude) and time zone. If running a Raspberry Pi offline (e.g. from batteries away from the house) it won't know the date and time. Connecting a GPS to the Raspberry Pi is one solution, but from a usability point of view it seems simplest to just set this via SkySafari (especially if using an iPad or iPhone with a GPS).

However, if you configure the Scope Type as "Meade LX-200 Classic" then SkySafari v4 takes an extra 15 seconds or so for the connection. Using one of the other Meade settings like "Meade LX-200 GPS" avoids this and connects really quickly while setting the location and time information. Here's a  sample of the output seen during connection (location redacted) when running my Python script telescope_server.py on a Raspberry Pi:

$ ./telescope_server.py 

Connecting to sensors...

Connected to GY-80 sensor

Opening network port...

Starting up on 192.168.1.102 port 4030

Local site now latitude XX.XXXd, longitude X.XXXd

Local site timezone now -0.0

Local site timezone now -0.0

Requested site time 14:42:20 (TZ -0.0), new offset 1s, total offset 1s

Effective site date/time is 2014-01-25 14:42:20.964108 (local/GMT/UTC)

Requested site date 01/25/14 (MM/DD/YY) gives offset of 0 days

Effective site date/time is 2014-01-25 14:42:21.090983 (local/GMT/UTC)

Oddly, if the Scope Type is set to one of the Celestron NexStar models, then SkySafari v4 doesn't actually seem to try to set the location or time. This is one reason why I'm sticking with the Meade LX200 protocol instead.

With a target selected in SkySafari, pressing the align button should update the telescope mount tracking to be centred there. With the NexStar protocol SkySafari seems to do this itself (and only allow relatively small offsets to be used). With the Meade LX-200 protocol, SkySafari sends the revised orientation to the telescope with a sync command, and the telescope mount itself recalculates the calibration. This seems like a really neat user interface, which Simon Box uses on his project.

The Meade LX200 protocol includes commands for controlling a motorised focuser - but as far as I can see, SkySafari doesn't support this. If it did, I might be tempted to connect my Tasco 1603EF focuser to the Raspberry Pi as well.

To Do List

Improve the Raspberry Pi mounting. It currently has some give, so may need bracing to prevent any knocks while in use throwing off the calibration by a few degrees. Also this is too far away from the eyepiece to connect the Raspberry Pi add-on camera via its ribbon cable, but a USB cable to a web camera or DSLR should be fine...

Sensor calibration, see for example AndrewBirkett's post on calibrating the HMC5883L compass, another interesting post on compass calibration (from a group working on DIY robot lawn mowers), and these maths heavy posts on Gauss-Newton for sphere fitting (part 2, part 3, mcUSense on GitHub).

A refinement (or alternative) would be to capture photos from a webcam or DLSR on the telescope and run a plate solver (e.g. using astrometry.net's software), to report exactly where the telescope is pointed. Plate solvers can be sped up by providing an approximate orientation, so this orientation sensor could help there.

Multi-star calibration, probably with SkySafari as the front end using the Meade LX200 protocol's sync commands. This will be important if the sensor chip's X-axis isn't perfectly aligned with the telescope's line of sight. Initially I'm just use one-star alignment to correct the azimuth angle which depends on the offset between true North and the compass bearing.

Reduce cable clutter by switching from ethernet to wifi, ideally freeing me from the house wifi network. Further reduce cable clutter by tapping a 5V supply for the Raspberry Pi from the 12V supply for the SkyWatcher EQ2 sidereal motor.

And of course, test this outdoors for real... ;)

Curious Rover Tracks at Space Expo 2014

September 5, 2014, 6:33 pm

≫ Next: Ikea ZAISU - Floor chairs for our kotatsu

≪ Previous: Instrumented Telescope with Raspberry Pi and orientation sensor

$

0

0

This week I enjoyed visiting the Space Expo 2014 "The Great Challenge of NASA/JAXA" which is being held 19 July to 23 September at Makuhari Messe (幕張メッセ) in Chiba, Japan.

1/10 size Saturn V model at Space Expo 2014	Space Expo 2014 exhibit floor, with hanging ISS model

Lunokhod ("Moonwalker") model	Curiosity Rover model at Space Expo 2014

Some of the most fun things were the life size models of the Space Shuttle nose section (including toilet) and the Japanese International Space Station (ISS) module - the Japanese Experiment Module (JEM, or Kibo, きぼう, meaning hope). This included the astronaut's entrance with its blue welcome curtain on the "ceiling" and small blue welcome message on the "floor", reading "Welcome to Kibo - please enjoy and relax in this brand new, spacious and the most quietest room in the ISS" (sic; see this guide to the ISS).

Life size Space Shuttle model's flight deck	Life size JEM/Kibo ISS module model with its "veranda"

I was pleasantly surprised to see an exhibit about Felix Baumgartner's Red Bull Stratos jump (lots of photos and Japanese text about this exhibit here). I remember watching this world record breaking sky dive on the internet.

Many of the models and artefacts had a brief English caption, but most of the text was of course in Japanese. Unfortunately for me that meant I could only look at the pictures and models for the Japanese rocketry history and JAXA space missions like Hayabusa which brought back comet dust (with its ion drive).

I found lots of interesting exhibits, but something which caught my eye in particular was the NASA Curiosity Mars Rover model - because one of the interesting design features was wrong...

Curiosity Rover model at Space Expo 2014

There are two things wrong with this, first and most obviously the tracks in the sand are wider than this model rover's wheels, although the zig-zag pattern looks consistent. Maybe the diorama setting was intended for an even bigger model?

Curiosity Rover model wheel and track mismatch

Second, the rover's wheel treads are not uniform - all six wheels bear a pattern (dot dash dash dash; dot dash dash dot; dot dash dot dot) which spells out "JPL" in morse code in the tracks (see this Scientific American article, or this NASA page). This is partly a homage to short for NASA's Jet Propulsion Laboratory in Pasadena, but also has a practical application in helping determine the distance travelled (or amount of wheel slip) by analysis of images of the tracks.

The older Soviet rovers like the Lunokhod shown earlier used a free wheel odometer approach (there was not enough light at the back of the model to photograph the spiked ninth wheel), combined with analysis of ariel photos. This had put the off-Earth rover record at 37.5km but a revised estimate using more accurate imagery put the Lunikhod 2 lunar journey at 42km, which at the time of writing has yet to be beaten.

XCKD Spirit Mars Rover cartoon

I wondered what the Sarcastic Rover (@SarcasticRover) would have as morse code on its wheels? With the XCKD Spirit Mars Rover cartoon in mind, I guessed SOS - and I was close ;)

SarcasticRover (@SarcasticRover) August 9, 2012: Little known fact: The treads on my tires write JPL in morse-code... all except one, which writes "SOS WTF BRB"! twitpic.com/ahearg

Ikea ZAISU - Floor chairs for our kotatsu

February 1, 2015, 8:24 am

≪ Previous: Curious Rover Tracks at Space Expo 2014

$

0

0

A year ago I setup a DIY kotatsu using an Ikea LACK coffee table, but never got a proper futon-mat, nor any Japanese style floor chairs to go with it: 座椅子 (ざいす, or zaisu). I'd been seriously pondering importing zaisu chairs when I stumbled on a blog comment suggesting using the top half of an Ikea swivel chair.

So I went back to the Edinburgh Ikea and attempted to check all their chairs to see which (if any) might be used without legs as a simple zaisu. I came home with a pair of Ikea VÅGSBERG swivel chair shells (and nearly bought the Ikea JULES junior desk chair shell as well - a little small for me), and a new thick rug.

Ikea kotatsu & zaisu: LACK coffee table with Metro heater, VÅGSBERG chairs, ALMSTED rug,  Euro-King size MYSA STRÅ duvet with LYCKOAX cover

Ikea ZAISU

Where Ikea sold a chair and its legs separately, I tried the chair part directly on the store floor. I was looking for something similar to the simple one-piece curved wooden zaisu readily available in Japan which have a flat base.

The Ikea VÅGSBERG (£25 without legs) and Ikea JULES (£10 without legs) were the best bets, stable and reasonably comfy on a hard floor. Note that both have a front lip which will dig into your carpet or rug. I rejected the Ikea VILMAR seat shell (£21 without legs; it rocked left/right), and the Ikea MARTIN seat shell (£10 without legs; it tips over backward very easily).

There were some more expensive possibilities sold with the legs - but most were unsuitable. The Ikea ERLAND (£40) has a curved front lip so would rock left/right. The Ikea TOBIAS (£65) clearly would not work due to where the legs were attached. The Ikea PREBEN (£80) was nice but has a slight bulge in the centre underneath which put me off. I was quite temped by the Ikea BERNHARD bar stool (£100), without the legs the base is almost flat so should be stable on a carpet or rug. One worry with these upholstered chairs is the underneath is not really designed for the kind of wear it would get if used as a zaisu.

Ikea Rugs

For our kotatsu we laid a couple of old blankets on top of the carpet to sit on, supplemented with cushions. I was looking for a nice warm rug, thick enough not to worry about the Ikea chairs not having a perfectly flat base. Our kotatsu was made from the Ikea LACK 118x78cm coffee table, and I was aiming for about another 50cm on each side for people to sit on, meaning a total rug size around 220x180cm. I had looked at the Ikea selection online before hand, but this was something I really wanted to touch (and sit on) before buying.

I was very tempted in store by the Ikea ALMSTED wool rugs, which seem to be about 1cm think and short pile,  available in medium (140x200cm) and large (170x240cm). Confused by conflicting price tags, the floor staff explained that the black and brown versions were being discontinued and reduced - both sizes were on sale at £75 (down from £190 and £300 each online!).

I came home with a large brown Ikea ALMSTED rug, and am pleased to say it fits nicely, the colour seems to go fine with the rest of the room, and it is a big improvement for sitting on directly. The only catch is I'm still looking for some kind of carpet protectors for the table legs...

Large Ikea ALMSTED rug, which I carried through the store on my shoulder (in a poor imitation of Arnie in the film Commando)

This might not impress the Ikea Hackers, but I'm happy, and wrote this post sitting under an "Ikea KOTATSU" in my new "Ikea ZAISU" chair :)