PDA

View Full Version : O-K: MX-28 Darwin-OP Inspired Biped



Upgrayd
04-08-2012, 05:44 PM
This weekend I have started work on a new biped project.

Some of you may be familar with my previous biped project (http://forums.trossenrobotics.com/showthread.php?4855-Upgrayd-s-AX-12-Darwin). This new biped could be considered a continuation of the previous one but I belive that the platform is different enough to warrant a new thread.

Project Goals
Mostly autonomous platform to compete in many of the non-combat humanoid events at RoboGames.
To use as simple and as few unique aluminum as possible.
Designed in such a way that all controller electronics can fit in a 'backpack' allowing the mechanical platform and control solution to be independent of one another.
Have fun and learn alot!

Robot Specs
DOF: 20
Actuators: Dynamixel MX-28 servos
Controller: BeagleBone (http://beagleboard.org/bone) single board computer with custom interface 'cape' (to be designed)
IMU: SparkFun 9 DOF Razor (http://www.sparkfun.com/products/10736) running custom firmware.
Vision: USB webcam (TBD)
Software: C and C++ Stripped down and modified Darwin-OP source (as used in UpMech)
Frame: Mix of standard and custom aluminum brackets designed with Autodesk Inventor
Skin: 3D printed shell (TBD)

First pass mechanical design/assembly:
http://forums.trossenrobotics.com/gallery/files/3/3/1/6/irinventor4_thumb.png (http://forums.trossenrobotics.com/gallery/showimage.php?i=4508)

Backside:
showing a placeholder for battery and possible areas for voltage regulation and power distribution boards behind the shoulders.
http://forums.trossenrobotics.com/gallery/files/3/3/1/6/irinventor5_thumb.png (http://forums.trossenrobotics.com/gallery/showimage.php?i=4509)

Comments, suggestions and criticism are welcome!

cire
04-08-2012, 06:28 PM
Looks pretty good, very compact upper body for sure.

One comment - keep an eye on your center of gravity, if you throw everything on the back then you will have to shift the body forward. Not a big deal if its only a little bit, but it can hinder your range of motion of the legs if it is shifted too much. Also it looks kind of silly if you shift the body forward a lot.

DresnerRobotics
04-08-2012, 09:44 PM
I'd suggest extending the body height a bit and making use of that gap to install the lipo between your shoulder/hip servos. Would be nice and close to your COG and improve the aesthetics a bit.

Looks great, I smell a TRC Robocup team in the works.

Upgrayd
04-09-2012, 08:47 PM
two things:

1. I took both Cire and Tyberius' advice into consideration and have moved the battery into the torso moving its COG forward. Anatomically this looks more correct as it was a little stout in its upper body however I am concerned about locking myself into a specifically size battery.

2. As per one of my stated goals to reduce unique parts I have adjusted the configuration of the legs and replaced the Darwin-esque tibia brackets with some common brackets.

http://forums.trossenrobotics.com/gallery/files/3/3/1/6/irinventor6_thumb.png (http://forums.trossenrobotics.com/gallery/showimage.php?i=4510)

Upgrayd
05-11-2012, 06:14 PM
I have been making a lot of progress working with the BeagleBone as a robot controller.

Most recently I have had some success implementing the hardware and software required to read and write data to and from ax-12 servos as seen in this video:

http://www.youtube.com/watch?v=IrkhPu0I_g8

I do not have any MX servos yet to test but the interface should remain the same. Fun stuff!

jwatte
05-11-2012, 11:26 PM
That design looks fun!


I am concerned about locking myself into a specifically size battery.

You'll need to pick some battery, right? Pick one right now that is big enough. Build for that. If you really, really need a different shape later, let it poke out the back, or use two parallel packs, or something. Or use a bracket that lets you slide the upper torso up/down to compensate, and some extra-length wires :-)

RobotAtlas
05-15-2012, 03:04 PM
> Controller: BeagleBone (http://beagleboard.org/bone) single board computer with custom interface 'cape' (to be designed)

Why not use FitPC2 and a new CM-530 controller from Robotis?
My thinking here is this should allow you to reuse (most?) Darwin-OP code instead of creating [the same] things from scratch.

tician
05-15-2012, 06:04 PM
Why not use FitPC2 and a new CM-530 controller from Robotis?
My thinking here is this should allow you to reuse (most?) Darwin-OP code instead of creating [the same] things from scratch.

The CM-530 is not the same as the CM-730. They both use the same STM32 ARM Cortex-M3, but not much else. The CM-730 has several analog inputs broken out, onboard digital 3-axis gyro, onboard digital 3-axis accelerometer, and can directly control power to the dynamixel bus. The CM-530 has only six analog inputs, no I2C or SPI interface broken out, and is not software compatible with the CM-730 (would require quite a bit of modification to get it working even close to the same - probably as much as writing it from scratch for the BeagleBone). There are other differences, but none are quite as relevant as the above.


If the BeagleBone can directly control the dynamixel bus via a 'cape', then it could eventually act as a far more advanced CM-730 if it is later decided to be inadequate as the main controller (video processing, navigation, voice recognition, etc.). In that case, you could more or less have the BeagleBone autonomously keeping the bot balanced and performing basic user interaction, and then either add a fitpc2/fitpc3/netbook/etc. directly to the bot or send the webcam video over wifi to a remote pc for more advanced vision/navigation.

Upgrayd
05-15-2012, 07:37 PM
>Why not use FitPC2 and a new CM-530 controller from Robotis?
My thinking here is this should allow you to reuse (most?) Darwin-OP code instead of creating [the same] things from scratch.

small size, light weight, nice form factor, ease of use, availability, direct access to IO, spi, multiple uart, i2c, fun learning experience, possibility to develop (cape) into a product.

:)

jwatte
05-16-2012, 04:15 PM
Beware, though, that if you mix hard-real-time things like direct control synthesis, with softer things like UI or high-level protocols and a Linux kernel, you may end up with poor performance on the hard-real-time things. In my own project, I chose to put in very cheap AVR microcontrollers for all the hard-real-time things and then communicate out to a general-purpose Linux board for higher-level things. Those AVRs are so cheap, I could put in one per servo and still come out ahead ;-)

RobotAtlas
05-19-2012, 08:27 AM
> small size, light weight, nice form factor, ease of use, availability, direct access to IO, spi, multiple uart, i2c, fun learning experience, possibility to develop (cape) into a product.

That's a lot of good reasons that are hard to argue with. :)