I posted this photo a few days ago for people to try and guess what I was working on. Alas, nobody got it right.

Short answer: It’s a Dual Receiver Board.

We’ve had issues at some events where our 2.4GHz Spread Spectrum radios cause problems like interfering with WiFi setups, and we’ve been asked to limit where who go. Luckily, on my Futaba 10C I can quickly switch out it’s transmitter module to either be 2.4GHz FASST or old school 72MHz FM. So I devised this little board to allow me to have two receivers (FM and FASST) connect to Artoo at once, and flip between them with a flick of a switch.

I’ve had this idea for a while, but only now getting around to implementing it because Maker Faire is in a few weeks, and I know we’re going to have interference problems and I didn’t want to limit myself to either FM or 2.4GHz – or have to make a fiddly change in the field.

Receivers connect on the left and the real servos and speed controllers connect on the right along with receiver power. Ignore the black/red/white wire color on the cables coming out of the receivers. I’m only connecting to the signal out on pin 1 for each channel, and the only nice wire I had handy was standard servo cable. The last pair in the row adds power/ground and are tied to the select switch.

I’m also tinkering with some other droid controllers and this will allow me to have them connect without disrupting too many things, but more on that later.

Spent the last few days playing with the new Futaba 10C transmitter.

I had to re-calibrate the joysticks with the RoboteQ AX3500, and took the opportunity to review my speed controller setup, and tweak some of the parameters. After I was done looked like something like this –

Control Input: RC
Motor Control Mode: A and B Mixed
Input Adjustment: Logarithmic Strong
Amps Limit: 60
Acceleration: 682 (milliseconds)

I changed the Input Adjustment to Logarithmic (from Exponential) and decreased the Acceleration Delay to 682 ms. This controls how fast Artoo reaches his maximum speed and time to stop. I found that anything lower made him too jerky as he tries to stop on a dime. Both these parameters will make Artoo a little bit more responsive.

On the Futaba I increased the end points on each of the servo channels to 140%, but I suspect I could have left them at 100% due to the joystick calibration on the RoboteQ.

I also had had to reverse the direction on some of the channels.

I’ve managed to get the signal Fail Safe to work on the Futaba. Many of the older Futaba can’t do this, or at least not on all channels. For example, I know the 7 ch 2.4Ghz receiver can only do it on channel 3/Throttle. Which makes sense for airplanes, but not very good for robotic applications.

The default setting on the 10C is “Nor” which will set the receiver to continue to send the last good signal received out to the servo, or in my case the speed controller. This would cause the droid not to stop if I ever lost power on the transmitter or it’s link to the receiver in the droid.

Hoping that I’ll never need to use it, but at least it’s setup now.

As a side note, I’d almost went with an RC setup from Spektrum which offer a separate receiver (BR6000) specifically design for robotics, but it’s only 6 channels and I’m not crazy about the Spektrum transmitter setup, and really liked the extra knobs and sliders on the Futaba 10C.

I’ve also discovered that the extra FM antenna on the 10C is easily removed, and has zero effect in the transmitters operation. I was suprised to even see it installed when I got the unit. I’ll need to make a plug to fill the hole.

WonderCon was last weekend, and it was my first real test of Artoo since the rebuild. I’d mentioned that both Gerard and I had problems with our batteries. We’d figured it much be the carpet, but I hadn’t had the problem at Celebration 4 – and in the back of my mine I had a niggling theory what was causing it.

For Celebration 4 I’d used 3 7Ah 12V batteries, two dedicated to powering the NPC-2212 drive motors, and one for the body electronics like the sound system, dome drive and speed controllers. But during the rebuild before WonderCon I’d decided to consolidate all 3 batteries into one block to make charging easier. I’d had issues with power before, but thought the problem was resolved and I could consolidate my battery sub-system. Runtime at WonderCon was approx. 60 minutes vs 180+ minutes at C4 – which is a huge difference.

Unfortunately, while I was redesigning my electronics and adding the charging system, I’d forgotten that the RoboteQ speed controller really likes a solid 12V supply, so last weekend as my batteries ran down and when the NPC motors first start-up they were eventually pulling the supply well below the minimum 10.5V required by the controller. It’s “intelligent” and shuts down if it thinks it doesn’t have enough power to control the MOSFET drivers. It’s only for an instant, and starts back up almost immediately as power is cut to the motors – which resulted in the very slow and slightly jerky movement.

So today to prove my theory, I reinstalled the the “dead” batteries from last week without recharging them, and added a separate 12V battery to the Power Control lines on the RoboteQ – Bingo! Worked first time. The issue was totally gone.

I’m kinda embarrassed that I went through this, because I should have remember that there’s a know “design feature” with low batteries and high current draw on this type of speed controller.

I’m now confident that I can pretty much run Artoo for multiple hours on a single charge – but I will have to reconfigure my electronics system again – making it harder to charge batteries in place.

Related Posts:

• WonderCon 2008 Show Report
• Updated Charging System Circuit
• RoboteQ 3500 code 8 fixed
• Artoo’s First Steps

Not a whole lot going on. I did find a very cool surplus electronics store this week in Santa Clara called HSC. They carry a LOT of stuff at a fraction of the cost and the place is full of things that can be used on R2. I was hoping to find a slip ring to experiment with but I was out of luck. I did pick up a few bits though, including some red rectangular LEDs for the front slot on the periscope.

I did a quick test fitting on my aluminum periscope housing and they fit perfectly.

There’s very little published reference material for the periscope, but I have it on good authority that the front red light was made up of 6 of these LEDs.

I also worked a bit on my RoboteQ speed controller, adding a RS232 connection to the provided PWM cable to allow me to monitor things live from a tethered laptop. Basically I ran two wires (RxD/GND) from the 25-pin plug they provide to a 9-pin RS232 plug/housing.

The plug you see on the right may look like an RS232 connector, but it’s really used to connect just two PWM wires from the Vex receiver into the RoboteQ. It comes as standard with the controller, and they also provide a seperate RS232 cable to connect your computer. I really don’t understand why they don’t just provide one combine cable. Confused? Please see the RoboteQ manuals 🙂

Once the controller is connect to my computer I can use they’re monitoring software called roborun. It polls the speed controller and graphs live data like battery voltage, controller temperature, current being used, PWM data etc. It also allows me to exercise the motors without using my RC transmitter.

I’m back from C4 and R2 performed really well.

I was able to finish the basic structure, the dome, the electronics and he was fully RC’d and running around most all of the days at the con. As you can see I also fixed the dome and got most of the blue painting done. Battery life was excellent and the Roboteq AX3500 speed controller / NPC-2212 combo worked out great. I was in both races and the little guy far exceeded my expectations of what I thought I’d be able to do at C4.

This is me driving back to the hotel on the last evening ready for transport back to the Bay Area – Yes I drove him home 1/2 mile to the hotel without incident.

I still need to sort through my photos and upload them and post a full write-up, but wanted to post something other than having my dented dome as the top post in the blog 🙂

I also intend on going back and catch up with blog posts on all the building I did before I left.

Drive system jerkiness is all fixed. The problem was the AX3500 and not a Vex compatibility issue. The board had a dry joint on the main power control tab which was causing a short. The speed controller thought the battery was low which cause the fail safes to kick in and turn everything off to avoid damaging the Mosfetts.

I’d gone back and forth on the phone with RoboteQ for a few days, and finally they just overnighted me a new board which fixed the problem instantly. While I was removing the cables to send the old board back the tab connector popped off the board totally.

In the process of troubleshooting the problem, they also convinced me to reconfigure my batteries to have a dedicated 12V supply to the board rather than using a single shared 12V supply for everything. They explained that the symptoms I was seeing were very similar to a low battery problem due to the motors drawing too much current.

I’m probably going to keep the batteries separate for now, but will have to rethink the wiring and my fuse block as I was hoping to just get away with one battery feed which also made charging easier.

The real worrisome thing is he’s way too fast and really dangerous. He can zip around at lightning speeds and can plow through most obstacles because of his weight. I may need to have a fast/slow switch.

He’s also shacking himself to pieces and has already dropped several screws.

I received my center foot on Friday and it was the last structural part that I needed to get R2 on all 3 feet. So, my goal for Saturday was to get him running around under his own steam by the end of the day. I still needed to wire in the RoboteQ AX3500 speed controller which controls the drive system.

I added a power strip to the inside of the back mounting plate to connect all the grounds to and set about wiring things up.

I then did some basic tests of the 3500 and noticed something strange. The motor would run for a second then stop for a split second then start again, like it had a slight tremor. Message code on the 3500 status panel flickered from motor direction information to an ‘8’ – which means under or over voltage. I suspect it’s a low battery. I hope it’s not a Vex/RoboteQ incompatibility problem. I suspect I may need to add a second battery dedicated to just controlling the 3500.

I then worked on trying to get the center foot assembled and attached to the frame. But there was a problem, I was missing the pack of hardware. A quick trip to Ace fixed it, but I couldn’t get the exact parts and had to improvise on the standoffs.

Like the outer legs and feet the new foot was a snug and it took some cajoling to get the pivot point to fit.

Now that the center foot/leg was attached I was excited to think I was close to getting him mobile.

However I really shouldn’t have rushed as much as I did. What followed was a bunch of silly mistakes which cost me a lot of time. Luckily no harm was done and I learned a lot in the process.

Even in my haste to get the legs on and the motors hooked up, I’d remembered that I needed to lock the legs somehow. I’m not going to be using the satellite motors to do 2-3-2 at this points, and one of they’re jobs in the design was to lock/hold the legs in place. So I knew I needed to figure something out, but I thought it wouldn’t hurt to skip this step just for now. Boy was I wrong!

At the same time I also had the drive wheels in the back of the feet, and they weren’t always touching the floor. I’d also forgotten to reverse the drive wires on one motor.

As you can imagine his first steps were not pretty to say the least and he jerked around because of the RoboteQ battery problem, and his legs went in opposite directions. It was a total shambles. Luckily I didn’t have the camera handy for a photo.

I also needed to tension the drive belts more which meant that I had to partially disassemble the feet again. I’m beginning to realize it’s a major pain to unscrew so many bits just to fix one thing.

After stripping him back down and fixing the problems and locking his legs back in 3 legged mode I gave him another spin and here he is. He’s super fast, but I really do need to figure out the battery/undervoltage problem that makes him stop/start/jerk.

Once I get the RoboteQ speed controller working correctly this thing is going to scream.

Another big step forward tonight and I’m not really sure where to start or if I can remember everything I did.

Maybe it’s easier to say where I’m at – I now have a lot of the electronics installed in the body, from fuse block and power distribution to the speed controllers and sound system. I can now control the dome and periscope from my Vex transmitter and trigger sounds with my RF remote.

There was a lot of stripping of wires, routing them, testing, and moving stuff around to make it all fit on the back panels. I also installed a second Vex in the dome to control the periscope, and eventually it’ll control some servos on the pie-panels.

From the photo it really doesn’t look like a lot but there’s a lot packed in there

I’m now realizing that it may not be a good idea to run R2 around naked / skin-less at C4. I could easily see someone pulling on the wires and frying something.

Here’s a quick demo video as well.

You’ll notice in the video that the periscope doesn’t run up and down smoothly and it chatters. Some of it is due to the speed the motors run at which I can limit in the Vex, but there’s also a lot of play in the lift mech screw system itself which I need to fix somehow.

I still need to wire in the RoboteQ speed controller which will drive the feet, but you can see it at the bottom of the frame.

One problem I noticed again is that the Vex in the dome has problems receiving a signal. This maybe a big show stopper unless I can route the antenna somewhere else.

The 12 channel RF Remote also has a “problem”. The new models have a little speaker/siren on them which makes this awful bleep every time you press a button on the remote – I’m sure for most applications this is fine, but for R2 it’s got to go. You’d think it could be disabled easily, but I can’t find anything. I’m going to have to fix it before it drives me nuts.