Servo Array + BT PS3 Controller Feasability

Hi everyone,
I'm not new to robotics but I am new to Arduinos (I have an UNO). All my experience has to do with mechanical design, so this aspect of robotics is not new to me. However, this is my first direct foray into microcontrollers and so my understanding of the HW+SW limitations of the Arduino is minimal.

What I'd like to do is control an array of six arms (each with 4-DOF) for a total of 24 servos. I would want this controllable via BT with a PS3 controller for manual operations (but will be automated for some portion of the process). Each arm will need to support a load of up to ~4 lbf.

Here is my example configuration:

Is there anything theoretically wrong with a setup like this? Can this setup be improved in either performance or cost, by your experience? Can the UNO hardware handle both a USB host and a 24-servo controller simultaneously (I simply do not know the interface here - how do both subsystems communicate with the Arduino and is there any conflict)? Am I missing anything else crucially?

I welcome any dialogue about this as this is my first full project with an Arduino besides a couple dozen tutorial projects.

Thanks!

Your big problem is one that you haven't acknowledged yet. The power supply. And getting the decoupling correct for that many motors.

I don't understand your desire to use a PS3 controller when there are plenty of controllers which are much easier to use with the Arduino. I suggest making sure those BT dongles will work with with the USB host shield.

I haven't used those servos myself. I used 18 of these in one of my hexapods. I think they work well.

I agree, powering that many servos is going to be a challenge.

I also think supporting a load of four pounds will be a huge challenge. The servos you selected would have a hard time with that sort of load if the arm is longer than an inch.

I strongly suggest you start with one arm before purchasing parts for all six.

Mike,
Can you elaborate on this? I've seen examples of ~20 servos powered externally through the servo controller (like this one). Is this an obstacle in the example setup?

Not all 24 servos will need to run simultaneously. At any given time there will be up to 9 servos actuating. I would think a battery such as this one could handle short periods of use, and a tethered power supply could be used when needed. Perhaps I am wrong.

--

Duane,
What was your power solution for your hexapod design? And do you have any examples of simpler controllers via BT? Regardless of this, wouldn't I still need to use a USB Host Shield to implement any controller?

Did you control you hexapod via BT? What HW did you use to achieve this?

--

My main concern at the moment is understanding if there are any conflicts with the various required hardware: Arduino > Servo Controller & USB Host. I've looked through the documentation for both and my inexperience with microcontrollers has me unsure.

Circuits@Home USB Host Shield, from here
"Digital I/O pins 8-13. In this group, the shield in its default configuration uses pins 9 and 10 for INT and SS interface signals. However, standard-sized Arduino boards, such as Duemilanove and UNO have SPI signals routed to pins 11-13 in addition to ICSP connector, therefore shields using pins 11-13 combined with standard-sized Arduinos will interfere with SPI. INT and SS signals can be re-assigned to other pins (see below); SPI signals can not."

Pololu Mini Maestro Servo Controller from here
"The minimal connections required for using this library are:

Arduino TX pin (see table below) - Maestro RX
Arduino GND - Maestro GND

(from table):
Controller: Arduino Uno
Hardware Serial: No (what does this mean for me?)
MCU RX Pin: 10
MCU TX Pin: 11"

Does this imply that there is a conflict at pins 10 & 11?

Exogenesis42:
Duane,
What was your power solution for your hexapod design?

I had read many horror stories from people trying to build a hexapod about voltage regulator burning out. In hopes of not having power supply issues myself, I decided to use a 2S 5Ah LiPo pack and two 15A regulators.

I've listed a bill of materials (BOM) on the project page at RobotRebels.org.

Exogenesis42:
And do you have any examples of simpler controllers via BT?

I think the main advantage of Bluetooth is the ability to use a smartphone or a tablet as a controller.

Whenever I've used Bluetooth with a microcontroller, I've always used Bluetooth in conjunction with an Android smartphone. (I made some painfully boring videos relating some of my thoughts concerning App Inventor 2 (AI2).) There's nice (free) app made by forum member, kas, which makes a nice robot controller.

There are plenty of non-Bluetooth controllers one can use with an Arduino.

You can either use a wireless version of these controllers or the wired version. I used a wireless Nunchuck to control my hexapod. I posted some demo code for the Wii Nunchuck here. Playstation 2 controllers is another controller which is relatively easy to use with an Arduino. There are lots of wireless PS2 options (though many clones are junk).

Another option is to use the wired version of these game controllers and (if a wireless connection is desired) and use a second Arduino to read from the controller and send the appropriate data to the other Arduino. This option lets you add additional features to the control unit.

I used nRF24L01+ transceivers in the above example. XBees are another common wireless option for these sorts of projects.

Besides the Wii Nunchuck and PlayStation 2 controllers there are other game controllers which can be used with an Arduino without the need of an USB shield. The GameCube controller is one I haven't mentioned yet which don't require any special hardware to use with an Arduino.

Of course you don't have to use a game controller at all. An Arduino can easily read inputs from joysticks, buttons and potentiometers so you could make a controller to match your specific needs.

Here's an example of a joystick you could use in a custom controller which wouldn't be available on a game controller.

The knob on this joystick can twist allowing an extra degree of control from a single stick (these sorts of joysticks used to be used with RC helicopters). Posted a bit more information about this joystick in this post. The post, to which I just linked, also contains links to videos showing some of my joystick/servo code in action (using the above joystick). While I'm mentioning joysticks, I'll also mention this one.

Besides being able to use the input devices you want, a custom controller also makes it easy to add a display.

Exogenesis42:
Regardless of this, wouldn't I still need to use a USB Host Shield to implement any controller?

As I mentioned, there are lots of options which don't require a USB host shield.

Exogenesis42:
My main concern at the moment is understanding if there are any conflicts with the various required hardware: Arduino > Servo Controller & USB Host. I've looked through the documentation for both and my inexperience with microcontrollers has me unsure.

Does this imply that there is a conflict at pins 10 & 11?

The Mini Maestro 24 isn't a shield. The only conflicts I could see is possibly the serial pin #0 and #1 (if they're used). I doubt that would be an issue. From my very brief look the product page, I think the Mini Maestro 24 uses the Arduino's I2C lines. The I2C lines are intended to be shared so I doubt this would be a conflict. Nope, it uses a serial.

You might not need the Mini Maestro 24 at all. I think a Mega can control 24 servos without the need of a separate servo control board. Personally, I'm not a fan of servo control boards. I think you're better off using a microcontroller capable of controlling the servos directly.

Edit: Sorry, I forgot to go into more detail about the battery options. There's a big advantage to using battery packs which don't require a regulator. Using a 2S LiPo pack and step down regulators may not be your best power supply option.

Arduino > Servo Controller & USB Host. I've looked through the documentation for both and my inexperience with microcontrollers has me unsure.

Well, you have picked components without really knowing how to interface them for your project. How do you plan to control four robotic arms with a PS3 controller? If you expect the arms made from the servos to support a weight of four pounds at any distance, that probably won't happen. 24 servos can be powered using a sufficient number of UBEC voltage regulators from an appropriate power source. Worse case you could use an automotive 12v battery and the UBECs if the servos are under large loads. I'm not familiar with the Pololu servo controller, but I've used others like the SSC-32 and they take a lot of the processing load and complexity off of the arduino. I suggest you use google and youtube to find an arm like you want to make and post up the link. You could get the arduino, four servos, and a power supply, and make a prototype arm first just to verify your arm concept will work before spending more $$$.

Thanks Duane, that's a lot of information to take in. One of the big takeaways for me here is that Mega can potentially control the array on its own. What I've read (and what the latest poster said) is that for more than a few servos a dedicated servo controller is preferred. Would the Mega be able to handle this load all on its own? What is the primary tradeoff for doing so?

Exogenesis42:
Thanks Duane, that's a lot of information to take in. One of the big takeaways for me here is that Mega can potentially control the array on its own. What I've read (and what the latest poster said) is that for more than a few servos a dedicated servo controller is preferred.

I haven't used more than a few servos in my Arduino projects. I was under the impression an external servo controller wasn't needed even when lots of servos were used because this hexapod uses a single ATmega1284 and my friend has a hexapod without an external servo controller. He used a power distribution board but the Arduino controlled all the servos directly.

I think my aversion to external servo controllers comes from wanting to dictate the position of each servo every 20ms.

Even with a simple joystick servo program, I'm not sure how an external servo controller would help. Since I'm updating the servo's position at 50Hz based on the joystick's position, I don't see an advantage of sending the servo's position to the servo controller at 50Hz over just setting the position with the Arduino at 50Hz. It's very possible I'm missing some subtlety of servo control on the Arduino.

I think my aversion to external servo controllers comes from wanting to dictate the position of each servo every 20ms.

What kind of servo controller was that? 8) Most servo controllers now accept simple position/speed/timed movement commands and similar and do it all without further input until something different is received. below is the user's manual for the ssc-32 servo controller, which is at least 10 years old (somewhat dated now).

zoomkat:
Most servo controllers now accept simple position/speed/timed movement commands and similar and do it all without further input until something different is received.

I generally don't want servos moving at constant speed. In the joystick/pan & tilt example, the program accelerates the servo up to speed and decelerates the servo to a stop. The target stopping point is constantly changing as the joystick is moved. So even if the servo controller could handle the acceleration and deceleration (which I don't think it can) the parameters of target position and target speed are constantly changing.

Besides the joystick/servo videos I have a couple other servo videos which demonstrate motion I don't think servo controllers could duplicate.

This is a simple demo showing a normal servo sweep with the position incrementing in a linear manner (servo on the left) vs a sinusoidal motion (servo on the right). I believe only the linear motion could be produced using an external servo controller.

This video is similar to the one I just mentioned, but on a larger scale. By controlling the position of each servo at 50Hz I think more complex motions are possible than simply commanding servos to move at a set speed.

In an attempt to write a better control algorithm for my hexapod, I studied code from other hexapod projects. I was surprised to find other hexapod code calculated foot positions for the start of a step and the end of a step and used a simple linear motion of the servos between these two positions. IMO, a hexapod produces a smoother motion if the foot's xyz coordinates are calculated in a linear manner but the IK position of the servos should be calculated at a full 50Hz in order to insure the foot's position follows a linear path. If the servo positions are moved in a linear motion, the path of the foot ends up sliding a bit as the step progresses.

I've had multiple people, who have built hexapods of their own, comment on how well they thought my hexapod moved. Again, this sort of motion wouldn't be possible with an external servo controller.

I'm sure there are plenty of applications where a constant velocity servo performs the desired task just fine. I just find I usually want a more complex motion than an external servo controller can provide.

What makes the Parallax board better suited for this than a Mega? And in comparing the two hexapods (yours and your friend's), is there anything either setup can do that the other cannot? Is the jitteriness of your friend's hexapod due to not including voltage regulators?

I am reading through your hexpod build process. You made two custom boards (perf board and your "Ten Servos" boards. Were these simply to route the signal lines from the controller and power lines to one board (well, two) for ease of assembly or is there more to this step? And each regulator routed to each of the two servo boards?

Edit: Also, if I so desired, could I use a PS3 controller (as an example, I understand I could use a different controller method) + Arduino Uno for a control scheme, and use the transceivers mentioned earlier (nRF24L01Z+) to communicate with a Parallax board? This interests me as I would be able to add a number of interesting features I didn't think of before.

Exogenesis42:
What makes the Parallax board better suited for this than a Mega?

I don't think I said one board was better suited for controlling servos than another?

Exogenesis42:
And in comparing the two hexapods (yours and your friend's), is there anything either setup can do that the other cannot?

There are certainly differences with hardware which allows one hexapod to do things the other couldn't but I don't have enough experience with both controllers to directly compare the two. I'm much more familiar with the controller I used than any of the Arduinos (I program sensor firmware using the other controller as my day job).

Exogenesis42:
Edit: Also, if I so desired, could I use a PS3 controller (as an example, I understand I could use a different controller method) + Arduino Uno for a control scheme, and use the transceivers mentioned earlier (nRF24L01Z+) to communicate with a Parallax board? This interests me as I would be able to add a number of interesting features I didn't think of before.

I personally think this is a very promising approach. Each of the controllers have their individual strengths. Parallax used to sell a servo control board which would act as a slave to other microcontrollers. I've helped people who wanted to make a Mecanum wheeled robot controlled by an Arduino use a Parallax board as a slave device to an Uno. They used the program I wrote for my Mecanum wheeled robot loaded in the slave board. They had the Uno send direction commands over a serial link to the slave board. The slave board took care of monitoring the four quadrature encoders and controlling the speed of the motors. The Uno took care of the high level logic concerning which course to take and the slave board did the resource intense motor control tasks.

I forgot to answer your questions about the servo connections.

Exogenesis42:
I am reading through your hexpod build process. You made two custom boards (perf board and your "Ten Servos" boards. Were these simply to route the signal lines from the controller and power lines to one board (well, two) for ease of assembly or is there more to this step? And each regulator routed to each of the two servo boards?

The two "Ten Servos" boards were to make it easier to route power to the servos. I had these made at OSHPark.

Here's a link to the .zip file I submitted to OSHPark.com.

The servo connectors are arranged in groups of five. Separate power sources can be used on each group To power all ten servos from one source, you need to use a jumper to combine the two power rails into one.

That's what I figured, but just wasn't sure.

Just a few more questions, I hope you don't mind. You're a great help!

With your hexapod setup, what battery life were you seeing? How well did your servos work and how much current did each draw during actuation? Is there anything you would have done differently in that area?

How would you describe the Parallax community? I've been very impressed by the help on offer in the Arduino community and if I proceed down this path (Arduino+Parallax) I anticipate needing occasional guidance, especially early on.

The more I read about this, the more I feel inclined to perhaps start with a hexapod as it seems to have significant documentation in the community, and is somewhat more straightforward than my my project goal (the scope of which is perhaps too ambitious for a first project).

Exogenesis42:
With your hexapod setup, what battery life were you seeing?

I generally don't worry about battery life (on this particular robot). I have a 2S 5Ah LiPo pack and it has always lasted as long as I've needed it. I generally don't run the robot for more than 15 minutes at a time and the 5Ah pack can easily last that long. If I were to take a wild guess, I'd say the battery pack would last an hour is the robot were very active. Under normal use with the robot walking a bit and the stopping to "look around" (it presently doesn't have any sensors), I think the battery would likely last a few hours.

I always use a LiPo meter/alarm with my battery packs so if a cell starts to get too low, the alarm will warn me before the battery gets damaged.

I purchased several 2S 2.2Ah packs I plan to use with the hexapod. I think 2.2Ah is enough for occasions when I want to use the robot, and the smaller pack will be easier fit inside the frame.

Exogenesis42:
How well did your servos work and how much current did each draw during actuation? Is there anything you would have done differently in that area?

I haven't measured the current draw. While each servo is capable of drawing over an amp of current, I don't think (on average) the whole robot draws much more than the a few (3?) amps in most situations. While the average current demand isn't extremely high, servos draw current in huge spikes. The big regulators and large battery supply are required to deal with these current surges.

I've only measured the current with the robot powered from my bench supply. While on the bench the robot is supported on a box. I could be way off on my estimate about how much current the robot draws. I should measure the current under load. I have the gadgets to measure the current, I just haven't taken the time to make these measurements.

The main thing I'd perhaps do differently would be to research the voltage regulator options in more detail. I'm not thrilled with the two giant regulators I'm using. There are likely more compact solutions. The regulators I'm using work fine so I don't feel much pressure to find an alternate solution.

One thing worth mentioning is the possibility of using servos capable to connecting to a 2S LiPo pack. I was told the servos I used should be safe when used with a 2S LiPo and the servos didn't burn out when powered this way but the servos jittered severely at the higher voltage. I've had a few small servos emit their smoke when powered from a 2S LiPo. I think the only servos I have which work okay on a 2S LiPo are the CR high speed servos I purchased from Parallax.

If you can use servos capable of being powered from a 2S LiPo, you'll save yourself a lot of trouble having to deal with voltage regulators.

Exogenesis42:
How would you describe the Parallax community?

Extremely friendly and helpful.

Exogenesis42:
The more I read about this, the more I feel inclined to perhaps start with a hexapod as it seems to have significant documentation in the community, and is somewhat more straightforward than my my project goal (the scope of which is perhaps too ambitious for a first project).

I guess I don't understand what you wanted to accomplish with your original plan. IMO a robot arm is a bit easier to manage than a hexapod. I don't know how you planned to use the six arms but a robot arm is (generally) stationary so you don't need to carry around your power supply. Power supply issues are a big challenge when dealing with lots of servos.

One aspect of a robot arm project which is harder than most people realize is how much torque is required to support an arm of any significant length. I have one of Crustcrawler's "Smartarms" which uses a bunch of Dynamixel AX-12+ servos. If I'm careful with how I manipulate the arm, I can sometimes manage to pick up a soda can. I can't do this consistently but if the can isn't too far out of alignment with the arm's claw, I can get the arm to pick up the can. The can needs to be EMPTY to do this. A full can of soda would be much too heavy for this sort of arm. I should add I used the original claw. A claw with a different shape would likely have an easier time lifting a can but I'd be surprised if the arm could pick up and pour a full can of soda.

A robot arm capable of doing real work would likely be expensive to build. You'd need more than just hobby servos to power it.

I'm not sure what you mean by "significant documentation" when it comes to hexapods. I've documented the mechanical aspect of my hexapod pretty well but I haven't posted the code for my hexapod. I'm pretty sure there is Arduino hexapod code available but I don't know where it is.

I was just looking at the Stubby code on GitHub and don't see any indication it uses the Arduino bootloader.

I believe Bajdi published his code (I'm not sure about this) but it had likely been published on Let's Make Robots which has since been purchased by the (IMO) evil corporation. Badji didn't accept the new terms of service (aka selling one's soul to the devil) so all his posts were deleted from the site (all my posts were also deleted). So I don't know where Badji's hexapod code is. I'm sure there are other sources for hexapod code but I'm not sure if I'd call this "significant documentation" (though I'm not saying it's wrong to do so).

I think the Stubby code would likely be a good place to start if you wanted to make an AVR based hexapod.

While I think I did a good job programming my hexapod (I wrote the code myself), I think Stubby out performs my hexapod in several respects. I haven't added the ability to have my hexapod tilt and twist the way Stubby can.

TL;DR - A hexapod is a good robot project but it's far from easy.

My end goal with my original idea is to prototype an object manipulation concept I've had for some time. There would be a high degree of automation to it by use of sensors/feedback, with manual inputs as necessary, and this system as a whole would be mobile (piggybacking another mobile system) - hence the wireless need.

Frankly, my education and experience is in mechanical engineering, not in computer science & programming, and I think my end goal could use a few stops along the way.

What I mean by "documentation" is that there seems to be a good bit of community resources and experience documented for hexapod logic, so it appears to be a good stepping stone since my end goal is essentially an inverted hexapod with a whole slew of other features that I don't yet know how to implement SW-wise.