Netduino home hardware projects downloads community

Jump to content


The Netduino forums have been replaced by new forums at community.wildernesslabs.co. This site has been preserved for archival purposes only and the ability to make new accounts or posts has been turned off.
Photo

AX-12 servo interface


  • Please log in to reply
2 replies to this topic

#1 Falstaff

Falstaff

    New Member

  • Members
  • Pip
  • 8 posts
  • LocationBellevue, WA

Posted 05 February 2011 - 08:10 AM

Hello all! I've not yet received my Netduino Plus, but I'm already looking forward to my first real project after I get some experience with the basics. I have considerable experience with AVR ATmega designs and PC-based .NET/C# development. So the Netduino seems like the answer to a lot of prayers for a great micro platform!! But I'm more of a software and digital electronics type, so for some of the more troublesome linear electronics issues I seek the advice of those with greater knowledge and experience.

First let me briefly describe my project: I already have developed a PC-based .NET/C# solution for driving AX-12+ "Dynamixel" servos using a USB2Dynamixel interface. My library is featured on the CrustCrawler site where the servos are available. I also offer a sample program to operate an AX-12 Robotic Arm using a PC joystick. Since I already have an XBee module embedded in a PS2 controller from a previous combat robot project, I'm hoping that using something like the Sparkfun XBee shield should get me up and running fairly quickly with a nice wireless joystick. But there are a few interface issues that I need to resolve to drive the AX-12 servos: (these are perhaps tightly-coupled issues)

(1) interface voltage: The AX-12 is 5v while the Netduino is 3.3v. I did find a nifty little level converter at Sparkfun that just might help. The TX side of this can apparently be used in a bidirectional way.

(2) interface logic: The AX-12 uses a single-wire half-duplex serial interface, with the following suggested driver circuit:
Posted Image
I've seen 3.3v device designs (using the Propeller) that drive the one line thru a level shifter. The Propeller can apparently use the one IO pin for both transmit and receive while still achieving the necessary high baud rate.
I've seen 5v designs (using ATmega's) that tie a TX and RX pin together directly to the AX-12 and rely on careful enabling in the software so that only one is active at a time. But the need to interface a 5v device complicates just a bit.

3) interface speed: The AX-12, by default, operates at 1M bps. It looks to me like the Netduino processor at 48MHz should handle that OK with a UART function. I'm not sure if the drivers and libraries might need some tweaking for the receive buffers to keep up at that speed. But I suspect it can be done. The incoming data arrives in short and sparse packets. I do have some concerns for the level shifter operating at that frequency. The AX-12 can be configured for lower speeds, but it's not recommended.

4) interface current draw: I don't see any specs for current draw on the AX-12 signal line, but they daisy chain indefinitely and I don't know if they boost the signal from one to the next. So I'm thinking I may need some kind of beefier driver/buffer. Perhaps I should just build the circuit as above and level-shift that final IO line. Perhaps there's a device that can do it all? I've not started looking into that yet.

So that's where I'm at. I don't think any of these issues are too terribly difficult. But any advice is appreciated. I hope to make a contribution to the community and have some fun!

#2 Falstaff

Falstaff

    New Member

  • Members
  • Pip
  • 8 posts
  • LocationBellevue, WA

Posted 24 February 2011 - 05:04 AM

I've begun trying to implement this half-duplex USART interface and have encountered a problem. The DIRECTION_PORT line, which determines whether we're transmitting or receiving (see the diagram above), needs to be high only while bits are being pumped out on the TX pin and then set low quickly to receive on the RX pin. Serial output is asynchronous, so I either need to respond to an interrupt, such as TXEMPTY, signaling output is complete OR wait until all bits are transmitted. Unfortunately neither function seems to be available within .NET MF. The SerialPort class contains no TX events. The Flush method helps only a little. It waits for the buffer to clear but returns before the Transmit Shift Register has cleared. So the last byte is still trickling out when Flush returns. Any advice on solving this problem? Perhaps I need to educate myself on native coding and implementing drivers to address this issue?

#3 Chris Walker

Chris Walker

    Secret Labs Staff

  • Moderators
  • 7767 posts
  • LocationNew York, NY

Posted 25 February 2011 - 12:36 AM

Hi Falstaff, Glad to see your progress. Ambitious first project: I like it :) If you want low-level control of the UARTs (setting an IO state in real-time in response to TXEMPTY for instance), you'll need to do that in native code. Luckily, Netduino is open source so this is very possible to do. Possible approach: modify the SerialPort (A91-USART) code in the firmware source File location: C:\MicroFrameworkPK_v4_1\DeviceCode\Targets\Native\AT91\DeviceCode\AT91_USART\AT91_USART.cpp For instance, in the "BOOL AT91_USART_Driver::TxBufferEmpty( int comPort )" function, you could set use the AT91_GPIO_Driver::SetPinStatefunction call to set the "direction" output port to true/false. [Create an OutputPort in code before you set up the SerialPort...and that'll protect the pins from being stolen elsewhere...or call the AT91_GPIO functions as part of the AT91_USART_Driver::Initialize routine for that comport. Does that help get you started in the right direction? Chris




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users

home    hardware    projects    downloads    community    where to buy    contact Copyright © 2016 Wilderness Labs Inc.  |  Legal   |   CC BY-SA
This webpage is licensed under a Creative Commons Attribution-ShareAlike License.