I recently was shown an equation for a spherical wave, given as an E-field vector field:
It looked interesting, so I decided to try to visualize it to understand better how would such a vector field, directed along phi unit vector, generate a spherical wave? For this I used MATLAB MuPad application to convert the equation to Cartesian form and then generated some plots.
Slice plots of E-field magnitude:
Iso- surfaces of magnitude of E-field:
High intensity isosurfaces
Medium intensity isosurfaces
Low intensity isosurface (becomes more spherical) , as seen with circles here: http://www.1stardrive.com/solar/mechs8.gif These "doughnut" shape features shrink in size because the intensity decreases with distance (as 1/r^2), however, if we normalize the intensity by r^2, we will now see where each individual point of E-field propagates with time, and the "doughnuts" will just expand, as shown on the right.
Some more:
B-field and Poynting vector intensities are coming soon !
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.
Updates:
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
Serial Bluetooth RF transceiver module with backplane
20x micro servos SG9 (but they are not very good quality: very difficult to attach servo head, wobbly, noisy), rated at 7.2V
2x 1800mAh Li-Ion batteries, NB-2LH, sold only on ebay with so high mAh. And a charger .One battery stopped working today :( My total current was peaking at 4A, so each battery was getting about 2A (maximum, or ~1A average). So I will look for a better solution.
Update: I decided to use 3 of these Li-ion batteries in parallel to reduce the load on each and improve mAh. So far it has been working fine. Even with maximum stress (running :)
50x self tapping screws,cross head, 1.7x5 mm or 2x6mm, try to find with pointy end (not flat). http://tiny.cc/quqq3
Three batteries are needed to reduce the load on them. But a tiny bit more space is needed on the bottom of the base for three batteries, so the wooden pieces that are inserted between two disks should be maybe 0.5cm more.
A much easier way to make battery mount is to remove a thin wire with metallic end from a futaba head, then make a small hole in the battery cover (that comes with the battery), pull that wire through with wire going 1st. If the hole is small enough, it will hold the metal end nicely.
3. Outer leg wooden part (thin end pieces) are not quite proper for this robot, they are not strong enough and make servos use a lot of power :( I suggest to make round end pieces, with wider and thicker wood. And attach to the servo perpendicularly, with screws. (alternatively design all parts in a 3D program and print on a 3D printer)
4. Those cheap e-bay servos are not very good.. they are working, but not accurate at all. The plastic disk is very weak, and it wobbles. I'll try to attach some other plastic parts and see it it's going to help. It's better to pay a little bit more, but get better built servos.
5. It is also very convenient to drill a hole to access the screws which hold servo "head" in place, because a LOT of adjustments will be required.
First steps!
I will upload walking hexapod video and more source code, as soon as I figure it out :)
Thanks for watching :)
These "doughnut" shape features shrink in size because the intensity decreases with distance (as 1/r^2), however, if we normalize the intensity by r^2, we will now see where each individual point of E-field propagates with time, and the "doughnuts" will just expand, as shown on the right. 
These "doughnut" shape features shrink in size because the intensity decreases with distance (as 1/r^2), however, if we normalize the intensity by r^2, we will now see where each individual point of E-field propagates with time, and the "doughnuts" will just expand, as shown on the right. 
