PDA

View Full Version : arbotiX VS Gumstix for Bioloid



SteamAutomaton
10-23-2011, 06:33 PM
I am leaning towards one but I am looking for more experienced reviews from people that has used one or both.

kamondelious
10-23-2011, 07:47 PM
Hey SteamAutomation.

Seems to me you're trying to decide between apples and oranges. The Arbotix has a microcontroller, the gumstix requires an OS. So it really depends on what your goal is and what your comfort level is with their respective requirements.

I have an Arbotix and a Beagleboard (comparable to a gumstix) and both work great. I find the Arbotix is better for getting something working faster, but if you need more processing power, then the gumstix might be the way to go.

Cheers!

:D

SteamAutomaton
10-24-2011, 06:17 PM
Hey SteamAutomation.

Seems to me you're trying to decide between apples and oranges. The Arbotix has a microcontroller, the gumstix requires an OS. So it really depends on what your goal is and what your comfort level is with their respective requirements.

I have an Arbotix and a Beagleboard (comparable to a gumstix) and both work great. I find the Arbotix is better for getting something working faster, but if you need more processing power, then the gumstix might be the way to go.

Cheers!

:DMy plan is to build animatronic character. I believe that the gumstix or similar uPC will give me better in sync control and expansion. I was going to with the arbotix first since I have experience with Ardruino. But what my plans are, I think I need more serial channels for everything to be in sync.

tician
10-24-2011, 07:21 PM
How many DOF do you plan for your animatronic character? What actuators are you using (hobby servos, dynamixels, pneumatics/hydraulics, linear actuators)? How many serial ports do you really need (how many sub-controller boards are you using)? If you are going for the least expensive multi-UART solution you can, try looking at the Arduino Mega as the ATmega1280/2560 have four UARTs and up to 14 PWM pins (~$60 versus ~$100 for the arbotiX, ~$150 for the BeagleBoardXM, ~$174 for the PandaBoard, and upwards of $200 for a functioning Gumstix development environment).

SteamAutomaton
10-31-2011, 06:09 PM
How many DOF do you plan for your animatronic character? What actuators are you using (hobby servos, dynamixels, pneumatics/hydraulics, linear actuators)? How many serial ports do you really need (how many sub-controller boards are you using)? If you are going for the least expensive multi-UART solution you can, try looking at the Arduino Mega as the ATmega1280/2560 have four UARTs and up to 14 PWM pins (~$60 versus ~$100 for the arbotiX, ~$150 for the BeagleBoardXM, ~$174 for the PandaBoard, and upwards of $200 for a functioning Gumstix development environment).Currently, I have 25 AX-12+s and 4 AX-18As. From my understanding from another thread, there is a 8 Dynamixal AX series bandwidth limit for keeping everything in sync. This would require splitting each limb and the body to its own bus (five buses). Also, the form-factor needs to be looked in to also (I have not looked closely at that yet).

Thoughts?

lnxfergy
10-31-2011, 06:28 PM
From my understanding from another thread, there is a 8 Dynamixal AX series bandwidth limit for keeping everything in sync.

Link? I have never had an issue keeping 18+ servos in sync (it's called SYNC_WRITE for a reason)....

-Fergs

tician
10-31-2011, 08:56 PM
Read Position (8 Bytes)
START, START, ID, LENGTH, INST_READ, LOCATION, NUM_BYTES, CHECKSUM
Response (8 Bytes)
START, START, ID, LENGTH, ERROR, LOW, HIGH, CHECKSUM

Write Position (9 Bytes)
START, START, ID, LENGTH, INST_WRITE, LOCATION, LOW, HIGH, CHECKSUM
Response (5 Bytes)
START, START, ID, ERROR, CHECKSUM

Assuming a negligible amount of time for the processor to build useful goal position packets from the received position packets (e.g. a PC running at >1 GHz):

Worse case (without Sync Write) is 30 bytes + latency (say, one byte per packet?) = 34 bytes (conservative guess that is in no way based on reality) transmitted at 1Mbps 8N1 (one start, eight data, one stop).
(1 000 000 bits/s) / (10 bits/byte sent) / (125 Hz) / (34 bytes/servo) = ~23 servos updated at 125 Hz (8 ms interpose length as used by DARwIn-OP motion modules)
(1 000 000 bits/s) / (10 bits/byte sent) / (30 Hz) / (34 bytes/servo) = ~98 servos updated at 30 Hz (33 ms interpose length as used by the arbotiX BioloidController)

With Sync Write, the packet length is 16+2 for polling and 8+1 + (3*Num_Servos) for writing.
(1 000 000 bits/s) / (10 bits/byte sent) / (125 Hz) = ((16+2)*Num_Servos) + (8 + 1 + (3*Num_Servos)) ==> (791 bytes) = (21*Num_Servos) ==> Num_Servos = ~37 servos at 125 Hz update rate
(1 000 000 bits/s) / (10 bits/byte sent) / (30 Hz) = ((16+2)*Num_Servos) + (8 + 1 + (3*Num_Servos)) ==> (3324 bytes) = (21*Num_Servos) ==> Num_Servos = ~158 servos at 30 Hz update rate

SteamAutomaton
11-02-2011, 04:41 PM
Link? I have never had an issue keeping 18+ servos in sync (it's called SYNC_WRITE for a reason)....

-Fergshttp://forums.trossenrobotics.com/showthread.php?1437-The-Ultimate-Bioloid-Thread/page44

That is good to know.:)

SteamAutomaton
11-02-2011, 05:52 PM
Read Position (8 Bytes)
START, START, ID, LENGTH, INST_READ, LOCATION, NUM_BYTES, CHECKSUM
Response (8 Bytes)
START, START, ID, LENGTH, ERROR, LOW, HIGH, CHECKSUM

Write Position (9 Bytes)
START, START, ID, LENGTH, INST_WRITE, LOCATION, LOW, HIGH, CHECKSUM
Response (5 Bytes)
START, START, ID, ERROR, CHECKSUM

Assuming a negligible amount of time for the processor to build useful goal position packets from the received position packets (e.g. a PC running at >1 GHz):

Worse case (without Sync Write) is 30 bytes + latency (say, one byte per packet?) = 34 bytes (conservative guess that is in no way based on reality) transmitted at 1Mbps 8N1 (one start, eight data, one stop).
(1 000 000 bits/s) / (10 bits/byte sent) / (125 Hz) / (34 bytes/servo) = ~23 servos updated at 125 Hz (8 ms interpose length as used by DARwIn-OP motion modules)
(1 000 000 bits/s) / (10 bits/byte sent) / (30 Hz) / (34 bytes/servo) = ~98 servos updated at 30 Hz (33 ms interpose length as used by the arbotiX BioloidController)

With Sync Write, the packet length is 16+2 for polling and 8+1 + (3*Num_Servos) for writing.
(1 000 000 bits/s) / (10 bits/byte sent) / (125 Hz) = ((16+2)*Num_Servos) + (8 + 1 + (3*Num_Servos)) ==> (791 bytes) = (21*Num_Servos) ==> Num_Servos = ~37 servos at 125 Hz update rate
(1 000 000 bits/s) / (10 bits/byte sent) / (30 Hz) = ((16+2)*Num_Servos) + (8 + 1 + (3*Num_Servos)) ==> (3324 bytes) = (21*Num_Servos) ==> Num_Servos = ~158 servos at 30 Hz update rateYour math is correct, but are you missing a variable? I am having a hard time envisioning that a higher updating rate has lower number of updated servos. I thought higher update rates meant more in sync servos.:confused:

tician
11-02-2011, 07:42 PM
Fixed baud rate (amount of data that can be sent over some time period). Fixed packet length (amount of data per servo per goal position update). Either send more packets (higher update rate) to fewer servos, or fewer packets (lower update rate) to more servos.

Not sure where Gorbag got that 8 servo 'practical' limit. Almost every design released by Robotis that is not in the 'Basic' series has 7 (Gerwalk) to 18 (Humanoids) AX-12 on a single bus with no problems. For a while there was a Type-A humanoid (18 AX-12) in the lab that had two Hylands Foot Pressure Sensor boards and an AX-S20 bringing the total devices up to 21 (with two ADC inputs for a gyro and one for the Sharp IR distance sensor in the chest). The DARwIn-OP is made from twenty MX-28 and one CM-730 (it behaves a bit like the arbotiX by being both a device with inputs/outputs and a pass through for packets between the USB2UART IC and the dynamixel bus) on a single bus at default of 1Mbps, with plenty of growing room (especially if you take advantage of the higher available baud rates of the MX-series). Not sure where I got the DARwIn-OP being made from 22 MX-28 in my post in the thread you linked.

r691175002
11-03-2011, 12:51 AM
Until you saturate the bus I don't think there will be a problem. Any latency will be completely overshadowed by mechanical inaccuracy and the resolution of our vision.

tician
11-03-2011, 08:27 AM
Until you saturate the bus I don't think there will be a problem.
Which is the source of the problem, the faulty premise that the dynamixel bus will saturate at ~8 servos. If for some reason you were using the bus at a baud rate of 57600 bps, then yes, the bus would saturate at ~6 servos with goal positions updated at 30 Hz (without sync write). However, the default baud rate for the AX-12 is 1Mbps, leaving lots of room.

SteamAutomaton
11-04-2011, 07:37 PM
[QUOTE=tician;49836]Fixed baud rate (amount of data that can be sent over some time period). Fixed packet length (amount of data per servo per goal position update). Either send more packets (higher update rate) to fewer servos, or fewer packets (lower update rate) to more servos.QUOTE]
Okay, that makes more sense. Thank you.;)

Xevel
11-08-2011, 01:16 PM
It seems to me that the origin of the "8 servos max" has something to do with the fact that Gorbag was talking about control loops: sending positions, then retrieving the real position to perform corrective actions if needed.

I use a big control loop for the legs of my Xachi : read the real positions, compute the actual positions of the feet with forward kinematics, compute the corrections needed to have the feet where they should be, compute inverse kinematics, send all positions.
With 16 servos in these big control loops, it gets quickly hard to keep even a modest update rate of a few Hz :/

tician
11-09-2011, 02:07 PM
With 16 servos in these big control loops, it gets quickly hard to keep even a modest update rate of a few Hz :/
Which is a limitation of the controller's processing power and the software's utilization thereof, rather than the dynamixel bus being saturated (which I think was Steam's initial reason for looking at systems with multiple UARTs).

So the real question is: Will the animatronic character be using predefined poses (arbotix) or a complex control system with lots of nasty 16/32/64-bit floating/fixed point math (Beagle Board (ARM), FitPC2/mini-ITX/netbook/laptop (x86), etc.)? Or a combination of both (arbotix for read/interpolate/write and a more powerful controller for the rest)?

SteamAutomaton
11-09-2011, 06:27 PM
So the real question is: Will the animatronic character be using predefined poses (arbotix) or a complex control system with lots of nasty 16/32/64-bit floating/fixed point math (Beagle Board (ARM), FitPC2/mini-ITX/netbook/laptop (x86), etc.)? Or a combination of both (arbotix for read/interpolate/write and a more powerful controller for the rest)?My real answer is: ;) The animatronic character will have mostly predefined poses for the top half, however walking will be adjustable with gyro/accel. Plus, the head :robotsurprised:(about softball size) will be needing very small (pico/micro) sized RC servos (no feedback will be needed). Unfortunately, Robotis will probably will keep the AX line their smallest ones that they offer.

r691175002
11-10-2011, 12:23 AM
I would almost never use the computer on a board type systems for this kind of stuff.

The artbotix is essentially an arduino mega with a few shields tacked on. You can get an arm cortex M3 dev board for as little as 12$ ( http://search.digikey.com/scripts/DkSearch/dksus.dll?WT.z_cid=sp_497_0928_buynow&site=us&lang=en&Enterprise=44&mpart=STM32VLDISCOVERY ) and an arduino compatible version for 35$: http://leaflabs.com/devices/
(http://leaflabs.com/devices/)
A 72MHz 32-bit micro-controller is several orders of magnitude faster than the 8-bit atmels, equal or cheaper in price and just as easy to program for.

Using linux/ROS type stuff is insane overkill and trying to do floating point math on an 8-bit is dumb.

lnxfergy
11-10-2011, 01:06 PM
The arbotix is essentially an arduino mega with a few shields tacked on. You can get an arm cortex M3 dev board for as little as 12$

It's not just about the board, we have a number of libraries and tools so that you don't spend time reinventing the wheel. Those libraries/tools will not work on the M3, since they have a number of low-level register accesses. Certainly you could build a similar board cheaper, but you would then spend a bunch of time designing a board/libraries, rather than programming your robot. I realize that isn't what everyone wants, but for a number of people out there they prefer to be writing code rather than mucking around wire wrapping together something and hoping it doesn't fall apart mid way through some competition or demo.


Using linux/ROS type stuff is insane overkill and trying to do floating point math on an 8-bit is dumb.

If all you are doing is replaying poses, and then maybe shifting those poses a bit, there shouldn't be any floating point math. But more importantly, if you have enough processing power to do what you need on the 8-bit micro, then using the 8-bit micro is not dumb.

-Fergs

SteamAutomaton
11-14-2011, 06:13 PM
It's not just about the board, we have a number of libraries and tools so that you don't spend time reinventing the wheel. Those libraries/tools will not work on the M3, since they have a number of low-level register accesses. Certainly you could build a similar board cheaper, but you would then spend a bunch of time designing a board/libraries, rather than programming your robot. I realize that isn't what everyone wants, but for a number of people out there they prefer to be writing code rather than mucking around wire wrapping together something and hoping it doesn't fall apart mid way through some competition or demo.

If all you are doing is replaying poses, and then maybe shifting those poses a bit, there shouldn't be any floating point math. But more importantly, if you have enough processing power to do what you need on the 8-bit micro, then using the 8-bit micro is not dumb.

-FergsAs much as I like soldering, I do that at work as a test technician. I like to leave work at work.:p

Will the arbotX control about 40 servos with accel/gryos?

SteamAutomaton
10-06-2012, 08:59 PM
Another question:

How many PWM channels does the arbotiX have?

jwatte
10-07-2012, 01:30 AM
Here's what I did:
1) Google "arbotix specs"
2) Click the top link, which should be this: http://www.vanadiumlabs.com/arbotix.html
3) Find "PWM" on that page
4) That page says there are 2 channels of PWM supported with the built-in libraries

Alternatively:
1) Google "atmel Atmega644p datasheet"
2) Click the second link (the doc8011.pdf file) which should be this: www.atmel.com/images/doc8011.pdf (http://www.atmel.com/images/doc8011.pdf)
3) Note that there are three timers, each of which has two comparators, so a max of 6 channels of PWM -- but you may need the timers for timing other things (like milliseconds and microseconds.)

And, finally:
1) Also note that the Arduino hobby servo library (if this is what you'll use the PWM for) actually uses a single 16-bit timer to run all the servos, programming interrupts for the high/low transitions, one at a time, at about a 30 ms loop time. That gives you a max of about 16 hobby servos within the 30-millisecond window. I imagine you could do a similar thing on the arbotiX.

lnxfergy
10-07-2012, 03:57 AM
Another question:

How many PWM channels does the arbotiX have?

Depends on the library used and how many other things are in use.

The hservo (or hardware servo) library that ships with the ArbotiX library is based on older versions of the servo library, uses timer1 to generate 2 fully-hardware based servo channels (which come out on headers labeled Servo A and Servo B). While this only gives 2 channels, the servo will basically never glitch because the servo pulses are generated entirely by hardware timers.

The servo library that ships directly with Arduino IDE, but will work on the ArbotiX, can do several more channels. I believe they say 8 max, although it really depends on how much other stuff is going on because this library uses timer1 to trigger an interrupt, and then generates the pulses inside that interrupt -- thus, if the interrupt is delayed because something else is in an interrupt handler, the servos will start to "glitch" as the pulses will be changing in length.

-Fergs

SteamAutomaton
10-07-2012, 06:56 PM
Here's what I did:
1) Google "arbotix specs"
2) Click the top link, which should be this: http://www.vanadiumlabs.com/arbotix.html
3) Find "PWM" on that page
4) That page says there are 2 channels of PWM supported with the built-in libraries

Alternatively:
1) Google "atmel Atmega644p datasheet"
2) Click the second link (the doc8011.pdf file) which should be this: www.atmel.com/images/doc8011.pdf (http://www.atmel.com/images/doc8011.pdf)
3) Note that there are three timers, each of which has two comparators, so a max of 6 channels of PWM -- but you may need the timers for timing other things (like milliseconds and microseconds.)

And, finally:
1) Also note that the Arduino hobby servo library (if this is what you'll use the PWM for) actually uses a single 16-bit timer to run all the servos, programming interrupts for the high/low transitions, one at a time, at about a 30 ms loop time. That gives you a max of about 16 hobby servos within the 30-millisecond window. I imagine you could do a similar thing on the arbotiX.

Thank you. I did the first one and knew of the Arduino having 6 PWM pins. So I was assuming the arbotiX could also due 6 PWM channels.

SteamAutomaton
10-07-2012, 07:04 PM
Depends on the library used and how many other things are in use.

The hservo (or hardware servo) library that ships with the ArbotiX library is based on older versions of the servo library, uses timer1 to generate 2 fully-hardware based servo channels (which come out on headers labeled Servo A and Servo B). While this only gives 2 channels, the servo will basically never glitch because the servo pulses are generated entirely by hardware timers.

The servo library that ships directly with Arduino IDE, but will work on the ArbotiX, can do several more channels. I believe they say 8 max, although it really depends on how much other stuff is going on because this library uses timer1 to trigger an interrupt, and then generates the pulses inside that interrupt -- thus, if the interrupt is delayed because something else is in an interrupt handler, the servos will start to "glitch" as the pulses will be changing in length.

-Fergs

Thank you. I was interested in the practical limit of the arbotiX. Now to have my income to become overflowing so I can get one to play with.

SteamAutomaton
12-01-2012, 11:16 PM
I now have an arbotiX! :D

I now have a brain and need to start learning to use it. :p

jwatte
12-02-2012, 01:02 AM
FWIW, what I do to control PWM servos on an Arduino, is to disable interrupts, then generate the PWMs all in parallel. Because no signal is greater than 2.5 milliseconds, and I do this every 20 milliseconds, no more than 13% of the CPU power goes to this. If you also need to serve incoming bytes from the UART, this may be a problem (unless you use hardware flow control,) but I use USB (Atmega32u4) which is hardware buffered up to 64 bytes / one full packet. With interrupts disabled, your C code is just as good as "real hardware" in generating glitch-free signals :-)