I had the privilege to see some pictures from your work earlier. But I just had to compliment you trough this channel as well!
You know I really admire your work and creativity! I see that the globe idea is really working out pretty cool! It would be pretty cool to stand on place while expending the body itself.
I love the “Dead Star” picture! It also showed how compact the build must be to fit everything in the sphere. This made me kinda wondering where you are gonna fit the battery? I bet there is no massive LiPo this time?
Yeah, thats the plan to do and it shouldn’t be to hard to make either. I’m planning to add different modes in the code, where I exclude the coxa calculations in the IK part so that it allow the feet to move under the body. When doing the body expanding part the coxa’s need to be adjusted about 15 deg. Some simple trig.calc’s should solve that part.
Well, I’m using some “military spec” LiPo’s this time. I’ve bought two of them from Trossen Robotics trossenrobotics.com/store/p/6300-2S-7-4V-2000mAh-Pro-Lite-Military-Spec-LiPo-Battery.aspx. What I really like with them is that they (2S 2000 mAh) have an almost quadratic dimension (13 x 50 x 65 mm) and a good weight vs. capacity ratio. I’m planning to place them on the other side of the inner body, just above all the gears.
BTW:
Great news! We got our son #3 at Sunday night! We are naming him Torbjørn (english = Thor + Bear). Everything is fine with my wife and the baby.
I hope to get back into robotics when everything has settled a little. I’ve almost forgot how it was to have a little baby again, even A-Pod is larger than my little son (maybe a cool picture would be fun) .
Its been awhile since I posted anything about MorpHex. I’ve not got much time for it either. Sadly this has to be a longterm project.
Anyway, I just wanted to post some minor updates. I’ve added two decks (acrylic, I’m not sure to be honest) that are going to hold the electronics on one side and the battery on the other side: http://zentasrobots.com/wp-content/blogs.dir/3/files/2011/04/MorpHex_040411_00003.jpg
Still a lot of work left. But thats kinda good thing since I’m strongly considering to build a humanoid using the 5990’s, meaning that I’ve not wasted to much time.
Its much easier to work on MorpHex when you have a strong stand:
Talking about LiPo. I’m considering to apply the 5990’s directly to the LiPo without any regulators. So I’m using some self-made power distributors, the principle is very easy. Only ground and signal are connected to the SSC-32.
A picture of the power distributors:
I did a little more work yesterday evening/night. A minor setback is that I can’t use the ARC-32 + SSC-32 combo, simply because it takes to much space. So I’m using the ARC-32 only. Hopefully that will work, i just can’t use the 6 DOF IMU I originally planned to use. So I’m going for the Razor 9 DOF IMU + XBee + some new cool lighting stuff from BasicMicro (36 RGB LED’s to be exactly). So the ARC-32 are going to be really stuffed…
Lately I’ve been busy with Basicmicro’s prototype serial controlled RGB LED’s called StarLites. With the latest IDE (2.0.0.13) with the fixed pacing part in the serout command they work very fine. Every StarLite can be controlled individually if you’ve assigned an unique address. The color are defined by one byte 3 bit blue, 2 bit red and 3 bit green. The colors can fade from one color to another. The fading time can also be set. Also a sequence of color shifting can be defined. I’m planning to use 3 StarLites on each of the 12 sphere segments. The StarLites are very small, about 10x16mm and comes with two mounting holes. I’ll post some pics later.
Yesterday I also played a little with Sparkfun’s 9DOF IMU and uploaded the 9 DOF AHRS code. What the code do is to simply spit out roll,pitch, yaw angle data continuously at 57600 baud every 20 mS. With the AHRS code the IMU really show how well it works, very cool! I think I need to buy another one for my biped too one time.
I’ll have to do some experiments to use serin to get the correct data. What I don’t like is that the main ARC-32 code (Xan’s Phoenix code) have to wait at max 19-20mS (worst case). I’m wondering if there is a way to simply tell the IMU that I’m ready for getting new data instead of waiting for the next stream of data to come. I’m a bit stuck when it comes to this part of programming, but I’ll give it a try. I need to use the IMU for reading the exact orientation of the sphere/MorpHex. Its’ easy to work in the Arduino editor for modifying the code. For Morphex I don’t need the high angle resolution, no decimal is fine I think.
I’ll keep you posted when I’ve done some more work on this project.
If you look at the link for the IMU you’ll see that you can download Arduino code for the IMU. I’m using the AHRS code.
Yeah, I guess I’ve to look into the hserial. XBee already uses one of the UARTs. Maybe I can use the other one, some jumpers (JP5) needs to be removed after every code upload though. I feel I’m getting into deep water when it comes to this type of coding though…
What about the software serin command and use the wait option? That would halt the program I believe. I think I need to study more around this before i start rambling with stupid questions.
The New Softserial library allows for input buffering. The current version only works with 1 I believe. A new beta version works with multiple inputs but only one at a time… I used it in the Arduino (non Mega) version of the phoenix code, which is in a zip file up under that thread.
At first I’m thinking not to do much changes to the Arduino code, just let the IMU spit out the angle data and read the data when I need it from the ARC-32. Using hserin (UART1, s_in) means that I read the buffer and save processor time? UART2 are used for XBee so I can’t use that one.
I’ve just started doing some testing around the hardware serial.
The TX line of the IMU are connected to the RXD2. This part is just the beginning of the program, the code before the main loop:
[code];*** ARC-32 + Razor 9DOF IMU AHRS code test program ***
;This program simply grab the serial stream from the IMU using Hardware serial, hserin.
pause 1
RXstring var byte(13)
ENABLEHSERIAL2
sethserial2 h57600 ;Set UART2
pause 10
serout s_out,i9600,"*** ARC-32 + Razor 9DOF IMU AHRS code test program ***",13][/code]
I’m using the serout for debugging and info. What puzzle me is that the serout doesn’t seem to work after setting the sethserial2.
The result in the terminal window look like this (the baud are set to 9600 in the terminal too):
I thought that you could use serout even if you use hardware serial too?
Another thing, is the ENABLEHSERIAL2 really needed, I can’t see it mentioned in the reference manual V2.0.
EnableHSERIAL and EnableHSERIAL2 are no longer needed.
As for garbage characters, yes you can still user serouts (probably not on the same IO pin)
However if the IMU is sending out lots of data, causing the Arc32 to be interrupted a lot, the bit bang serouts often have problems… This is why I will then also convert the serout s_out commands over to hserial…
Another Q, does RXD2 read 3,3v signal level from the IMU or do I need a levelconverter?
my hserin keep timing out.
This is the code I use:
[code];*** ARC-32 + Razor 9DOF IMU AHRS code test program ***
;This program simply grab the serial stream from the IMU using Hardware serial, hserin.
pause 1
RXstring var byte(13)
sethserial1 h9600
sethserial2 h57600 ;Set UART2
My guess is the 3.3v signal coming in will be fine, as for example I believe the sparkfun XBee adapter does not upshift the TX line at all and it works with the Baps/Arc32. Have had issues with some Atmegas (Axon2, have heard others with issues with Arduinos) with the sparkfun adapter.
But by spec pages 400-401 of the H8/3687 hardware manual pdf:
Vcc = 5v
Low signal for RX2 is defined in the range of: -.3 - 1.5v (Vcc*.3)
High signal is: 3.5v(Vcc*.7) - 5.3 (Vcc + .3)
So for sure the high Lee coming from a 3.3v source will be in the undefined range, but as I said it works with the XBee.
Are you going to beat me to it? 
I need to use the IMU for reading the exact orientation of the sphere/MorpHex. Its’ easy to work in the Arduino editor for modifying the code. For Morphex I don’t need the high angle resolution, no decimal is fine I think.