DeBrat - Axon2(ATMega640) Brat

Just for the fun of it I decided to try out one of the Society of Robots AxonII controller boards (societyofrobots.com/axon2/). It is based on the Atmega640 microcontroller by Atmel, which has some nice features like 4 UARTS (1 is used by the USB), 16 AtoD pins, 15 PWM channels…). After getting a few things to work, I decided to try it out on one of my Brats, as you can see in the picture below:

I cut out my own electronics holder for it as the board is a slight bit wider and shorter than the BB2. The software is written using Appstudio from Atmel and the free GNU C compiler. Note: the C compiler that downloads with Basic Micro Studio for the Basic Atom Pro is also the GNU compiler. I started off using a software Library called WebBotLib which is Open Source. More information up at: sourceforge.net/projects/webbotavrclib/

The picture shows the Axon2 board. The top row of pins are the Analog input pins. I am currently only using 1 for the SHarp sensor. The right hand side shows the USB adapter, which I am using to output debug messages. The Gray ribbon wire connects to an ISP board that I use to download programs to the board. You can use the bootloader on the board, but it is a little more complicated and slower. The servo wires are connected on the bottom and left hand side and the XBee is connected to one of the UARTS toward the top left of the board. Note: I had problems with the Sparkfun regulated adapters and I am currently using one of the ones from Selmaware (I can go more into this if anyone is interested…)

In my Code, I currently have all 7 servos connected up to hardware PWM channels and I am using the webbotlib servo class, which more or less defines the range of a servo in a byte (-127 to 127). When you define the servo you define the center point (1500) and the range (500) for the servos and it does the translations. I then wrote my own version of Servo Group move that I specify a new location for a set of servos and how much time in mS to get there and it does the work to adjust each servo. Currently I have a call out in my main loop to do this every 50ms, but may move this to an actual timer. I also then then converted the BAP basic code that for example to do a turn left that looked like:

elseif(command = 11) ; Turn left gosub movement 200, 0, 0,-140, 0, 0,500] gosub movement 200,-350,-350,-140, 350, 350,500] gosub movement 0,-350,-350, 0, 350, 350,500] gosub movement 0, 350, 350, 0,-350,-350,500] gosub movement 200, 350, 350,-140,-350,-350,500] gosub movement 200, 0, 0,-140,-350,-350,500] gosub movement -140, 0, 0, 200,-350,-350,500] gosub movement -140, 0, 0, 200, 0, 0,500] gosub movement 0, 0, 0, 0, 0, 0,500]
To be Data Driven in C. So I created a set of classes and then defined data that looked very similar:

static CMLSD1 s_cmlsd1_TurnLeft = {9, { { 200, 0, 0,-140, 0, 0,500}, { 200,-350,-350,-140, 350, 350,500}, { 0,-350,-350, 0, 350, 350,500}, { 0, 350, 350, 0,-350,-350,500}, { 200, 350, 350,-140,-350,-350,500}, { 200, 0, 0,-140,-350,-350,500}, {-140, 0, 0, 200,-350,-350,500}, {-140, 0, 0, 200, 0, 0,500}, { 0, 0, 0, 0, 0, 0,500}}}; ... SetCurrentCommandList(&s_cmlsd1_TurnLeft); //command = 11

This allowed my main input loop to simply call off to process the current moves and then call of to get input and decide if a command list is still running, decide which events I wish to process. For example I can be walking and then easily call off to have the turret servo rotate. Or if I had them on this Brat shoot the guns…

I have made some reasonable progress. It is talking to the DIY XBee remote, it is walking (although I want to probably fine tune this some), The head servo rotates and I can do a ping with the Sharp sensor and send the distance back to the DIY remote which displays the results.

If anyone is interested, I can upload the sources… Right now it is a work in progress.

P.S - Before anyone asks. No I have not abandoned working on the Basic Atom Pros. They are also great boards and I have a lot invested in them. May at some point try to port the C code back to the BAP and may try changing the Basic version Movement functions to be more data driven as well… Besides I am still waiting for the next version of the BAP manual to review and Arc32 board to play with…

Nice work- I’m interested on getting source code. On the Selmaware board is it one of the Appbee boards and if so which one?

Thx

Thanks,

First the disclaimer… This is a work in progress…

This is a silent update. I have playing with the code and it is working better than before. The code now runs the multiple servo updates on a scheduler task. Fixed some bugs in the code that was causing the walk speed to change while walking… Also fixed some stuff associated with the find zero points. More on this later.

Now that this is working better I may now play with the PS2 code. Sure is nice having two usable USARTS. Running XBEE at 62500 and the USB output for debugging at 125000 without problems!

Still having fun :slight_smile:

Today I played with the PS2 code. I now have it walking and the like with either the PS2 or the XBEE. Currently it will start off assuming PS2. If you push the button on the board it will then go to DIY XBEE, push again it will be back to PS2. May change soon to assume PS2, but if it detects that it is receiving XBEE information switch to it automatically. I thought about generating a video, but it would currently just be a rather standard brat walking around…

Still lots more stuff to experiment with… Some of the things I am thinking of trying out

  1. Migrate it to MechBrat - Add 1 or more guns to the brat and integrate the code to fire them. Should be very simple.
  2. Finish the Servo zero stuff. I currently have it that if you are holding down the button when the program starts, it allows me to use the keyboard to go to the different servos and try to find their zero points. What I need to do now is to save this information away and restore it when the program starts.
  3. This board reminds me of what we were discussing with SSC-NG. I may experiment with having code on the USB UART that accepts SSC-32 commands and tries to execute them. Not sure how far I may take it. Could probably easily do the # command, some of the Q’s, Ver, … The question will be about maybe being able to save and use sequences…
  4. Convert the XBEE code to use API mode. This would be a good experiment to see how well that mode works, before I convert all of the BAP28 code to do so.

Well that is all for now. Not sure if anyone else is interested. If not may continue on other forums…

Kurt

Edit: Silent update - I did some work on 2). I now save and restore stuff for the zero points. Relies on webbotlib version 13a
DeBrat Checkpoint.zip (28.1 KB)

I thought since I have received a few private messages on this, I would post an update talking about how servo processing is implements with the Axon2 using the Webbotlib library. First a slight background.

Webbotlib is an open source C library for several AVR processors including the ATMega640 which is on the Axon2 controller board. This library has a lot a lot of support for a lots of things like timers, servos, UARTS, sensors, … You can download it from: societyofrobots.com/robotforum/index.php

On webbotlib there is servo support both using hardware PWM as well as software generated PWM. I believe that the Axon2 with it’s 4 16 bit timers can support something like 12 hardware generated PWMs. Currently this is what I am using on this Brat.

The abstraction that is used in this library allows you to define the center point for the servo (like 1500) and the range (how far both in the + and - range you can go from there). Then you use a data type of DRIVE_SPEED which is a byte to define the actual positions you want. So you can go to -127 to +127 with 0 for center. Likewise ±64 would move you to about the halfway point from the center to the ends of the range. So if one servo is defined as (1500, ±500) and you give a position of 64, you will have an output approx 1750 where if you have a second servo defined like (1500 ± 800), the 64 will map to 1900, which is obviously different than how the values I specify on the BAP (HSERVO) or values I pass to SSC-32 work.

My current Brat code has moves defined logically in 10ths of a degree so I thought I should try to figure out what a good range would be in my definitions for the servos, such that ±127 moved the servos to about ±90 degrees. The initial code used some early values of ±500 which I knew were going to be inaccurate. I did define one with 700 which I knew would be closer. Today I implemented some simple code that using the keyboard I could move a servo to the drive speeds of ±127, ±64 and 0. Also I could use + and - key to decrease or increase the range. I also set up a quick and dirty setup with an HS645 servo some books and the like so I could see what angles were produced.

Here are some of the results.

Sorry about the photo quality and how low tech it is, but it will hopefully suffice for now. :slight_smile:

The top left is when I used a value of ±900 which I think I will use as it got me pretty close to 90 degrees. The top right was the ±700 which was off by maybe about 20 degrees. The bottom left shows when I went to 64 which is pretty close to 45 degree and the bottom right shows it at 0… That is all for now…

Kurt

It looks like there is a 5 to 7° error unless you matched the protractor to the angle of the servo horn at 0 (center). Looking at the protractor vs. the servo case, it looks to be off. I know due to the spines on the servo shaft when at center position, the horn doesn’t always go on at a true 90°. I assume you set the protractor to eliminate this difference?

Thanks Mike,

Yep you are right that the horn is not completely zeroed out properly. If I were using this horn for normal use, I would be adjusting its position. I simply installed it onto an unused 645 as it was big enough to point far enough into the protractor to see where it was going. Also I should note that the images were not shot directly above so for example the horizontal one at the bottom left looked from above to be correct. As I mentioned in a previous post, I do have code in place that I can adjust the servo zero points using the keyboard over the USB connection on the board and save them away to the EEPROM on the chip.

When I mentioned spare 645, I now have 12 of them :slight_smile:. I need 6 more to then build my own phoenix. Waiting on new leg contact design to order parts, not sure yet if I will grab another 6 645s or go for the 485s. Will probably run that one with an Arc32 board…

Thanks again Mike,

Kurt

I have wanted to explore the range of the servos also. Some sort of calibration fixture, with perhaps a high-resolution encoder? Austria Micro Systems comes to mind. I have one of their high-resolution encoders.

austriamicrosystems.com/eng/Products/Magnetic-Encoders/Rotary-Encoders

A metal hub with a metal arm scribed with a centerline might help, and be easier to make. Use of available protractors would be convenient, although I suppose I could scribe a protractor in the mill as well.

I’m wondering about the alignment of the R/C servo in the fixture. With the differences in servo bodies, and the spacing of the mounting holes, how do you “align” the servo in the fixture?

Alan KM6VV