Make no mistake, the Raspberry Pi is an excellent piece of equipment.
Like any device, it has its limitations, and like any device, there are ways to expand those limitations with clever use of hardware and software.
One of the limitations is the number of communication pins available to the user without using an GPIO expander.
I want to perform a large number of sensor readings and position actuator operations using the Pi. I want to simplify the software that runs those actuators and sensors. Essentially, I want a much more powerful system controlling my microscope.
I can do this in two ways - one is to scrap the idea of using the Raspberry Pi, and to install a big, custom-made control system. The other is to farm out part of the computational load to other, small computers.
The first option sounds expensive, and will require everything to be written as a monolithic system - one that will require a lot of re-writing every time I want to make a change.
The second option, however ...
Enter the Arduino nano. This is a "single chip" solution - it is actually a tiny PCB populated with an AT Mega microcontroller, ancillary circuitry and a set of pins that turns the surface mounted device into a DIP package with a couple of connectors on top.
Programmed in a dedicated version of C, the device is all about sensors and control actuation. It is fast, it is cheap and, above all, can keep track of several stepper-motors, travel limit switches and indicator lamps (LEDs).
Thus, each cluster of stepper motors in this project will be overseen by an Arduino, keeping the workload of the Pi neatly centred on the task of running the microscope.
Of course, this means learning yet another programming language, but at least it is based on one that I have used before, if briefly.
Showing posts with label Eyepiece Project. Show all posts
Showing posts with label Eyepiece Project. Show all posts
Wednesday, 1 July 2015
Sunday, 15 February 2015
Eyepiece - absolute position sensing using optical detectors (part 2)
A month ago, I discussed the idea of using an old USB mouse as a motion sensor.
One of the problems that I have been wrestling with is that reading the data stream output by the mouse will hang the process if there is no data (i.e. no changes), until data is presented to the reading program.
Finally, in desperation, I tried splitting the process of reading the mouse data from the process of actually using it. Success in using a system that I'm still not terribly confident with to perform a fairly esoteric job feels good.
The operating system (Raspian Linux) treats the data flow between the OS and devices as file objects, which means that you can simply open the device interface file and read from or write to the device as though it were a binary file.
By opening a text file in another location and writing the appropriate data to it allows the data stream from the mouse to be buffered so that it can be read asynchronously, on demand and the end of file detected - the virtual device file doesn't allow this luxury as there is no EOF marker.
In order to get this to work, I wrote a simple device driver program in python, and set it to work as a background process, a second program can pick up the pre-processed data from the mouse whenever it is required.
The simple proof of concept flushes the file occasionally when the mouse is idling. The mouse driver opens the communication file whenever it is ready to write data and closes it immediately after writing. The reader program simply echoes the mouse data on-screen and occasionally flushes the file in order to ensure that it doesn't become an unwieldy size.
Because of the tendency of SD cards to have a limited operational lifespan, it is important that the data files be on a remote or an external hard drive.
So, the programs:
The Mouse Driver - the original, simple file that needs a bit of work, but essentially works as-is.
In theory, this system could be used to make precise measurements of the relative motion of mouse and surface, though the need for careful tracking and conversion of mickeys (mouse pixels) to millimetres is fraught with difficulty. Theoretically, this could take the place of a binary scale for sensing the position of the specimen stage for macro focusing.
Note that /$.m55.eyepiece.remote/ is the path to a network shared drive, and is not located on the Raspberry Pi's SD card system drive.
One of the problems that I have been wrestling with is that reading the data stream output by the mouse will hang the process if there is no data (i.e. no changes), until data is presented to the reading program.
Finally, in desperation, I tried splitting the process of reading the mouse data from the process of actually using it. Success in using a system that I'm still not terribly confident with to perform a fairly esoteric job feels good.
The operating system (Raspian Linux) treats the data flow between the OS and devices as file objects, which means that you can simply open the device interface file and read from or write to the device as though it were a binary file.
By opening a text file in another location and writing the appropriate data to it allows the data stream from the mouse to be buffered so that it can be read asynchronously, on demand and the end of file detected - the virtual device file doesn't allow this luxury as there is no EOF marker.
In order to get this to work, I wrote a simple device driver program in python, and set it to work as a background process, a second program can pick up the pre-processed data from the mouse whenever it is required.
The simple proof of concept flushes the file occasionally when the mouse is idling. The mouse driver opens the communication file whenever it is ready to write data and closes it immediately after writing. The reader program simply echoes the mouse data on-screen and occasionally flushes the file in order to ensure that it doesn't become an unwieldy size.
Because of the tendency of SD cards to have a limited operational lifespan, it is important that the data files be on a remote or an external hard drive.
So, the programs:
The Mouse Driver - the original, simple file that needs a bit of work, but essentially works as-is.
#!/usr/bin/pythonThis program is launched using a single-line BASH script:
# Filename: udrv.Mouse.py
# Mouse comms driver program (proof of concept)
# Core logic courtesy of PeterO on the Raspberry Pi forum.
# http://www.raspberrypi.org/forums/viewtopic.php?f=63&t=80987
import struct
import binhex
import sys
# You'll need to find the name of your particular mouse to put in here...
mFile = open("/dev/input/by-id/usb-05e3_USB_Mouse-event-mouse","rb")
# And this is the communications file
mLog = open("/$.m55.eyepiece.remote/udrv.mouse.comm", "w")
mLog.close()
while True:
mChunk = mFile.read(16)
(mType,mCode,mValue) = struct.unpack_from('hhi', mChunk, offset=8)
if mType == 1 or mType ==2:
# These represent button-click and movement messages
mRes = str(mType) + ", "+str(mCode) + ", " + str(mValue)
mRes = mRes + chr(13) + chr(10)
mLog = open("/$.m55.eyepiece.remote/udrv.mouse.comm", "a")
mLog.write(mRes)
mLog.close()
#/bin/bashAnd finally, the reader program:
# Filename: script.mousestart.sh
# Simple script to start the mouse driver program
python /$.m55.eyepiece.remote/udrv.mouse.py
quit
#!/usr/bin/pythonThere is no attempt at locking the file by the during a write operation, so some care is required in operation. This is not a substitute for a GUI mouse driver, after all.
# Filename: udrv.MouseComms.py
# Mouse comms reader program (proof of concept)
# Core logic courtesy of PeterO on the Raspberry Pi forum.
# http://www.raspberrypi.org/forums/viewtopic.php?f=63&t=80987
import struct
import binhex
import sys
import subprocess
import time
mLog = open("/$.m55.eyepiece.remote/udrv.mouse.comm", "r")
mActive = False
mCount = 0
mTime = time.clock()
while True:
mBuff = mLog.readline()
if mBuff != "":
mActive = True
mTime = time.clock()
print mTime, mBuff
else:
mCount = time.clock() - mTime
if mActive and mCount > 0.1: # Flush the buffer.
print "Flushing buffer"
mLog.close()
mLog = open("/$.m55.eyepiece.remote/udrv.mouse.comm", "w")
mLog.close()
mLog = open("/$.m55.eyepiece.remote/udrv.mouse.comm", "r")
mActive = False
In theory, this system could be used to make precise measurements of the relative motion of mouse and surface, though the need for careful tracking and conversion of mickeys (mouse pixels) to millimetres is fraught with difficulty. Theoretically, this could take the place of a binary scale for sensing the position of the specimen stage for macro focusing.
Note that /$.m55.eyepiece.remote/ is the path to a network shared drive, and is not located on the Raspberry Pi's SD card system drive.
Monday, 26 January 2015
Eyepiece - Back to the camera.
This afternoon I reached the point of being able to test the Raspberry Pi camera module against one of the eyepieces from the microscope.
In order to do this, I kludged together an illuminator (using four white LEDs) and a printed image that sits in the graticule tray - an object that is in focus at the same time as the image from the microscope objective.
By holding the objective to the camera, I was able to estimate the separation between camera lens and eyepiece required for the best possible image - as well as to determine whether any intermediate lenses would be required.
The test was unexpectedly an immediate success. With the camera sat against the built in eye-cup on the eyepiece (a Vickers x10 Complan), the (circular) test image almost filled the height of the rectangular image - meaning that with a little tweaking and with the creation of a suitable adaptor, the camera is essentially able to be used as-is.
In the graticule image above, the edge of the graticule mount covers the edge of the image - the fine, black line representing the expected limit of the vignette.
As you can see, the test image is rather grainy - this is because the image is of a tiny picture printed out using an ink jet printer. There is also some distortion, but this is mainly due to the graticule being somewhat misshapen.
A blurred artifact (from the 3 o'clock to the 6 o'clock position) is the visual effect of some de-lamination in this eyepiece's optics.
The image is not properly centred because the test system was simply being held together in my hand. The pale mark in the lower left of the image is a reflection off of the inside of the eye-cup.
Conclusion:
This test was more successful than anticipated, and will warrant a proper adaptor being made in the near future.
Next steps:
A paper and card prototype adaptor will be used to perform more sophisticated testing and adjustment of the optical system. An acrylic design will follow, which will be capable of supporting the camera and associated computer while attached to the eyepiece.
In order to do this, I kludged together an illuminator (using four white LEDs) and a printed image that sits in the graticule tray - an object that is in focus at the same time as the image from the microscope objective.
By holding the objective to the camera, I was able to estimate the separation between camera lens and eyepiece required for the best possible image - as well as to determine whether any intermediate lenses would be required.
The test was unexpectedly an immediate success. With the camera sat against the built in eye-cup on the eyepiece (a Vickers x10 Complan), the (circular) test image almost filled the height of the rectangular image - meaning that with a little tweaking and with the creation of a suitable adaptor, the camera is essentially able to be used as-is.
 |
| The graticule image - this was scaled down to a 19.5mm diameter. |
 |
| First Test - captured image through the eyepiece |
A blurred artifact (from the 3 o'clock to the 6 o'clock position) is the visual effect of some de-lamination in this eyepiece's optics.
The image is not properly centred because the test system was simply being held together in my hand. The pale mark in the lower left of the image is a reflection off of the inside of the eye-cup.
Conclusion:
This test was more successful than anticipated, and will warrant a proper adaptor being made in the near future.
Next steps:
A paper and card prototype adaptor will be used to perform more sophisticated testing and adjustment of the optical system. An acrylic design will follow, which will be capable of supporting the camera and associated computer while attached to the eyepiece.
Thursday, 15 January 2015
Eyepiece - absolute position sensing using optical detectors.
There are several ways of locating the relative positions of two mechanical components:
For the macro focus mechanism, using a datum and calculation doesn't really allow for the possibility of disturbing the set up, either while changing optics, swapping samples or drift due to the heavy sample stage that has to be braked.
Sonar and laser rangefinders are both relatively inaccurate and are both expensive and challenging to implement satisfactorily.
Laser interferometry is an excellent solution for extremely precise positioning, but is unnecessarily complex for this project. Interpolation between the 1mm marks of the scale will be done by counting stepper motor steps.
An optical scale can easily be designed and sensors may be recovered from such devices as old computer mice. This is the route I have settled upon.
Being something of a pack rat, I had half a dozen defunct mice of various types - most of which contained one or more optical interrupters (quadrature encoders for mouse ball position etc). These interrupters comprise an Infra Red LED and a dual Infra Red sensing Phototransistor - as two discrete components.
Unsoldering these is a simple task, yielding about 20 detector pairs.
How does an optical scale work?
Firstly, there are two geometries available - reflective and transmission.
The reflective detector shines a light (usually Infra Red) on a scale and the light level between white (reflective) and black (absorptive) represents a binary one or zero.
The transmissive system simply shines the light through a sheet of paper or plastic. Where the material is opaque, the light is interrupted and where transparent, the light is transmitted - representing the binary value as before.
By printing a grid pattern of black and white representing binary values from, for example, |000000| to |111111| (six bits), a position scale of zero to sixty three positions may be measured. 8 bits give a range of zero to 255. The rectangles on the scale (left) are 0.8mm high on a 1mm pitch, while the ladder on the far left has rectangles 0.25mm high at 1mm intervals - this represents the millimetre datum, and should ensure that the position detection is accurate to ±0.25mm.
Arranging for reliable reflective detection of these small panels is beyond most domestic electronics workshops. On the other hand, transmissive detection is as simple as positioning LEDs and detectors on opposite sides of a piece of paper and getting everything properly aligned. In theory, it should be possible, with the salvaged detectors, to measure down to 0.25mm, though this is rather more precise than the application actually calls for.
Precision - I may test out using a thinner mm scale ladder, or even go to 0.5mm resolution
The Electronics:
Testing the concept (as well as the individual devices) requires a simple circuit to be built. Because the sensitivity may need to be tweaked, I built this using breadboard with a suitable 5V power supply.
The two phototransistors in the package are connected in parallel, giving a degree of redundancy.
The IR LED (D1) illuminates the phototransistors (PH1.1 & PH1.2).
When illuminated, they begin to conduct through R2, pulling the input of U1.n low. U1 is a hex inverter with Schmitt inputs (74LS14), which removes the uncertainty of when the device switches between .true. and .false.
The LED (D2) provides visual confirmation of the output state of U1.n.
The value of R2 alters the sensitivity of the input - values between 82kΩ ind 180kΩ will adjust between insensitivity and extreme sensitivity respectively. 82kΩ is about right for the test IR LED that I was using.
Bit(n) represents the output to the computer.
Choice of material:
Printing the scale using an ink jet printer resulted in a much finer line, but an almost unusable scale due to the relatively low opacity of the ink. Doing the same using a laser printer resulted in an excellent dark/light sensitivity. Both scales were printed on standard photocopier paper.
Colour Scheme:
The scale is actually designed as a white panel = binary zero. This is because a generally dark scale produces less glare (crosstalk) between channels. Because of the way the detector and Schmitt input operate, this translates correctly, resulting in the output being a binary number of millimetres from the datum (maximum elevation of the microscope stage).
Mechanical support:
A paper scale, while easy to produce, is rather too flimsy for this application, thus I will, in the near future, try the transmissive detector using a scale that has been put through a laminator, otherwise, supporting it with a clear acrylic panel will be necessary.
Computer Input:
I have a Quick2Wire interface that will connect to the Raspberry Pi, and, using the port expander, will allow a number of additional interfaces to be connected while providing some protection for the GPIO pins of the Pi.
- Having a datum position (micro-switch, optical interrupter etc.) and calculating the position by measuring the number of pulses (opto-interrupter, motor steps etc.) taken to get somewhere.
- Using an ultrasonic measuring device (sonar)
- Using a laser measuring device (laser rangefinder)
- Using laser interferometry
- Using an optical scale and a series of sensors.
For the macro focus mechanism, using a datum and calculation doesn't really allow for the possibility of disturbing the set up, either while changing optics, swapping samples or drift due to the heavy sample stage that has to be braked.
Sonar and laser rangefinders are both relatively inaccurate and are both expensive and challenging to implement satisfactorily.
Laser interferometry is an excellent solution for extremely precise positioning, but is unnecessarily complex for this project. Interpolation between the 1mm marks of the scale will be done by counting stepper motor steps.
An optical scale can easily be designed and sensors may be recovered from such devices as old computer mice. This is the route I have settled upon.
Being something of a pack rat, I had half a dozen defunct mice of various types - most of which contained one or more optical interrupters (quadrature encoders for mouse ball position etc). These interrupters comprise an Infra Red LED and a dual Infra Red sensing Phototransistor - as two discrete components.
Unsoldering these is a simple task, yielding about 20 detector pairs.
How does an optical scale work?
Firstly, there are two geometries available - reflective and transmission.
The reflective detector shines a light (usually Infra Red) on a scale and the light level between white (reflective) and black (absorptive) represents a binary one or zero.The transmissive system simply shines the light through a sheet of paper or plastic. Where the material is opaque, the light is interrupted and where transparent, the light is transmitted - representing the binary value as before.
By printing a grid pattern of black and white representing binary values from, for example, |000000| to |111111| (six bits), a position scale of zero to sixty three positions may be measured. 8 bits give a range of zero to 255. The rectangles on the scale (left) are 0.8mm high on a 1mm pitch, while the ladder on the far left has rectangles 0.25mm high at 1mm intervals - this represents the millimetre datum, and should ensure that the position detection is accurate to ±0.25mm.
Arranging for reliable reflective detection of these small panels is beyond most domestic electronics workshops. On the other hand, transmissive detection is as simple as positioning LEDs and detectors on opposite sides of a piece of paper and getting everything properly aligned. In theory, it should be possible, with the salvaged detectors, to measure down to 0.25mm, though this is rather more precise than the application actually calls for.
Precision - I may test out using a thinner mm scale ladder, or even go to 0.5mm resolution
The Electronics:
Testing the concept (as well as the individual devices) requires a simple circuit to be built. Because the sensitivity may need to be tweaked, I built this using breadboard with a suitable 5V power supply.
 |
| Optical position test circuit |
The IR LED (D1) illuminates the phototransistors (PH1.1 & PH1.2).
When illuminated, they begin to conduct through R2, pulling the input of U1.n low. U1 is a hex inverter with Schmitt inputs (74LS14), which removes the uncertainty of when the device switches between .true. and .false.
The LED (D2) provides visual confirmation of the output state of U1.n.
The value of R2 alters the sensitivity of the input - values between 82kΩ ind 180kΩ will adjust between insensitivity and extreme sensitivity respectively. 82kΩ is about right for the test IR LED that I was using.
Bit(n) represents the output to the computer.
Choice of material:
Printing the scale using an ink jet printer resulted in a much finer line, but an almost unusable scale due to the relatively low opacity of the ink. Doing the same using a laser printer resulted in an excellent dark/light sensitivity. Both scales were printed on standard photocopier paper.
Colour Scheme:
The scale is actually designed as a white panel = binary zero. This is because a generally dark scale produces less glare (crosstalk) between channels. Because of the way the detector and Schmitt input operate, this translates correctly, resulting in the output being a binary number of millimetres from the datum (maximum elevation of the microscope stage).
Mechanical support:
A paper scale, while easy to produce, is rather too flimsy for this application, thus I will, in the near future, try the transmissive detector using a scale that has been put through a laminator, otherwise, supporting it with a clear acrylic panel will be necessary.
Computer Input:
I have a Quick2Wire interface that will connect to the Raspberry Pi, and, using the port expander, will allow a number of additional interfaces to be connected while providing some protection for the GPIO pins of the Pi.
Friday, 9 January 2015
Eyepiece - more on the Vickers M55 microscope
I spent time yesterday building a chassis for the stepper mechanism. Because the microscope has been modified to accept a bracket for a video camera (one of the big, old, heavy ones - which I do not have), I was able to use the mounting for this to attach the base plate. This plate is 2.5mm aluminium salvaged from an old piece of equipment. It will need a coat of the appropriate colour paint before it is finished.
Some drilling and fiddling, and I have a removable base plate with a stepper mounted on it. Since I'm still waiting for the electronic parts to arrive, that is as far as I can go.
Once the chassis was built, I turned my thoughts to the macro lenses. Swapping the micro optics for macro optics is a five-minute exercise. I tried the incident illumination, and found that it is useless for looking at rocks (no surprises there), so I got out the oblique illumination attachment (a mirror on a simple swivel mount).
This is the first time I have attempted to use oblique illumination using the macro lenses, and discovered that the adjustment screw was sheared off.
An hour later, I had removed the broken piece of screw and had to find a 6BA screw to replace it with. Luckily, I have a big pile of old clock-repair parts, including a selection of BA size screws.
(The pictures show the oblique illumination mirror with the new part - which needs a coat of paint)
Some work with a countersink and emery-paper on an old bronze motor bush produced a respectable head of the correct size to turn a long countersunk screw into a short screw with a smooth knob for a head.A spot of steel epoxy permanently fixed the screw in the knob (with an exposed slot head to enable release with a screwdriver, if necessary).
Now, the way the micro-focus mechanism operates is by moving the objective lens up and down - which has a coarse focus knob and a fine focus knob (which now has a stepper motor attached.
The macro mechanism, on the other hand, moves the specimen stage up and down, using a large knob and a friction brake. This is also the knob that is used to move the stage out of the way in order to swap the optics.
This knob is big and rather stiff (it operates a physically heavy piece of equipment, after all), and if I want to do image stacking using the macro system, it means another stepper to operate this knob. I also need to be able to lock the position as the stage is heavy enough that the mechanism drifts downward quite rapidly when released with the locking knob released.
The range of motion is enormous (15mm between micro examination and x5 macro) - and this means that I will need to be able to adjust and lock the stage elevation automatically. Since I am planning on using the macro optics a lot, then this is a change critical to the project.
I have managed to find a higher torque stepper in my parts bin (I may have something even heavier duty knocking around - somewhere), and so I will try that for size.
 | |
| The fine focus knob |
 |
| - with the old video-camera mounting base attached |
 |
| The stepper chassis attached with mounted stepper motor and drive belt. |
Some drilling and fiddling, and I have a removable base plate with a stepper mounted on it. Since I'm still waiting for the electronic parts to arrive, that is as far as I can go.
Once the chassis was built, I turned my thoughts to the macro lenses. Swapping the micro optics for macro optics is a five-minute exercise. I tried the incident illumination, and found that it is useless for looking at rocks (no surprises there), so I got out the oblique illumination attachment (a mirror on a simple swivel mount).
This is the first time I have attempted to use oblique illumination using the macro lenses, and discovered that the adjustment screw was sheared off.
An hour later, I had removed the broken piece of screw and had to find a 6BA screw to replace it with. Luckily, I have a big pile of old clock-repair parts, including a selection of BA size screws.
(The pictures show the oblique illumination mirror with the new part - which needs a coat of paint)
Now, the way the micro-focus mechanism operates is by moving the objective lens up and down - which has a coarse focus knob and a fine focus knob (which now has a stepper motor attached.
The macro mechanism, on the other hand, moves the specimen stage up and down, using a large knob and a friction brake. This is also the knob that is used to move the stage out of the way in order to swap the optics.
This knob is big and rather stiff (it operates a physically heavy piece of equipment, after all), and if I want to do image stacking using the macro system, it means another stepper to operate this knob. I also need to be able to lock the position as the stage is heavy enough that the mechanism drifts downward quite rapidly when released with the locking knob released.
The range of motion is enormous (15mm between micro examination and x5 macro) - and this means that I will need to be able to adjust and lock the stage elevation automatically. Since I am planning on using the macro optics a lot, then this is a change critical to the project.
I have managed to find a higher torque stepper in my parts bin (I may have something even heavier duty knocking around - somewhere), and so I will try that for size.
Sunday, 4 January 2015
Eyepiece - on stepper drivers and motion sensors
I have spent the past couple of days designing the electronics by which to control the stepper motor that will be used to operate the fine focus of the microscope for image stacking.
The mechanism has an extremely free operation and the end stops cause the knobs to continue to rotate through use of a fairy stiff friction clutch.
The output torque of a stepper motor is roughly proportional to the current through the windings, and thus to the voltage of the electrical supply.
The motor that I have has 40Ω windings, and is designed for use at somewhere around 20V - therefore, it would be possible to drive the stepper at a lower voltage, set so that the motor stalls at the end of the focus mechanism's travel.
Stalling a stepper motor (difficult to do when fully powered) doesn't damage the motor or the drive circuitry (one of the reasons for my choice of stepper rather than a DC servo motor).
I am still refining the design and features of the board which will be used to drive the stepper motor.
While on the subject of the focus mechanism, I wanted to be able to detect when the motor stalled. One way would be to use an optical encoder, either attached to the motor or to the focus knob, but the problem remains that if the knob bounces as the motor state changes, that small motion could well be registered as continued movement.
To prevent this, a quadrature encoder would be required - and thus calling for its own additional circuitry to determine whether the motor was stalled or not.
The alternative would be to use dome form of optical device to detect the net motion of the knurling on the knob.
Now, what device do we all use to detect relative motion?
A clue, most of them are attached to our computers and located alongside the keyboard.
A cheap mouse will do the job, and ten minutes effort with Google provided sufficient information to be able to, theoretically, access a USB mouse directly from software.
Edit:
I have now tested this idea - and, not only does it work, but it detects the three microswitches, too!
Because of the way Plug 'n' Play works, multiple mouse devices are separately enumerated, and their names placed in the appropriate directory
/dev/input/by-id/
The python program that is used as a proof of concept is:
#!/usr/bin/python
# Core logic courtesy of PeterO on the Raspberry Pi forum.
# http://www.raspberrypi.org/forums/viewtopic.php?f=63&t=80987
import struct
import binhex
# You'll need to find the name of your particular mouse to put in here...
file = open("/dev/input/by-id/usb-192f_USB_Optical_Mouse-event-mouse","rb")
while True:
byte = file.read(16)
# h = ":".join("{:02x}".format(ord(c)) for c in byte)
# print "byte=",h
(type,code,value) = struct.unpack_from('hhi', byte, offset=8)
if type == 1 and value == 1:
if code == 272:
print "LEFT PRESS",
if code == 273:
print "RIGHT PRESS",
if code == 274:
print "CENTRE PRESS",
print code
if type == 2:
if code == 0:
print "MOVE L/R",value
if code == 1:
print "MOVE U/D",value
if type == 0:
print "Clear Event", type, code, value
if (type <> 0) and (type <> 1) and (type <> 2) :
print "other event", type, code, value
While I like to build my electronics on custom printed circuit boards and, indeed, have the software to do so, it tends to be somewhat expensive - especially should any error be made in the board design.
Since it is unlikely that this electronic design will ever be anything but a one-off, I have decided that I will be building using either proto-board or strip-board.
That is, to say, AFTER testing the design out using breadboard!
The mechanism has an extremely free operation and the end stops cause the knobs to continue to rotate through use of a fairy stiff friction clutch.
The output torque of a stepper motor is roughly proportional to the current through the windings, and thus to the voltage of the electrical supply.
The motor that I have has 40Ω windings, and is designed for use at somewhere around 20V - therefore, it would be possible to drive the stepper at a lower voltage, set so that the motor stalls at the end of the focus mechanism's travel.
 |
| Preliminary circuit design - stepper controller |
Stalling a stepper motor (difficult to do when fully powered) doesn't damage the motor or the drive circuitry (one of the reasons for my choice of stepper rather than a DC servo motor).
I am still refining the design and features of the board which will be used to drive the stepper motor.
_______________________________
While on the subject of the focus mechanism, I wanted to be able to detect when the motor stalled. One way would be to use an optical encoder, either attached to the motor or to the focus knob, but the problem remains that if the knob bounces as the motor state changes, that small motion could well be registered as continued movement.
To prevent this, a quadrature encoder would be required - and thus calling for its own additional circuitry to determine whether the motor was stalled or not.
The alternative would be to use dome form of optical device to detect the net motion of the knurling on the knob.
Now, what device do we all use to detect relative motion?
A clue, most of them are attached to our computers and located alongside the keyboard.
A cheap mouse will do the job, and ten minutes effort with Google provided sufficient information to be able to, theoretically, access a USB mouse directly from software.
Edit:
I have now tested this idea - and, not only does it work, but it detects the three microswitches, too!
Because of the way Plug 'n' Play works, multiple mouse devices are separately enumerated, and their names placed in the appropriate directory
/dev/input/by-id/
The python program that is used as a proof of concept is:
#!/usr/bin/python
# Core logic courtesy of PeterO on the Raspberry Pi forum.
# http://www.raspberrypi.org/forums/viewtopic.php?f=63&t=80987
import struct
import binhex
# You'll need to find the name of your particular mouse to put in here...
file = open("/dev/input/by-id/usb-192f_USB_Optical_Mouse-event-mouse","rb")
while True:
byte = file.read(16)
# h = ":".join("{:02x}".format(ord(c)) for c in byte)
# print "byte=",h
(type,code,value) = struct.unpack_from('hhi', byte, offset=8)
if type == 1 and value == 1:
if code == 272:
print "LEFT PRESS",
if code == 273:
print "RIGHT PRESS",
if code == 274:
print "CENTRE PRESS",
print code
if type == 2:
if code == 0:
print "MOVE L/R",value
if code == 1:
print "MOVE U/D",value
if type == 0:
print "Clear Event", type, code, value
if (type <> 0) and (type <> 1) and (type <> 2) :
print "other event", type, code, value
_______________________________
While I like to build my electronics on custom printed circuit boards and, indeed, have the software to do so, it tends to be somewhat expensive - especially should any error be made in the board design.
Since it is unlikely that this electronic design will ever be anything but a one-off, I have decided that I will be building using either proto-board or strip-board.
That is, to say, AFTER testing the design out using breadboard!
Monday, 29 December 2014
Eyepiece - some thoughts on GUI interfaces using Python
What a nightmare ...
As a long-term user of IDE (Integrated Development Environment) programming tools, and specifically Visual Basic on Windows, I'm used to being able to drag and drop controls, insert modules and pop-up forms and so on without having to write more than a line or two of code - and to then to add the functionality wherever I need.
With Python, it seems that everything has to be hand-coded using library classes that have multiple rules about how anything is placed, a hierarchy of grids, stickies and classes that are ill-documented. It felt like I was programming back in the 1970's without the benefit of being able to preview what I was doing.
the standard tk (Tkinter) library that is an integral part of Python is a hoary old set of widgets (graphical control objects) and cruft that requires some arcane knowledge and a lot of practice to use - especially since anything more complex than a 'Hello World' application seems to require swathes of code to manage.
Indeed, it was to the point where I was considering using Curses - a kind of text-mode interface that creates forms just using colour and text (including the box-drawing characters).
Then I found wx.Python - a somewhat more modern GUI interface with a larger choice of widgets. It still requires a library of arcane knowledge, and the documentation is just as confusing to a Python newbie like me.
Google (my best friend) turned up a number of IDEs for Python, and specifically for wx.Python. Some were form generators, others were supposedly IDEs
I tried several that completely failed to do anything useful - either they didn't load, or they didn't do what it said on the box.
Then I found Boa Constructor - a Windows IDE specifically for Python (Boa and Python are both big snakes of the constrictor variety). Boa not only does what it says on the virtual box, it is free, and it resembles nothing more nor less than the old Delphi interface, using a mosaic of windows rather than a single one with multiple panes.
The range of widgets is excellent (and can be expanded), it generates the necessary code on the fly and will allow a preview. The form designer is also drag and drop (a bit clunky in places, but still excellent). It even allows you to preview the controls in action while designing the form.
I now have an interface of sorts, but I still have to figure out where to put the various bits and pieces of actual code. What's more, the same code runs on both Windows and the Raspberry Pi ...
As you can see, the windows interface features the nice, rounded corners, semi-transparent top-bar and windows-style controls, while -
the Raspberry Pi's Linux interface has the square frame, foursquare controls and the same look and feel as the operating system's GUI (LXDE in this case). On a full Linux system where speed, memory and disc space was less of an issue, the window would take on the look and feel of whatever Desktop Environment was in use be it LXDE, Gnome, KDE etc.
Incidentally, while the interface reacts to input, it doesn't actually do anything useful - yet.
Boa Constructor can be found at:
Boa Constructor at Sourceforge
As a long-term user of IDE (Integrated Development Environment) programming tools, and specifically Visual Basic on Windows, I'm used to being able to drag and drop controls, insert modules and pop-up forms and so on without having to write more than a line or two of code - and to then to add the functionality wherever I need.
With Python, it seems that everything has to be hand-coded using library classes that have multiple rules about how anything is placed, a hierarchy of grids, stickies and classes that are ill-documented. It felt like I was programming back in the 1970's without the benefit of being able to preview what I was doing.
the standard tk (Tkinter) library that is an integral part of Python is a hoary old set of widgets (graphical control objects) and cruft that requires some arcane knowledge and a lot of practice to use - especially since anything more complex than a 'Hello World' application seems to require swathes of code to manage.
Indeed, it was to the point where I was considering using Curses - a kind of text-mode interface that creates forms just using colour and text (including the box-drawing characters).
Then I found wx.Python - a somewhat more modern GUI interface with a larger choice of widgets. It still requires a library of arcane knowledge, and the documentation is just as confusing to a Python newbie like me.
Google (my best friend) turned up a number of IDEs for Python, and specifically for wx.Python. Some were form generators, others were supposedly IDEs
I tried several that completely failed to do anything useful - either they didn't load, or they didn't do what it said on the box.
Then I found Boa Constructor - a Windows IDE specifically for Python (Boa and Python are both big snakes of the constrictor variety). Boa not only does what it says on the virtual box, it is free, and it resembles nothing more nor less than the old Delphi interface, using a mosaic of windows rather than a single one with multiple panes.
The range of widgets is excellent (and can be expanded), it generates the necessary code on the fly and will allow a preview. The form designer is also drag and drop (a bit clunky in places, but still excellent). It even allows you to preview the controls in action while designing the form.
I now have an interface of sorts, but I still have to figure out where to put the various bits and pieces of actual code. What's more, the same code runs on both Windows and the Raspberry Pi ...
.png) |
| Version 0.01 prototype interface on Windows 7 |
.png) | |
| Version 0.01 prototype interface on Raspberry Pi |
Incidentally, while the interface reacts to input, it doesn't actually do anything useful - yet.
Boa Constructor can be found at:Boa Constructor at Sourceforge
Thursday, 18 December 2014
Eyepiece - Problems and Successes
For some reason during the past couple of days, while trying to get the configuration on the Pi right, the automatic graphical log-in on the console decided that it wasn't going to work - resulting in the display switching off.
I finally discovered that I could disable the graphical desktop on the console and get the screen to remain switched on indefinitely.
Strangely, (or maybe no so strangely) this speeds up the system by a marked amount.
Rather than have a permanent mess of system messages littering the console when not displaying a camera preview, I have created an ASCII-graphic that displays some information and something to identify the appliance.
The version should be shown as v 0.xx.xx, but whenever I get a production system will be the first release.
I have had a chance to play around with the camera - exploring the dozens of settings that can be changed from software. Some highlights are as follows:
The Automatic White Balance has a selection of profiles that will correct for a range of lighting conditions.
There is a setting that allows Dynamic Range Compression - giving an insight into shadows and highlights.
There are settings for Shutter Speed, Film Speed, Colour Saturation, Contrast, Brightness and Sharpness amongst other settings.
It is possible to capture images without any of the usual corrections, indeed, it is possible to capture the whole image effectively as it comes out of the image sensor.
I have started writing the camera control software in Python - a language that I have never used before. I have been pleasantly surprised at how easy it is compared with other languages that I have used.
I have reached the point where the camera is switched on, will display a full-screen preview, will warm up before capturing a series of images (with timestamps on the image and on the file name) and will then switch off the camera.
Next comes the work on the user interface - and a way of setting all the controls without having to type in python commands.
I have turned up a salvaged stepper motor that I will be able to use to drive the fine focus knob. It is rated at 24volts, but it should run at 5v with sufficient torque to turn the knob (a very free motion), and to stall at the ends of the fine focus travel - thus allowing detection of the upper and lower limits of motion.
As it is a 4-phase motor, I will be able to drive it with a unipolar control board (so much simpler than H-bridges).
I finally discovered that I could disable the graphical desktop on the console and get the screen to remain switched on indefinitely.
Strangely, (or maybe no so strangely) this speeds up the system by a marked amount.
Rather than have a permanent mess of system messages littering the console when not displaying a camera preview, I have created an ASCII-graphic that displays some information and something to identify the appliance.
The version should be shown as v 0.xx.xx, but whenever I get a production system will be the first release.
I have had a chance to play around with the camera - exploring the dozens of settings that can be changed from software. Some highlights are as follows:
The Automatic White Balance has a selection of profiles that will correct for a range of lighting conditions.
There is a setting that allows Dynamic Range Compression - giving an insight into shadows and highlights.
There are settings for Shutter Speed, Film Speed, Colour Saturation, Contrast, Brightness and Sharpness amongst other settings.
It is possible to capture images without any of the usual corrections, indeed, it is possible to capture the whole image effectively as it comes out of the image sensor.
I have started writing the camera control software in Python - a language that I have never used before. I have been pleasantly surprised at how easy it is compared with other languages that I have used.
I have reached the point where the camera is switched on, will display a full-screen preview, will warm up before capturing a series of images (with timestamps on the image and on the file name) and will then switch off the camera.
Next comes the work on the user interface - and a way of setting all the controls without having to type in python commands.
I have turned up a salvaged stepper motor that I will be able to use to drive the fine focus knob. It is rated at 24volts, but it should run at 5v with sufficient torque to turn the knob (a very free motion), and to stall at the ends of the fine focus travel - thus allowing detection of the upper and lower limits of motion.
As it is a 4-phase motor, I will be able to drive it with a unipolar control board (so much simpler than H-bridges).
Saturday, 6 December 2014
Eyepiece - an interlude
The new PiCamera has arrived and, at first, I thought that it was dead on arrival ...
For anyone who receives one of these items that doesn't appear to work, you may need to re-seat the ribbon cable at the camera end, and to pop the nano-connector on the board out and back in.
The nano-connector is a little, flat, rectangular connector hidden under the flexi-circuit that emerges from the optical module (the actual camera).
A thumb-nail under the edge of this should separate the two parts, pinch between finger and thumb to re-seat the connector.
Also, for some reason, it takes a few seconds at cold-boot for the Pi to start up with the camera connected.
While I am working with the assembled electronics and doing the prototype work, I needed a temporary case for the camera. An off-cut of black, 1mm art board (cardboard) folded with a suitable hole for the optical module, held together with tape serves well. It is only to provide protection from handling (electrostatic discharge and stray signals from fingers), so it doesn't need to be a permanent (or even terribly attractive) feature.
I have also turned up a computer-mouse sized, wired, remote module already fitted with a push-to-make switch (to use as a shutter-release) and a neon which will accept a LED 'ready' indicator. The curly cable from an old, serial keyboard will serve for connection.
While waiting for the camera module and playing around with the settings on my Pi, I have been considering the interface between the computer (Raspberry Pi), the physical controls for the next stage of the project (for image-stacking), the remote shutter release and the stepper motor that will operate the fine-focus knob of the microscope.
Because the shutter control will eventually need to send a signal to two Raspberry Pi computers (when I get around to building an eyepiece spectrometer), the button will operate two transistor switches.
On the subject of the microscope spectrometer, I have decided that, since I will be using a camera as the detector (a PiNoir, infrared-sensitive version of the Pi Camera), there will be sufficient sensor space to handle four simultaneous channels of data - one being the light passing through the specimen. The other three will be a neon discharge tube, a mercury discharge tube and a beam of light direct from the microscope illuminator (delivered via fibre-optic light-pipe).
This will allow each spectrometer frame to have sufficient calibration data in it to enable direct measurements without having to set up calibration shots and reference illumination sources each time the device is used. Now all I have to do is to find myself a decent, linear transmission grating, since the DVD I was originally planning to use isn't a sufficiently high quality grating for anything but testing (the grating is curved, after all).
For anyone who receives one of these items that doesn't appear to work, you may need to re-seat the ribbon cable at the camera end, and to pop the nano-connector on the board out and back in.
The nano-connector is a little, flat, rectangular connector hidden under the flexi-circuit that emerges from the optical module (the actual camera).
A thumb-nail under the edge of this should separate the two parts, pinch between finger and thumb to re-seat the connector.
Also, for some reason, it takes a few seconds at cold-boot for the Pi to start up with the camera connected.
While I am working with the assembled electronics and doing the prototype work, I needed a temporary case for the camera. An off-cut of black, 1mm art board (cardboard) folded with a suitable hole for the optical module, held together with tape serves well. It is only to provide protection from handling (electrostatic discharge and stray signals from fingers), so it doesn't need to be a permanent (or even terribly attractive) feature.
..............................
I have also turned up a computer-mouse sized, wired, remote module already fitted with a push-to-make switch (to use as a shutter-release) and a neon which will accept a LED 'ready' indicator. The curly cable from an old, serial keyboard will serve for connection.
While waiting for the camera module and playing around with the settings on my Pi, I have been considering the interface between the computer (Raspberry Pi), the physical controls for the next stage of the project (for image-stacking), the remote shutter release and the stepper motor that will operate the fine-focus knob of the microscope.
Because the shutter control will eventually need to send a signal to two Raspberry Pi computers (when I get around to building an eyepiece spectrometer), the button will operate two transistor switches.
..............................
On the subject of the microscope spectrometer, I have decided that, since I will be using a camera as the detector (a PiNoir, infrared-sensitive version of the Pi Camera), there will be sufficient sensor space to handle four simultaneous channels of data - one being the light passing through the specimen. The other three will be a neon discharge tube, a mercury discharge tube and a beam of light direct from the microscope illuminator (delivered via fibre-optic light-pipe).
This will allow each spectrometer frame to have sufficient calibration data in it to enable direct measurements without having to set up calibration shots and reference illumination sources each time the device is used. Now all I have to do is to find myself a decent, linear transmission grating, since the DVD I was originally planning to use isn't a sufficiently high quality grating for anything but testing (the grating is curved, after all).
Friday, 21 November 2014
Eyepiece - Part 4 - Building from a clean install.
This is the approach when using a Windows system - users of Linux and Mac will need to look for their own software.
NOTE:
There is an issue with automatic log-in when running XDM on Raspbian. The workaround is not to start the XDM service until after the system has logged on the primary user.
Preparing your Raspberry Pi.
After downloading the latest build of Raspbian (Debian
Linux for Raspberry Pi), you will need to unzip the disk image and install it
onto a SD card with a capacity of at least 4 GB. The download is about 1000MB (1GB) in size.
Raspberry Pi Downloads (O.S.Images)
For unzipping, I use 7zip, a free utility.
To transfer the operating system image onto the bootable SD
card, you will need Win 32 Disk Imager.
Once your image is transferred, insert the SD card into the
socket on your Raspberry Pi and boot it up. You will need a monitor and
keyboard attached just this once.
A screen will appear asking you to choose a number of setup
options. Make sure that you change the Host Name to something distinctive so
that you can find it in the next step.
Complete your set up and reboot you Pi.
At this point, you will need to know the
network address of your Raspberry Pi. I use a product called Advanced IP
Scanner, though you may have another program that you prefer.
Run this program (or
something similar) for your local network, and make a note of the IP address of
your Raspberry Pi. You will need this IP address for the next part.
Updating your Pi.
At this point, you will need to run PuTTY, a program that operates as a remote terminal to communicate with a Linux computer. You will also need to have an active Internet connection on your network.
PuTTY is also free software, and has more uses than just this.http://www.chiark.greenend.org.uk/~sgtatham/putty/
When PuTTY starts, you will be presented with a window that asks for Host Name or IP Address. Enter the address you were supplied with by Advanced IP Scanner (above). Make sure that the option SSH is selected (just below where you entered the IP Address).
Click OPEN at the bottom of the window. Accept any warnings about identity and security, this is perfectly normal the first time you communicate with a new computer.
A new window will open and, after a few moments you will be invited to
Logon as:█
As this is a brand new install, the user name is Pi. Type this in and press enter.
You will be asked for a password.
pi@192.168.1.39's password:█
Enter the password, the default being raspberry. Again, press enter.
You will be given a block of text disclaiming any liability for anything at all and you will be presented with a prompt:
pi@(none) ~ $ █
You are now able to do things with your Raspberry Pi ... things like getting the remote graphical interface working.
Now, enter
sudo apt-get update
This command will take a couple of minutes to complete while it installs all of the updates to your new machine - some of the programs on the Pi are updated almost weekly.
Next, enter
sudo apt-get upgrade
You might as well go and make a coffee since this typically takes 10 to 15 minutes to complete.
Your operating system is now fully up to date.
enter
This will restart the Raspberry pi.sudo shutdown -r now
Installing a Desktop Manager
Once your Pi is up and running again, log in using PuTTY and your previous credentials. Once you get to the system prompt, enter
You will then need to type in a password for the root user (super user, administrator, head honcho etc.) ...
sudo passwd root
... twice.
This is not normally recommended, but since we will be accessing the computer remotely, then this is necessary (at least for now).
Now, you need to enter
su -Which command logs you in as the root user, who is allowed to do anything at all - including deleting the whole operating system. You have been warned.
Enter
apt-get install xdmThis installs the X Desktop Manager, which will give us remote access to the system's graphical interface. It will also run dpkg-reconfigure xdm.
When asked to choose a default desktop manager, select XDM and then OK.
You now need to change the contents of two files. Be very careful. You may need to read the simple editor tutorial page (coming soon).
Enter
cd /etc/X11/xdmthis opens the file /etc/X11/xdm/xdm-config in the default editor.
ed xdm-config
You need to change the line that reads
DisplayManager.requestPort: 0to read as
! DisplayManager.requestPort: 0so enter
,pYou should see the entire file being listed on your screen. The last line should be the relevant line. If so, then you may use the following script:
lThe line should have been correctly edited. if so, then you may enter
s/Display/!Display/
,p
wwhich saves the file and quits the editor.
q
Now enter
ed
/etc/X11/xdm/Xaccess
the line that reads
#* #any host can get a login windowneeds to be changed to read
* #any host can get a login windowentering
,pwill list the file. The line you want is a little under half way down.
Enter
46This should display the correct line. If not, you can advance lines by entering + or go back by entering - (minus).
once the correct line is reached, enter:
s/#//wq
This should have configured the machine to allow remote desktop access. Be warned that this is an insecure method and anyone on your network would be able to intercept your data.
Enter the following three commands to start the X Desktop Manager service, and to install some useful applications.
Now is the time to check that that XDM is running correctly:
Enter
Next: Accessing your Pi with Xming and configuring your system
Enter the following three commands to start the X Desktop Manager service, and to install some useful applications.
service xdm startx11-apps and midori (a web browser) will take a few minutes to install. python3-picamera and python3-picamera are most likely to be already installed.
apt-get install x11-apps
apt-get install x11-xserver-utils
apt-get install xscreensaver
apt-get install midori
apt-get install python-picamera
apt-get install python3-picamera
apt-get install python-picamera-docs
Now is the time to check that that XDM is running correctly:
This should return the following information:
netstat -ulnp | grep 177
if you see udp, :177 and xdm then everything is running properly.
udp 0 0 0.0.0.0:177 0.0.0.0:* 2864/xdm
Enter
service xdm stopand wait for the system to reboot
shutdown -r now
Next: Accessing your Pi with Xming and configuring your system
Wednesday, 19 November 2014
Eyepiece - Part 3 - Where , oh where has my remote drive gone?
After two days of struggling to get the Raspberry Pi to log in automagically, to set up user accounts, to set up remote desktop access, disabling the screen saver and to try to get the camera working (even though is seems to be dead), it was time to get the computer to mount some network shared directories into the local file system.
I can do this in Windows in my sleep.
Seemingly, others can do this in Linux, in their sleep.
I ended up cheating.
After a day of fiddling with the settings inside the operating system (which requires hunting for all manner of different text files to edit), I could manually mount those directories wherever I wanted, just not automatically at boot-up.
Now, in Linux, when you attach a network share to your system, it gets linked into an empty directory (folder) that exists in the file system.
The command is:
After trying all of the dozen or so methods of getting those remote shares to mount without human intervention, I gave up and cheated.
I wrote a script (a DOS Batch file) that starts a remote console (text only) session, logs in and does the job, it then closes the session and terminates itself. I also did the same thing to restart and shut down the Pi.
Happily, this isn't an issue, since the machine will always be run from another computer, I will set it up so that the main computer performs those tasks routinely itself.
eyepiece.bat
For more information on the Raspberry Pi ...
http://www.raspberrypi.org/
Next: Building from a clean install.
I can do this in Windows in my sleep.
Seemingly, others can do this in Linux, in their sleep.
I ended up cheating.
After a day of fiddling with the settings inside the operating system (which requires hunting for all manner of different text files to edit), I could manually mount those directories wherever I wanted, just not automatically at boot-up.
Now, in Linux, when you attach a network share to your system, it gets linked into an empty directory (folder) that exists in the file system.
The command is:
mount.cifs {where from} {where to} -o {options}Which worked fine. You can also tell the operating system to attach some remote directory to the file system - but if it can't do it, the entries are deleted, although you can tell it to mount them 'later', when mounting them becomes this command:
mount -aMuch easier, and again it works, but not automatically.
After trying all of the dozen or so methods of getting those remote shares to mount without human intervention, I gave up and cheated.
I wrote a script (a DOS Batch file) that starts a remote console (text only) session, logs in and does the job, it then closes the session and terminates itself. I also did the same thing to restart and shut down the Pi.
Happily, this isn't an issue, since the machine will always be run from another computer, I will set it up so that the main computer performs those tasks routinely itself.
eyepiece.bat
"C:\Program Files (x86)\PuTTY\putty.exe" -load M55 -l root -pw passwd -m mount.shAnd the mount.sh script
"C:\Program Files (x86)\Xming\Xming.exe" :1 -terminate -clipboard -query 192.168.1.72
#!/bin/bashNow, all I need to do is do the whole thing over again with a clean install of the latest version of Raspbian from the Raspberry Pi site.
mount -a
exit 0
http://www.raspberrypi.org/
Next: Building from a clean install.
Eyepiece - Part 2 - The initial hoops and hurdles.
Before anything else, it was necessary to set up the computer and to find out how the camera worked.
I actually bought the camera module a year ago, but hadn't managed to get around to trying it out.
I intend to do a clean install later, and will go through the full set up again, this time taking notes and screen-shots. The full set up will be published, eventually.
So ...
I set up the SBC (Single Board Computer) and started it up. Now, a long time ago, I got fed up with a monitor, keyboard and mouse attached to every computer I used, and so I discovered the joys of the Remote Desktop.
For Microsoft Windows, there is a program (creatively named Remote Desktop) that will access a Windows computer as though you were sat at the desk it is on. Remote desktop doesn't work for non-Windows computers, so I went to start my copy of Xming, which does the same job but with a Linux computer at the other end of the network. Well, that had disappeared last time I rebuilt my laptop, so I had to re-install. Xming is available for free.
http://www.straightrunning.com/XmingNotes/
Now, getting two computers talking together when they are running very different operating systems is a bit of a chore, and I needed to make some changes using the command line interface (you remember DOS, don't you - this is similar, but very different.) - for that I needed an old friend called PuTTY, another fine piece of free software designed specifically for that purpose.
PuTTY: A Free Telnet/SSH Client
A complicated hour or two later, including an update of the whole operating system via the Internet, and I had remote access to the Raspberry Pi desktop.
Now, I could install the driver software, in the form of Python libraries.
Python is a programming language with which I am only passing familiar, so I followed the instructions in the tutorials. I managed to capture an image or two (dog's nose, the wall, my right foot etc.) without ever seeing the preview.
Down in the notes there were words to the effect that the preview image is only displayed on the primary display hardware. This required a monitor with an HDMI interface, and a suitable cable.
Some plugging and rebooting later, and I had an excellent view of the cables in which the SBC nestled. A good picture that moved in real time (unlike a traditional web-cam or other networked camera). It even captures still images when told!
Then the LED on the camera came on (as normal) during a simple script test, and the program hung.
Reboot, unplug and re-connect. check everything and then check the website. It seems that the magic smoke that the camera runs on had escaped. [Insert appropriate imprecations and incantations here.] So, I need to order a new camera module.
Undeterred, I start work on the other bits of the set up, and notice that the primary display has gone blank. Cue a bit more cussing while I tried to discover how to disable the screen saver. That took a couple more downloads and a strange discovery - it is impossible to disable the screen saver on the log-in screen on Debian. You also have to install the screen saver software in order to disable it on a user profile.
The solution turned out to be a bit of editing in order to log in a dummy user when the computer starts up. It only took me 48 hrs to figure out how to do this reliably.
Thank goodness for Google and people willing to share their expertise!
After that it took a few minutes to share folders from the SBC to the network using SAMBA (which meant another package download and install).
Next: Adventures in accessing files across the network.
I actually bought the camera module a year ago, but hadn't managed to get around to trying it out.
I intend to do a clean install later, and will go through the full set up again, this time taking notes and screen-shots. The full set up will be published, eventually.
So ...
I set up the SBC (Single Board Computer) and started it up. Now, a long time ago, I got fed up with a monitor, keyboard and mouse attached to every computer I used, and so I discovered the joys of the Remote Desktop.
For Microsoft Windows, there is a program (creatively named Remote Desktop) that will access a Windows computer as though you were sat at the desk it is on. Remote desktop doesn't work for non-Windows computers, so I went to start my copy of Xming, which does the same job but with a Linux computer at the other end of the network. Well, that had disappeared last time I rebuilt my laptop, so I had to re-install. Xming is available for free.
http://www.straightrunning.com/XmingNotes/
Now, getting two computers talking together when they are running very different operating systems is a bit of a chore, and I needed to make some changes using the command line interface (you remember DOS, don't you - this is similar, but very different.) - for that I needed an old friend called PuTTY, another fine piece of free software designed specifically for that purpose.
PuTTY: A Free Telnet/SSH Client
A complicated hour or two later, including an update of the whole operating system via the Internet, and I had remote access to the Raspberry Pi desktop.
Now, I could install the driver software, in the form of Python libraries.
Python is a programming language with which I am only passing familiar, so I followed the instructions in the tutorials. I managed to capture an image or two (dog's nose, the wall, my right foot etc.) without ever seeing the preview.
Down in the notes there were words to the effect that the preview image is only displayed on the primary display hardware. This required a monitor with an HDMI interface, and a suitable cable.
Some plugging and rebooting later, and I had an excellent view of the cables in which the SBC nestled. A good picture that moved in real time (unlike a traditional web-cam or other networked camera). It even captures still images when told!
Then the LED on the camera came on (as normal) during a simple script test, and the program hung.
Reboot, unplug and re-connect. check everything and then check the website. It seems that the magic smoke that the camera runs on had escaped. [Insert appropriate imprecations and incantations here.] So, I need to order a new camera module.
Undeterred, I start work on the other bits of the set up, and notice that the primary display has gone blank. Cue a bit more cussing while I tried to discover how to disable the screen saver. That took a couple more downloads and a strange discovery - it is impossible to disable the screen saver on the log-in screen on Debian. You also have to install the screen saver software in order to disable it on a user profile.
The solution turned out to be a bit of editing in order to log in a dummy user when the computer starts up. It only took me 48 hrs to figure out how to do this reliably.
Thank goodness for Google and people willing to share their expertise!
After that it took a few minutes to share folders from the SBC to the network using SAMBA (which meant another package download and install).
Next: Adventures in accessing files across the network.
Tuesday, 18 November 2014
Eyepiece - Part 1 - the start of a new project
Now that winter has arrived, I am able to find time to start work on some of my planned indoor projects.
I have decided that the first project that I am going to work on is a camera eyepiece for my venerable Vickers M55 microscope - partly to save my poor aching eyes, and partly in order to allow me to do some micro photography.
Lacking the resources for purchase of a specialist microscope camera, I am going to put together a camera using an Raspberry Pi with its dedicated camera module (5 Mega pixel live feed, computer initiated capture including video). Later, I intend to add in a home-built spectrometer, but that's for another time.
This project will neatly encapsulate three of my interests - computers, microscopy and electronics.
I have had the computer for a couple of years. For anyone who doesn't know, this is a tiny single-board computer that runs the Linux operating system (amongst others). In this case, it will be running Raspbian the Raspberry Pi's custom distribution of Debian Linux.
It is a bit larger than a credit card and has a custom camera module that can be attached. The model B boasts both USB ports and a network port as well as a high definition video output. Instead of a disc drive, it accepts a wafer-thin SD memory card.
In order for this minimalist system to be useful for large-scale image capture, it will need to have access to a computer network which will allow it to use another computer's disc-drive for image storage. It will also allow access to the computer without having to have a keyboard and mouse attached to the Pi. The monitor, however, stays, as it is where the camera will send its preview video stream to.
It will also require quite a bit of programming in order for it to do its job.
While I am a more than competent computer user with some experience of using Linux computers as file servers, I am not that used to delving into the heart of the operating system in order to change the way it works.
Thus comes the first set of hurdles.
Next: Testing and initial setup.
I have decided that the first project that I am going to work on is a camera eyepiece for my venerable Vickers M55 microscope - partly to save my poor aching eyes, and partly in order to allow me to do some micro photography.
Lacking the resources for purchase of a specialist microscope camera, I am going to put together a camera using an Raspberry Pi with its dedicated camera module (5 Mega pixel live feed, computer initiated capture including video). Later, I intend to add in a home-built spectrometer, but that's for another time.
This project will neatly encapsulate three of my interests - computers, microscopy and electronics.
I have had the computer for a couple of years. For anyone who doesn't know, this is a tiny single-board computer that runs the Linux operating system (amongst others). In this case, it will be running Raspbian the Raspberry Pi's custom distribution of Debian Linux.
In order for this minimalist system to be useful for large-scale image capture, it will need to have access to a computer network which will allow it to use another computer's disc-drive for image storage. It will also allow access to the computer without having to have a keyboard and mouse attached to the Pi. The monitor, however, stays, as it is where the camera will send its preview video stream to.
It will also require quite a bit of programming in order for it to do its job.
While I am a more than competent computer user with some experience of using Linux computers as file servers, I am not that used to delving into the heart of the operating system in order to change the way it works.
Thus comes the first set of hurdles.
Next: Testing and initial setup.
Subscribe to:
Posts (Atom)