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.
Showing posts with label Wireless. Show all posts
Showing posts with label Wireless. Show all posts
Tuesday, October 5, 2010
Monday, August 2, 2010
Gold Rush Serial Data Packet Control
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.
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.
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.
Posted by
MrLowerr
Sunday, February 21, 2010
Pairing Xbee Wireless Modules

Xbee wireless modules offer a quick, easy and inexpensive way to provide wireless end-point connectivity in your projects.
While they do offer “no configuration needed for out-of-the-box RF communications” you will want to do some configuration to allow high speed communications with automatic resending of lost packets.
The easiest way to set the parameters of an Xbee modules is with the use of Digi's X-CTU software utility. X-CTU is a windows-based application designed to interact with Digi's RF products providing a simple GUI for firmware configuration.
For paring a set of 2 Xbee Modules the parameters we are concerned about are PANID (ATID), Destination Address Low (ATDL), 16-bit Source Address (ATMY) and Interface Data Rate (ATBD).
The PANID (ATID) or Personal Area Network ID is a number shared amongst each Xbee module in a network. Many Xbee modules could exist in the same area but only those that share a PANID can talk to each other. The default PANID is 3332 and should be avoided
The Destination Address Low (ATDL) sets the destination address of the Xbee module and the Source Address (ATMY) sets the address number of the Xbee module. For a pair of Xbee modules these should be set opposite of each other to enable automatic resending of lost packets.
The Data Rate (ATBD) or baud rate is the number of bits per second the Xbee module will send. Xbee modules must have matching baud rates for them to talk to each other. The default is 9600bps.
At the moment SA's Xbee modules are set to:
Xbee #1 – Computer Side
ATID = 4321
ATDL = 11
ATMY = 10
ATBD = 3 (9600bps)
Xbee #2 – Robot Side
ATID = 4321
ATDL = 10
ATMY = 11
ATBD = 3 (9600bps)
So far this configuration has been working well. I do plan to experiment with a higher baud rate soon as 9600bps is a bit slow. But for now all seems well.
Posted by
MrLowerr
Subscribe to:
Posts (Atom)

