Apr 052016
 

Hi, my name is Darren and I’m a serial hobbiest.

Well maybe not that bad, most of my hobbies are pretty much related (electronics, computers, science), and a lot are things I’ve been interested in since I was a kid. Most recently, I’ve invested in a fairly decent telescope and mount to do some visual astronomy, but more for astrophotography. I want to take pretty pictures of things very far away! So after a lot of reading of various blogs and websites (Star Gazers Lounge forum is fantastic), and watching numerous youtube videos, I got a tripod for my camera and a couple of cheap lenses off eBay. That is all that is needed and you can get some half decent shots.

My astrophotography album

But it wasn’t enough. So I dove back into the forums and did even more research, and learnt a few important things.

  • Telescope – Numerous different types, mainly split into reflectors, refractors, and catadioptric. All have their benefits and downsides, but for doing astrophotography the telescope isn’t the most important item surprisingly.
  • Mount – This, for astrophotography, is the most important thing to get right.You need to have a solid mount for doing anything more than a few seconds exposure, and one with tracking in Right Ascension at least, to track the stars. And it really needs to be an equatorial mount to avoid rotation of the starfield as it rotates.
  • Eyepieces – You need eye pieces to view through a telescope, and the shorter the focal length, the greater the magnification. These are generally only used for visual astronomy, as cameras bypass the need.
  • Camera – Most DSLR cameras block out a large part of the infra red by design, but you can get them modified to remove this filter and get much more vibrant images. Its not a necessity, but definitely a nice to have.

Whilst learning all this, I had a thought in my head about some form of computer control (Linux based, of course) and actually stumbled upon a few projects to help with this. The first was AstroEQ which was an opensource ‘Goto’ system (select a star, and the telescope will automatically move to center on it) designed around an arduino. That was a perfect start for me, and I was pretty sure I could get it working from Linux. Thats when I discovered indilib!

Indilib is an open source system for controlling all sorts of astronomical instrumentation, not just goto mounts, but also things like auto focusers, digital camera, filter wheels, and other custom devices you may want. Even better, all this can be run from a Raspberry Pi as the control server and a laptop using the actual astronomy software. This would mean I could set it all up, and retreat to somewhere a little warmer to actually do my observations and photography. I’m sure this is against the amateur astronomers code or something, but damn it gets cold out there.

Along with indilib, there is kstars. This is a planetarium program written for the K Desktop Environment, and with EKOS plugin can control any indilib hardware. Not only that, it can schedule work and sequences, and help you plan your observations.

I’m going to (try to) write more blog posts chronicling my progress on getting all this set up, and some HowTo posts on using indilib on a raspberry pi, with kstars, and any custom hardware I make.

Dec 042015
 

11934535_10156061505195316_3190924556943319116_oIts been a long time since an update, but we moved house at the start of the year and things have been hectic. At least, thats my excuse and I’m sticking to it! I have been making progress with R2 in the last couple of months, doing a lot of work on his brain for starters, and painting various parts.

Code wise, there has been a couple of fairly drastic rewrites since my last update. The interface is a REST API, which sends commands to various modules as before. I’ve added a scripting module now, so that scripts or loops can be initiated such as random sounds, or a dance routine. The servo module had to have a major rewrite too as I discovered that I could only control one servo at once and had to wait for that to finish before another command could be sent. That wasn’t much good! I’ve also written the first of the actual controller interfaces (not counting a simple web one for testing), R2 can now be controlled from a PS3 controller. Button combos are read in from a csv file to trigger certain effects or scripts. Lastly, R2 now has a voice, and can play any mp3 stored in a directory, including selecting random ones from a list of types. Next step is to get either the Pi or the A la mode Arduino to control the speed controllers. I don’t want to run them off the Adafruit i2c servo controller for safety, I’d rather drive them directly and have some form of watchdog to make sure R2 doesn’t go on a rampage. All the code is still available on GitHub under my user, dpoulson

The PDU also needed a rethink, not least of all because of the amount of current it needed. The setup now has feeds directly to the speed controllers, with relays on the output from them to the motors so I can break the circuit if needs be. These relays will automatically turn off if the battery is disconnected so that any pushing of R2 will not feedback into the speed controllers and fry them. The relays will also be controlled from GPIO pins on the Raspberry Pi so I can disconnect them via an API call. I’ll also have an input for a kill switch that will have to be permanently on if any of the motors are to be powered, possibly using a transmitter in a replica droid caller or hilt of a light saber. I’ve a base idea for the new relay controls:

Powerswitch The relays I’ve found are Omron G4A-1EA, which have the benefit of the switched load being on spade connectors on the top, rather than through PCB traces, which when I did the calculations would need to be massive to support the potential current running through them. This allows me to make a simple PCB with the controller circuit, and hook the 24V battery up to it to power the coils. If the battery is removed, the coils turn off and the circuits are broken. No fried speed controllers.

The 24V connection will probably go through the fuse box I’ve installed, with a hefty fuse. The makers of the speed controllers don’t actually recommend a fuse but I’ve seen a few comments saying a 60+A fuse can’t be a bad idea, just in case!

The battery will connect directly to the center contacts of a DPDT switch, with the fuse box on one side, and the charger connection on the other. This will allow charging the batteries without taking them out of the droid. Not sure if this is best practice or not, needs more research. Currently they are just a pair of 12V SLA batteries that I had, connected in series to give the full 24V.

I’m hoping to get some time either this weekend or next, to hook up the motors, speed controllers, and battery, to test them out and get an idea of potential current draw. They’ll be controlled with a standard RC transmitter/receiver for now. If I can get the legs onto R2 he may even be drivable by xmas.

Fingers crossed!

Mar 132014
 

So, I seem to be building R2 in the reverse of how most people build their versions. Whilst I started with the dome due to finding a good deal, I’ve spent most of my time working on his internals and very little on the actual physical droid. Since my last post back in August regarding R2’s brain, I’ve done a lot of work on how everything will tie together to do the control. My current working idea is to have an i2c bus running throughout as R2’s central nervous system both sending out commands, and receiving feedback.R2D2_Electronics_Block_Diagram

The main control is still going to be a Raspberry Pi as this gives me much more range to do some interesting things later such as voice recognition, as well as letting me experiment with lots of different ways to actually control R2. I’m still thinking of using a PS3 controller as input, but also thinking of using a wii nunchuck is possible as a much smaller one to control simple operations.

The Pi will be linked via i2c to the various modules such as the servo controllers mentioned in my last post, with one in the dome and one in the body, and also to the lighting systems with Arduinos programmed to receive the signals to trigger various effects. I’m using BHD‘s Arduino code for the TeeCees lights in the dome at the moment, with just minor changes to accept the i2c signals. I may write something at a later date to do more dynamic light displays such as free form text messages to scroll across the RLD, but for now this is more than adequate.

Communication between the spinning dome and body will be through a 6 wire slip ring connector. 2 wires will be enough for the data signal, and then I will pair up the others to provide the power. I’ll probably have to go for two separate 5V supplies to the dome, one for electronics and one for servos as there will more than likely be a lot of noise coming over the servo power lines as they move.

PDUPower for all the electronics will come from a simple USB battery pack, which in turn will be plugged into the power distribution board I have designed. The PDU will take in a raw input from the sealed lead acid battery (or batteries) and produce clean 5v and 12v outputs, as well as a raw output direct to the speed controllers. The PDU also incorporates a few other features such as connectors for volt/amp meters that will be behind a panel on the front of R2, a voltage divider to allow the charge bay lights to function as a crude charge display for the batteries, and also a relay cut off for recharging R2. The last means that I can safely plug R2 into the charger (via an XLR connector), which will pull power going to the rest of the circuits. Lastly, there is the main power switch to kill power from the battery. There is a diode across the switch however which should allow any charge coming from the speed controllers to go back into the battery. This is a feature of the speed controllers to allow regenerative breaking.

The clean 12v will be used to power the audio amplifier. What is R2 without a few beeps and whistles?

I’m just waiting on the PCBs to come back from OSHPark, so I can try them out. Hopefully I managed to get most of it right and I haven’t seriously miscalculated the current draw from the batteries. I don’t want any tracks melting off the board!

Code wise, I’ve done quite a drastic rewrite of the controlling software to make it much more object oriented. Each different module (servos, audio, lights, etc.) is a module with a command keyword associated with it. This means adding new modules (LCD screen, extra lighting, drinks dispenser…) should be easy and just a case of creating a config file and possibly a class file if its a new type of module. All the code is available at github, along with the schematics and board diagrams of the PDU. The PDU is also available to get direct from OSHPark.

Fingers crossed I may be getting a few parts to build the actual droid with soon, including the feet, which means I now have to figure out a drive system for him. Mechanics isn’t exactly my strong suit, so should be interesting. 🙂

Feb 202014
 

Ok, so along with my R2, a side project is something that will hopefully fit inside of R2 and make him even more popular. To reprise his role in Return of the Jedi he will be serving drinks, and not just glasses from a fancy tray bolted to his shoulders. He will be able to mix a drink for you and dispense it into your glass.

The idea is, to have a bunch of reservoirs in a caddy inside R2’s main body, with pipes to an automatic arm that will open a door and raise, allowing you to put your drink under it. My design so far allows for five bottles, with peristaltic pumps from adafruit (via a UK reseller, Phenoptix), some L293D motor drivers, a TLC5940 PWM driver, and an Arduino Pro mini. I still have a long way to go on the design, but I have managed to the main module constructed and the pumps installed. I’ve also got a first revision of the circuit schematic worked out, along with a PCB layout that I’ve ordered from OSHPark.

Pumps

A closeup of the pumps

The main unit is made from a series of laser cut acrylic sheets, with a central threaded rod as the main shaft. The bottle tops still need holes for the tubing to go into, and the lids will be glued to the acrylic. Refilling will be done by removing the bottom plate and unscrewing the bottles. I also need to figure out ideas to check for the fluid level so I get notified when a bottle is nearly empty.

The main control for selecting the drinks will be handled by a Raspberry Pi, talking over i2c to the arduino to control the motors. This will allow me to do an embedded web server for selecting the drinks, depending on what options are available. R2 will also have most of his communication done over i2c which will allow the drinks dispenser tie into that and control the door and dispensing arm. Other future ideas are also having a few spare bottles and QR codes as labels on them so that I can automatically scan them in so that the Pi knows what drinks are available rather than having to key the data in manually.

Main unit

The main unit.

This is my first attempt at doing an actual useful PCB. Probably many errors and will need another couple of revisions, but it is a start. The Schematics and other files can be found on github here:

https://github.com/dpoulson/drinks_dispenser

And if you’re really bored and have money burning a hole in your pocket, then the latest revision of the PCB can be bought at OSHPark:

http://oshpark.com/profiles/DarrenP