A few years ago my father built a neat little desktop CNC machine capable of engraving plastic and cutting thin materail with a Dremel tool.
As with most DIY CNC machines the control of its steppers relied on a computer with a parallel port. Obviously this is an issue for people who like to use modern computers!
I have decided to tinker with the machine. The plan is to program an AVR micro controller to interpret G-Code fed to it over USB or read from an SD card. The setup would be nearly identical to the controls of a reprap 3d printer.
In the embed video you can see how I have programmed an ATMEG168 micro controller interfaced with a Pololu A4988 Stepper Driver to drive the Y axis of the desktop CNC into a micro switch endstop.
I am not sure how far ill take this project but it sure is fun to play with different things.
Starting to make some progress on my RepRap Prusa project.
I have purchased stepper motors and stepper motor controllers from Pololu. The stepper motor controllers are really just carrier or breakout boards for Allegro’s A4983 DMOS Microstepping Driver.
To test the controllers and stepper motors I interfaced them with my simple AVR ATMEGA 168 breakout board. With the digital outputs of the AVR connected to the enable, direction, step, and microstepping inputs of the stepper motor controller I was easily able to write a simple c program to test all of its features.
I have recently started work prototyping some ideas for a simple wireless remote controller for my robots.
Originally I was going to purchase some thumb joysticks available from Sparkfun to use for prototyping. Luckily I had the idea to use an old Playstation One Dual Shock controller that has been collecting dust for ages in my closet. It was kind enough to donate its innards for my purposes. Surprisingly the thumb sticks found inside the Playstaion controller are identical to the Sparkfun ones.
I went ahead and etched two breakout boards for the liberated thumb joysticks and have begun to interface them with one of my ATMEGA168 breakout boards. The software is really quite simplistic. It is just a matter of doing two analog to digital conversions for each axis of the joystick, forming a packet with the joystick readings and transmitting the packet out the micro’s USART to the Xbee module.
While working on a recent project I needed to generate a PWM signal from my ATMEGA644P in order to operate a SN754410 motor driver as a speed controller.
To generate the PWM I used the ATMEGA’s 8-bit Timer/Counter 2 configured for fast PWM mode. Fast PWM works as follows:
The timer will continually count up from ‘bottom’ to ‘top’. When ‘top’ is reached the counter will then wrap around and begin counting up from ‘bottom’ again. In this case we are using an 8 bit timer so ‘bottom’ will be equal to 0 and top will be equal to 255 decimal or FF hex. When the counter reaches the ‘compare’ value an output pin will be set. This pin will then reset when the counter wraps around to ‘bottom’. We are able to vary the value of ‘compare’ in order to generate a fixed frequency PWM signal with a variable duty cycle.
In order to set up the timer its registers need to be configured as follows:
Set the Data direction for timer pin set as output
I am using timer 2 output A so pin 7 port D (PD7 OC2A/PCINT31) needs to be set as output:
DDRD |= (1 << PD7)
Set waveform generation mode
Waveform generation mode is set in the two registers TCCR2A and TCCR2B, Timer/Counter Control Registers A and B. I need Fast PWM counting from 0 to 0xFF so I set the registers as:
TCCR2A |= (1 << WGM0) TCCR2A |= (1 << WGM1)
Set compare output mode
Compare output mode is set in the TCCR2A register:
TCCR2A |= (1 << COM2A0) TCCR2A |= (1 << COM2A1)
Clock selection is set in the TCCR2B register. I am not concerned about the frequency of the PWM signal so I just select the AVR’s clock as without any prescalling.
TCCR2B |= (1 << CS20)
Set the output compare
Lastly the fast PWM’s duty cycle needs to be set by adjusting the compare value. This is set in the OCR2A, Output Compare Register A. This register can be written to in any point in software to vary the duty cycle of the output PWM signal.
Over the last week I have been able to get wireless control working with my AVR micro. Communication to the AVR is being done by sending wireless serial data packets using xbee modules. At the moment my packets consist of two header bytes (0xff) to designate the start of a new packet. The header is then followed with 4 bytes to hold the values of 2 joystick (horizontal and vertical axis). The packet is then ended with a checksum.
I have created a simple python and wxpython app to simulate the control of two joysticks using some slider widgets. This app simply reads the value of the 4 sliders, forms a data packet and writes it out serially to a xbee module connected to my PC around 30 times a second.
MechController.py demo window.
On the micro side I have a second xbee module connected to one of the atmega644′s usarts. The micro is adding every byte it receives on this usart to a ring buffer. Then, when called, a function is able to search this buffer for a full data packet, pull out the joystick data and flush the buffer.
Here is a little video I took to demonstrate it all working. Off camera I am changing the values on the top two sliders in my python app. These two sliders represent the vertical and horizontal axis of a single joystick. In turn the value of each slider determines the walking direction of the robot.
Progress continues with my AVR microcontroller board… Today I was able to get some simple wireless serial communication tests working.
I followed this great tutorial post on AVR Freaks on creating interrupt driven USART echo program. I then took it a step farther and had each side of the serial link (PC and micro) echo the last character received pulse one.
All in all the test were not very interesting but they do lay groundwork for the development of a control packet structure for driving Gold Rush around.