SOLVED: AX-12 interfacing approach (see first post)

[Gertlex]

I've got my Axon to AX-12 setup working nicely now.
Things I learned:
-Soldering techniques that would make real EEs cry
-Some 9V batteries suck for unknown reasons
-Webbotlib (and Webbot) is awesome
-If an AX-12's LED flashes when you're sending it a command, it's generally an error.  In my case, this almost definitely corresponded with insufficient power being supplied.
-For testing, this 12V power supply I had lying around wins.

I've still got more testing to do, and stuff to determine regarding working with the AX-12s + Webbotlib/Axon.

A couple pics:
The Tri-State Buffer which allows me to interface with the Ax-12s (See also this thread)


Janky adapter for power supply, which replaces my need for 9V batteries


-------Former post-----
My current project involves using AX-12 servos with an Axon.  At the moment I don't have the recommended circuitry for doing both TX and RX with the servos.

Is it possible to control the servos just using the TX from the axon and ignoring whatever is sent back from the servo?  E.g. Simply hook it up to an adequate power supply and connect data to a UART TX pin?

This post is based on what I've read here, mostly:

http://www.societyofrobots.com/robotforum/index.php?topic=6032.0

[Webbot]

WebbotLib supports the AX12 - but you have to add the tristate chip (v. cheap).

Yep - in theory you can just use the xmit pins but you are then missing out on loads of good stuff you can read back from the servo: temperature, load, voltage, actual speed etc.

So for transmit and receive I really recommend the tristate buffer (Project Designer will show you how to wire it up). I choose this approach as the only other alternative is short out the Tx and Rx pins on the Axon and hope your code works without blowing the Tx/Rx pins. Even if you do that ok - then beware of loading new code, ie another project, where you are using the uart as normal but you've forgeotten to remove the short - bang! Hence the buffer is the safest way.

[Gertlex]

Yup I plan to do the hardware "fix" you described.

Just doing a bit of testing in the meantime.

Thanks!

[Gertlex]

Have not had success controlling the servos yet.  Is I2C necessary with the AX12 library?.. I'm just using the non-USB UARTs at the moment....

Edit: Ok, now playing with Project Designer... But first, sleep.  I'll see if I get anywhere with it tomorrow afternoon.

[Webbot]

You don't need I2C, and you can use any hardware UART. Don't use a software UART as it wont be able to do the 1M baud required.

[Gertlex]

I got the parts today necessary to build the tristate buffer circuit, and built it.  I think I built it right (link), but am seeing odd results.

I'm testing using code that that toggles a variable value, which in turn dictates whether to turn LEDs on or off when the Axon's button is pressed.  I'm toggling both the Axon and the AX12s' LEDs.

What I've tested:
-Turning servo LED on and off - works randomly, but reproducible.
-Moving servos with act_speed() does not work.  I maybe saw a servo move once a few days ago when I was toying with the temporary approach earlier in this thread.
-Changing servo IDs - works eventually, then verified by varying which servo ID the LED commands are being specified for.
-Changing the BAUD rate - appears to have worked.  1million BAUD no longer controls the servos which were sent to 115200 baud.  However, changing the ax12_driver in the hardware.h file to 115200 manually doesn't seem to let me control the servos at all.  Two servos are in this state, currently x_x.

Any ideas?

[Webbot]

I've replied to this in your other thread on the matter:-
http://www.societyofrobots.com/robotforum/index.php?topic=13740.msg101687#msg101687

[Gertlex]

As mentioned in the other thread, signals now go to the servos reliably... creating a common ground between the multiple power sources in the tri-state buffer was my previous omission.

I was also able to fix the baud rates that I had changed... Looking at the ax12 documentation and webbotlib ax12 header file clued me in to what I'd done wrong (or rather not understood).  I just have to remember that the ax12Set____ function parameters are the bytes sent to the servos, not actual values... (specifically calling ax12SetBAUD(&servo,115200) was actually calling ax12SetBAUD(&servo,254), which corresponds with a baud rate of 7840.  Durrr.)

...

So anyways, I now have reliable communication with my servos, but I've still been unable to get them to move with either the act_setspeed or ax12SetGOAL_POSITION functions.

Additionally, right now I'm getting 0x100 (256) as my status code, using the ax12GetInfo and ax12Dump functions if I insert a delay_ms of less than about 70 ms between calling any ax12 function and calling the getInfo/dump functions.  This error message corresponds with a timeout for receiving data.  I get the same error if I have nothing connected to that UART.  I characterized this behavior with simple code like this:

Code: [Select]

           ax12SetGOAL_POSITION(&servo12,750);
            delay_ms(70);
            outvar = ax12GetInfo(&servo12);
            rprintf("%d\n",outvar);

            ax12SetGOAL_POSITION(&servo12,750);
            delay_ms(65);
            outvar = ax12GetInfo(&servo12);
            rprintf("%d\n",outvar);

            ax12SetGOAL_POSITION(&servo12,750);
            delay_ms(60);
            outvar = ax12GetInfo(&servo12);
            rprintf("%d\n",outvar);

Any idea about the lack of servo movement and the timing for servo response?  I don't think the latter will be a problem, though...

Further testing has been hindered by the CRC-error bootloader problem and more importantly, packing stuff up so I can drive to Los Alamos for my summer internship...  I won't really get a chance to hook up Axon+servos until next Wednesday or so :/

[Webbot]

I've only really tested the servos at the factory set !M baud and since it worked ok then I haven't tried slowing the servos down to 115,200 baud as there didn't seem any point. But the slower baud rate of 115,200 may explain the timeout issues.

[Gertlex]

I'm not using the 115200 now, I'm using the default 1m baud rate.  The former was going to be my attempt earlier to fix what the common grounding fixed.

I really just need the chance to test other functions.  I'm tempted to get the USB2Dynamixel device that is sold as a testing tool... but maybe I could simply use the tristate buffer i built and try sending command with my computer again? E.g. (computer -> serial port [->? serial to ttl?] -> buffer -> servo)?  Thoughts?

[Webbot]

You definitely need the RS232 to TTL converter.
Not sure how you would drive the Direction pin of the buffer. So I'd stick to transmit only routines ie like turning the LED on/off.

I still think its a bit of a waste of time - my AX12s work perfectly well at 1M baud using the example code kicked out by Project Designer (using act_setspeed etc). I can then add the routines to dump out all the info on each servo. Everything works perfectly. No need to resort to the lower level commands defined in the H file like set goal position etc.

If your servos still aint responding then I'm wondering if you have got them actually set to the baud rate and ID numbers that you 'THINK' you have.

[Gertlex]

I think I'm failing to communicate my setup with you, Webbot.

Fortunately I am now successfully controlling the movement of my servos.  Turns out it matters which battery I was using.  I've been using 8.4v NiMh (aka rechargeable 9V's).  I recharged one right before I left on my road trip, and that's the one working.  (Despite the others measuring the same voltage).  I suspect the others will work once I charge them fully (which I thought I had done already...).  Regardless, I'm now set to order new lipo batteries anyways.