Hexapod robot update: walking, MATLAB code and AVR studio code

Posted by Happy Hippo on 10/16/2011 09:24:00 pm
Note: the code (both controller and MATLAB) need a lot of improvement especially to address how quick the robot responds and routines need fine tuning (each servo is slightly different for example). It's just first rough draft that is working. I will work on it when I have free time again over Christmas period. As well as addressing mechanical problems, since currently the joint are too flexible.


1) I added some capacitors (100 uF, 10uF, 1uF, 1nF) in parallel with the 3 batteries to stabilize current fluctuations and improve the battery life. About 3 pounds from Maplin Electronics.

2) Set UART2 (WIRELESS_UART) buffer to 1024, otherwise it stops working often.

3) My AVR studio code is quite long now , but basically what it does is:
 - Start: turn off servos (in software initialisation function)
 - Read character from UART2 (bluetooth serial) and depending on what that character is do things. I wrote a whole bunch of different commands depending on what is sent through uart.  For example if I send "m12145d" it means "m1: move 1 servo, then next two chars: 2, 1 are leg_ID, joint_ID, and last three are servo position (angle) where 'd' or 'r' indicares whether to move "direct" or "reverse" , i.e. +- angle" And similar. For example m6: move 6 servos simultaneously. m9: 9 servos etc.

4) I wrote my walking gait by working our geometrically the angles I need to move the body in a particular direction say by 5cm at a time. There is a long list of move_9s (...) commands in the AVR code that include run eight 3x3 matrices for this gait.
Here are my AVR studio source files: http://www.mediafire.com/?6u3vancozpzcg66

5) I can send characters one by one from MATLAB, even at 9600 baud rate I can send chars every 0.1 ms. But with big buffers in UART and in MATLAB I can actually forget about this (althoughI set a limit to read robot uart not faster than every 0.5ms).

My MATLAB code has some functions now just to get rid of writing low-level fprintf command every time. The main file is main_script.m (note some of those functions are not so useful anymore, only the ones used in main_script.m). Here are the source files: http://www.mediafire.com/?x82x6co2y35h8cs
Update: sorry the file was unavailable, mediafire thought I was sharing MATLAB distribution since I called it "MATLAB" and they deleted it automatically, what they didn't see was the file size was only 6kilobyte :D

And finally, a video of main_script.m running from MATLAB:

Video 2

If you have any questions, suggestions etc post a comment. I just re-enabled notifications of comments, so I will reply asap :)

P.S. I was asked to give more explanation about the code by e-mail, so I decided to paste this e-mail here, as it may be useful :
The controller code is programmed into the robot (not the matlab code). And there I wrote a number of things for the robot to do , depending what it receives via bluetooth serial port and RS-232  protocol. This protocol is used to send 8 bits of data at a time (i.e. 1 byte, or 1 character). With baud rate set at 9600 I can send 1 character every 0.1 milliseconds. This is ok to send data from time to time, but it is not enough (although maybe my code is not optimized) control servos 1 at a time. So what I had to write was basically to do a number of actions for some characters sent. Currently I have the  following character communication setup:
if I send :

"m" : means move.
       -"1", "3", '6", "9" : how many servos to move
       -and then depending on the number of servos parameters for each servo in format: leg_id, joint_id followed by two digits and followed by "r" or "d" ("r" for reverse or - movement and "d" for direct movement). I.e. if I send    "m12345d" (1 character at a time) it will move servo 1 on leg 2, joint 3 by +45 degrees.  If I send m3 I  will to send parameters of 3 servos etc (i.e. 3x leg_id, 3xjoint_id, 3xpositions).
"i": moves the servos incrementally , similar structure to "m" but
needs more work on code, not so good.
"f": turn off power to servos

"o": turn on power to servos

"r" : reset all servos to 0

"w": walking routine. Followed by another single character (0-5) that
specifies in which direction to walk ( I call it leg shift). If I sent "0" it will walk in the direction between legs 0 and 6, if "1" it will  go in the direction between 1 and 2 legs and so on.  Next character is "delay" that sets the delay between leg moves (but needs more work).  So I usually send "w07" or "w19" etc.
"s": is supposed to be "smooth walk" , has similar structure to "w".
Needs a lot of work.

Ok, this outlines that basic idea so far. Now specifically with MATLAB
code, first open main_script.m  . This has action that are done in my robot testing videos. The command:

s = serial ... 
creates a "serial port" object (i.e. so your program knows where to send data). This will only work after you "pair" up
robot bluetooth card and your computer (just as any other bluetooth device).

Other commands basically wrap what I wrote above about character
command in a nice way. I.e. don't want to type fprintf(s, ... ) all the time to send characters. I just want to be able to say move 1  servo and give some parameters , instead of m13245r. I think it's quite self explanatory. Btw, the function that sends 1 byte is  fprintf. I.e. it I write:

fprintf(s, '%s\n', 'f');

This will send "f" to the controller, and the controller will find
what to do with it (i.e. turn off power to servos). So instead of
writing this, I wrote a function servos_off.m

I hope that helps.


Great! MATLAB posted about your hexapod here: https://www.facebook.com/MATLAB/posts/280255658672098

Conratulations and thanks for the code files (mediafire issue :D)

Ingin menambah pengetahuan anda lebih jauh bro ??
anda bisa mengunjungi website kami di bawah ini tersedia banyak informasi dari seluruh belahan dunia :

1. http://988betlink.com/
2. http://mizuhobbs.net

© All content on this site is copyright, except where other sources are specified. Please contact me before using any resources on this blog in any way ©