To supply power to the controller and stepper motors a pretty hefty power supply is required.  Many people opt for a standard old school non-regulated power supply, but I opted to go with something that would provide plenty of power along with regulation and thermal protection.

Taking all variables into account I decided on a switching power supply that produces 48Vdc @ 350Watts (7.4A with air cooling) with an efficiency rate of 88%+.

I found this power supply at Digikey model: FXA350048A.  It has a remote ON/OFF, power sense, power good indicators and thermal protection.


As I posted a few days back, I’m making the jump to upgrade my manual Taig mill to CNC.  One of the first thing I have had to do was to select a stepper driver and controller.  I’ve read a lot of various forums and a lot of people have very good results and comments about Geckodrive.

So I opted to get a Gecko G540 drive for my mill.

I also decided to be smart and avoid issues by ordering matching stepper motors from GeckoDrive.

So far I’ve managed to keep my Taig mill 100% North American made 😉

Well I finally succumbed to the call of CNC.  After operating my hobby metal lathe and mill for several years, I’ve now decided to convert my mill to CNC.  The aspect of creating many similar parts really got tiring on the manual machines, one, two is ok, but past that, it gets real tedious.

I have been looking at this for quite a while and have been reading various forums,  I decided to opt with Geckodrive’s drive/stepper/controller for my Taig mill… and will probably start off using Mach3 for the CAM S/S even though it only runs on windows 😦

I have received many of the parts for the conversion and will soon start the process.  I will try to blog my conversion adventures here, under the category of “CNC conversion”

It’s been a while seen I took a look at my system chart, so this morning I decided to update the chart with the latest changes.

Here it is :

Lots of progress on many fronts.  My next step is really to re-assemble the rover so it can run around on the ground and do some interactive testing of the systems… but before I can do that, I’ll have to get a USB/WiFi dongle so I can communicate with the beast while it moves… or get a very long cat5 cable 😉

I wanted a simple yet robust mechanism to have the master controller send low-level commands to the slave controller.  From the previous post I mentioned that I had to use a USB i/f between the 2 controllers.  On the BS2SX side of things this was achieved by using a couple of I/O pins and connecting them to the USB controller on the SparkFun USB controller.  From there the s/w looks at each end as if they are standard serial port lines.  The low-level device drivers and hardware handle the conversion.

Eventually with a lot of fussing about with serial port configurations on the Linux side (BeagleBoard), I got the 2 controllers to chat consistently.  I used a very simple “send/ACK” protocol between the two.  It works for what I need at this point.  I decoupled the sending/receiving stuff from the applications to allow for future changes.  On the BS2SX side things got a bit more complex than anticipated.  Due to the length of the program, I had to use more than one memory slot for the firmware.  This was an interesting learning exercise on its own.

Here’s a screen snapshot of the various windows on my Linux desktop while monitoring the master and slave controllers.

The screen shot shows on the left the BS2SX debug console messages (blue on white) and on the right the remote console session on the BeagleBoard running the RCI (rover command interface) that I used to test/debug the application.  In this shot, a START command is issued from the BB to the BS2SX, this launches an initialization sequence on the BS2SX and sub-systems.

Always learning… that’s a good thing… my plans to use the RS-232 serial interface from the BeagleBoard to the BS2/motor/servo controller got derailed when I realized that the port is already used to “communicate” to the console during the boot of the BB.   Yes, I could disable this and change the boot system, but I really don’t want to mess around with the boot loader and want to keep my console access as a safety measure… and it turns out that the BS2SX also uses some “interesting” f/w on its RS-232 port to communicate with the programming PC… it echoes every character received.

So, that means I had to come up with a different scheme for the communication between the master BB and the slave BS2 controller.  I opted to connect the BS2 via USB to the BB.  I’m using a nice prototype board from SparkFun as the USB i/f and carrier for the various BS2, motor & servo controller boards.  It has plenty of room for all the boards and provides a very nice/clean USB controller and interface.

This is what the modified rover now looks like… I had to move the carrier board closer to the BB and also move the USB hub to ensure everything would connect properly.

You can see from left to right, the servo controller, the motor controller (with heat sink), the BS2SX stamp and USB hub mounted on top of the BeagleBoard.  It makes a nice compact controller complex.

The RS-232 cable that you see in the picture is connected to the programming PC running the Parallax Basic Stamp editor/programming under Wine on my Ubuntu Linux desktop, more on this later.   This cable is removed in normal operation.

MKII : USB Web Cam

Posted: 2010/11/08 in Uncategorized

Well one area that I need to re-design from MK I is the USB Cam module.  This module does not work as is on the BeagleBoard.  My MK I stuff was designed around the original V4L libs, and code borrowed from a public domain tool “camgrab”.

I need to upgrade this stuff to V4L2, the current version of the USB Cam libs for Linux.  Sounds simple, but I’m no pro in this area.  I’m going to have to do a fair amount of homework on this… but hey, that’s part of the fun. 😉

At the same time, I’m taking a closer look at OpenCV, there’s a lot of nice utilities in there for robot vision and image manipulation.

Stay tuned…