SciHackDay side project
2014-Nov-19, Wednesday 09:34 am![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
chebeSet the scene; it's midnight, I'm just back from (sci-fi) book club, SciHackDay kicks off in the morning, and I want a project; something sciencey. I decide I want a radio telescope. But, well, I don't have the parts. So I scale back my idea into something I can iterate up into a radio telescope.
I shifted my focus on the electro-magnetic spectrum up to visible light, hoping to use my new colour sensor. It will really only give me one reading from one point of space, like a single pixel. To scan an area I'll need something to move it along. But I don't have any servos, and I've never played with motors before. Luckily I have a robot arm handy. And then the rest should just be Arduinos.
That's the thing about poorly researched hacks, they're never as straight-forward as they seem.
I got started with the greatest unknown; the robot arm. I didn't want to break it apart, but rather to automatically, in a repeatable way, control its movement. Basically to replace the controller with a computer. I took the controller apart, opened up the body of the arm, and had a good look around. It is entirely mechanical, there are no embedded elctronics anywhere that can be seen. And being originally a kit everything is well labeled. The controller is attached via a cable and connector, and is a one-to-one relationship, no multiplexing to worry about. From left-to-right they are; Vcc, motor1, motor2, motor3, motor4, motor5, LED, Gnd.
I was going to just plug everything straight into my Arduino, but Rob insisted that the current was measured first. At somewhere around 160 he declared it would fry my Arduino. I guess some people get around this with motor shields, but not having one Rob produced some H-bridge chips to breadboard. There was a long discussion about how to control these, and not being an electronics person I mostly left it to Rob and Paul, just letting them know when something didn't work the way they'd intended.
In a simple way the motors can be viewed as being at 0v; nothing happening. By connecting one to 3v, the motor moves counter-clockwise. By connecting one to -3v (or Gnd), it moves clockwise. We were connecting them up to quad half-H-drivers (L2930NE). The method to get the motors to move the way you want is to set the Input pin to the direction you want; i.e. LOW for clockwise, HIGH for counter-clockwise. But the motor won't actually move until you set the Enablement pin to HIGH. These chips can handle four motors each, but two motors (both on one side) share one Enablement pin. So to be able to completely, individually, control each motor we could only wire up two motors per chip. Five motors meant we needed three chips.
And at the moment the arm is simply controlled by time delays, but for accuracy potentiometers and trimpots will probably be needed.
After that, getting the colour sensor working seemed trivial. I then got Processing working for the first time, and constructed a four-by-four grid of large square pixels. I taped the sensor to the front of the robot arm, programed it to take four steps right, one down, four left, one down, etc, to scan an analogous region of space to map to the Processing grid. It was all going well until I realised that my colour sensor is a proximity colour sensor. It just couldn't cleanly detect colours at a distance. Which makes sense. After all, my robotic colour telescope is still missing any kind of telescope. Essentially, instead of taking very low resolution photos I had created a very low res robtic hand scanner.
Nonetheless I am one step further along towards my radio telescope goal.
Also, photos are up!
I shifted my focus on the electro-magnetic spectrum up to visible light, hoping to use my new colour sensor. It will really only give me one reading from one point of space, like a single pixel. To scan an area I'll need something to move it along. But I don't have any servos, and I've never played with motors before. Luckily I have a robot arm handy. And then the rest should just be Arduinos.
That's the thing about poorly researched hacks, they're never as straight-forward as they seem.
I got started with the greatest unknown; the robot arm. I didn't want to break it apart, but rather to automatically, in a repeatable way, control its movement. Basically to replace the controller with a computer. I took the controller apart, opened up the body of the arm, and had a good look around. It is entirely mechanical, there are no embedded elctronics anywhere that can be seen. And being originally a kit everything is well labeled. The controller is attached via a cable and connector, and is a one-to-one relationship, no multiplexing to worry about. From left-to-right they are; Vcc, motor1, motor2, motor3, motor4, motor5, LED, Gnd.
I was going to just plug everything straight into my Arduino, but Rob insisted that the current was measured first. At somewhere around 160 he declared it would fry my Arduino. I guess some people get around this with motor shields, but not having one Rob produced some H-bridge chips to breadboard. There was a long discussion about how to control these, and not being an electronics person I mostly left it to Rob and Paul, just letting them know when something didn't work the way they'd intended.
In a simple way the motors can be viewed as being at 0v; nothing happening. By connecting one to 3v, the motor moves counter-clockwise. By connecting one to -3v (or Gnd), it moves clockwise. We were connecting them up to quad half-H-drivers (L2930NE). The method to get the motors to move the way you want is to set the Input pin to the direction you want; i.e. LOW for clockwise, HIGH for counter-clockwise. But the motor won't actually move until you set the Enablement pin to HIGH. These chips can handle four motors each, but two motors (both on one side) share one Enablement pin. So to be able to completely, individually, control each motor we could only wire up two motors per chip. Five motors meant we needed three chips.
Pinout diagrams
Breadboarding
Photo by chebe
The whole contraption
Photo by chebe
And at the moment the arm is simply controlled by time delays, but for accuracy potentiometers and trimpots will probably be needed.
After that, getting the colour sensor working seemed trivial. I then got Processing working for the first time, and constructed a four-by-four grid of large square pixels. I taped the sensor to the front of the robot arm, programed it to take four steps right, one down, four left, one down, etc, to scan an analogous region of space to map to the Processing grid. It was all going well until I realised that my colour sensor is a proximity colour sensor. It just couldn't cleanly detect colours at a distance. Which makes sense. After all, my robotic colour telescope is still missing any kind of telescope. Essentially, instead of taking very low resolution photos I had created a very low res robtic hand scanner.
Nonetheless I am one step further along towards my radio telescope goal.
Also, photos are up!
