Project: Melissa Hands - Perhaps a little easier..

[PaulL]

I love it when a plan comes together...

I've made more progress. The controller board is built, the power board is built. I've already made modifications to the next revision based on building these two boards, some things that I needed, some things that will make it easier to build.

As a first set of boards, I've managed to turn this into what is, so far, a working prototype. I've done some testing on the power board and the control board. Only audio amp, optocoupler, PMBus to the DC to DC converters, and laser driver / laser actuator driver testing remain. I'm confident in all but the PMBus testing - for that to be successful depends on a few things - we'll see. I had a few changes to make, not too bad: added forgotten pull up resistors to the PCA9685 I2C Bus, changed resistors on the MPU-9150 / DC to DC Converter I2C Bus, swapped out the oscillator capacitors in troubleshooting the fact that analog voltage input is required to run the STM32 (THAT was frustrating to realize!).

I did manage to fry the first STM32, as it is quite clear that if you accidentally plug pullups into a 5v bus on a breadboard, you will render the chip non-functional (didn't have low enough resistors on the MPU9150 / PMBus I2C, wired out to a breadboard to fiddle). I "borrowed" an STM32 from a Maple Mini, as it's bootloader is already flashed and I didn't want to fuss with trying to tack a wire to a pin again. I'll probably put another STM32 back in the Maple Mini I robbed the chip from at some point. I have 4 Maple Mini's lying around, and I'm sure I can find projects for all of them at some point in the future - no sense leaving one board processor-less. I'll order an extra STM32 next time I place a Digikey order.

These boards were relatively problem free to build, easy to get working, very few solder bridges easily fixed. The correct resistor packs have arrived and are installed - only one bridge with manually applied paste across 5 tiny resistor packs, not too bad. A little flux pen and an iron, and done. I had 2 or 3 bridges on the STM32, fixed with flux pen and iron.

I had an oversight - I didn't connect Boot1 to anything, as I figured it wasn't needed - WRONG! It needed to be tied to ground to flash the Maple Mini boot loader. Magnet wire and cautious effort was needed to bridge off the pin to ground. I've added a solder bridge for the next board rev.

I used magnet wire to add the missing I2C pullup resistors as well.

I think one more rev will make these boards just about right, but with the tweaks, they're good enough to test and develop with.

Initially, I ordered two sets of components, thinking I'd fry enough to justify a second set on another of the 3 boards sent - other than the accidentally blown STM32, I have no other component failures, so these parts will be saved for boards V2.

One more note about construction - via-in-pad is problematic, no matter what you do. Though what I have is working, I don't know if it'll handle the current. I'll give it some thought and try something different on the DC to DC converters on the next board rev (at the least, move vias out of the pads - there's room). I may go for a larger single via in the power pads, as there's a lot of current to be running in and out of these - a via large enough to easily flow a good amount of solder - the holes I have are what was recommended in the datasheet, but they're not big enough to feasibly get solder into once the component is mounted.

Testing!

All testing was done via Remote Desktop into the Z530 board. Two USB ports are on the control board, wired to the Z530 (white connectors bottom right on the blue Z530 board in the pics). One is the typical Maple Mini USB connection (for programming), the other is a CP2103 USB to UART bridge for higher speed / less CPU load.

The power board voltages are all good, the MAX1614 works as expected - a high current switch driver / controller that can keep the LiPo's safe from over-discharge and notify the STM32 that shutdown is needed (which can then power down non-critical functions, and ultimately the Z530).

The CP2103 was flawless from the start, no issues with this chip at all. I thought it would have a problem, as the stencil left the pads with very little paste - but it was fine. I'm capable of running 921600 bps through it to and from the STM32 - a nice hardware pipe for commands and responses. I've read that SerialUSB is software-based and won't go that fast, no reason to tie up the CPU doing needless things. Also handy was that by chance, I have the CP2013 tied to USART1 on the STM32, which is needed for bootloading, so that was convenient.

The PCA9685's are talking at 400 kHz, I'll do some motion on a servo or two soon.

The MPU9150 is talking over I2C at 400 khz, I ran a sketch to verify, got to see data streaming out of the CP2103 over a 921600 bps connection via Hyperterminal on the Z530 board - temp, mag, gyro, accelerometer. Monitoring temp on the MPU9150 could be useful, for example, to diagnose fan problems.

There will be some hardware changes to the torso brackets, I will need to add / move some holes for wiring. Haven't worked out a bot-controlled charger plugin (easy alignment, easy insertion, sufficient current handling), I'll get to that eventually. Maybe have him stick his finger in a special socket, who knows.

Fit Testing!

These boards will be stacked. I still don't know how much interference the DC to DC converters may cause, some copper shielding between the power and control board may be needed. I don't anticipate any interference problems between the Z530 and the control board.

The fit around the fan and the speakers is spot on. The position of the boards cuts the fan air flow such that these two boards get some air, as does the Z530. This should work well.

I need to give some thought to board mounting. The holes left and right on the control board are a little off (I knew they would be, I wasn't expecting the first board rev to work as well as it did) - I could make it work as is, but I'll change it in the next rev.

Also need to give more thought to wire routing, there's going to be quite a bit going on - camera power, Laser power, Laser Actuator Power, Hand Servo Power, Z530 power, SATA cable (found a site that sells some right-angled combinations that should work) and SATA power, battery wires, Camera and BlinkM in the head, Microphone, USB, Speaker Wiring, Audio input wiring, Z530 board header connections, power switch, neck servos, etc. I'll use high flex silicone wiring where I can. I need to order some 24 or 26 gauge stuff, have some 30 something gauge, 20, 16, and 12 gauge in silicone. I might design up some wiring boards I can tuck here and there - $5 each for 3 copies (<1 sq in), can't beat that OSHPark price!!

I'll definitely do the same STM32's in the hands, I have a set of UART pins brought out to some connections to control them from the main board.

The pics!!

So, here are the boards as received - very nice:


Boards as built:


Boards stacked together:


And fit in the top frame of the torso (bear in mind, this "box" will house two standard servos and 3 micro servos - one micro servo will be above the power board on the right. LOTS of stuff packed in tight):







And a bit of a secret I'll let out, a 64GB SSD I'll mount to the chest (takes only 5v, so power will get wired to the same supply as the Z530 board). Yes, there are two, only one will be in the bot at one time:



He'll be 1 foot tall, 1.6 Ghz, 2gb 667Mhz DDR2, 64Gb SSD, 72 Mhz STM32 controller, mag / gyro / accelerometer, PMBus power control, QSI Speakers with enclosures driven by a Class D ~2W audio amp, Micro Camera, NTSC to USB Converter, Line Laser and Actuator for 3D imaging, 3 DOF neck, 5 DOF per hand, Wrist and Hip rotation, 33 servos, 1 magnetic actuator, plus whatever I'm forgetting at the moment. He's going to be quite a machine.

***

A quick note about SATA and SBC's: I checked out some details on Compulab's site (they make the FitPC2, etc), and what I found is that they use a "bridge" from SATA to IDE, meaning that even though SATA boasts of huge speed, you'd be limited to IDE ATA speeds even with the fastest drive you can find.

However, the Kontron board I'm using has a SATA controller strapped to the PCI bus, as it should be: faster.

Regardless, the SATA drive will beat the snot out of the MicroSD card I was planning on using. Maybe I can find another use for the MicroSD card - MP3's or whatever, personality / program configuration, something like that.

[PaulL]

... a month and a half gone by, no replies. Can't say I'm too surprised, though. An update anyway...

Testing continues. I ran into a problem trying to access the DC to DC converters via I2C - the LeafLabs LibMaple library had some shortcomings: didn't support repeat start, blocked for the whole I2C transaction, didn't support PEC byte. So, what did I do? Dove into C (not my strongest area of expertise) and rewrote the darned I2C stuff (the ISR mostly). I looked around the 'net, couldn't find anyone that managed to do what I was trying to do, let alone code for doing PMBus / SMBus on the STM32 (found some that was blocking, something I didn't want to do), so knowing that the chip was supposed to be capable of it, I re-wrote the ISR (and gained some more experience in C).

Now, I can read voltages and margin the voltage (testing lately has gone pretty well). I'm currently working on the I2C code to add queuing to I2C in order to keep data flowing over the 2 I2C busses on my board concurrently. The code I have is non-blocking, meaning I can do other stuff when the ISR isn't running (which is most of the duration of an I2C transaction), like process data from the host SBC, process data from the MPU-9150, etc, etc. It's much more efficient this way, better use of the processor than waiting for I2C to finish every time it is called.

I'm close to moving servos via the controller board, then I'll work on the PC interface protocol (I've already done some work in this area).

Bit by bit - literally, at times...

[xevel]

Hey Paul,

I'm in awe :O
That's a lot of work you've been doing, it looks marvelous!

I, for one, am very interested to know how things are progressing!

[PaulL]

Thanks, Xevel!! It's not often I get comments to this thread these days, very much appreciated!!! If you have any questions about what I'm doing (sometimes I'm one-track minded on a particular aspect and may not be clear), by all means, just ask.

It's been a long time in the works - hardware, software, and more recently, the electronics, and lately, firmware (controller software).

I'm still working out buffering, having some problems with pointers and arrays of pointers pointing to structures having arrays and such, it's my lack of knowledge in C that's causing me trouble. I'll get it eventually (I may have it now, need to test changes made yesterday).

Before I started on the buffering code (significant change to the libmaple ISR code), I managed to move a servo, and I was talking to all 3 DC to DC converters and the MPU-9150, all at 400khz (and I have about 8" of wire between the controller and the power board for testing) - SMBus / PMBus and regular I2C devices together. Yesterday, I tried a few new things, got the code to a point of compiling without error, so I'll test that a bit more today. Once I've got this nailed, I'll copy some of the code over to USART, I'll handle packets within the USART ISR (to / from host PC), much like I'm doing with I2C.

Meanwhile, a few other project-related bits:

* Got an old Tektronix scope off ebay, should arrive this week - it should be quite helpful in troubleshooting more complex problems I may encounter.

* I was working on a hard drive for a co-worker, and ended up loading WinXP on one of the SSD's on my desktop quad core box - from end of BIOS to desktop, 6 seconds, from shutdown to powered off, 4 seconds. FAST!!! So much so, I am tempted to slap a few into my desktop machine on a permanent basis. This was with the slower of the two SSD's, so the faster one on the bot should be incredible!

Of problems that may be possible, there could be problems with heat dissipation / power handling in the DC to DC converters. I shouldn't power test all up servo load until I have the torso put together so that the fan can do its job. I doubt the magnetometer mid-torso will be of any use, nestled between DC to DC converters, servos, and speakers, which is another reason that putting STM32's with MPU-9150's in the hands and feet would be of use. Still, the servo magnets will give the magnetometers some trouble. I may be able to calibrate magnetometers using a fixed position of servos (ex, standing still), and across a few of them, I might have some decent results. The main reason for MPU-9150's in hands and feet is bump detection, tilt detection, and gyro compensation.

More about the boards: Some of the components are so close together, I needed a magnifying glass to verify that there were no shorts - particularly in the audio section of the board. But, having built these with 0805 parts, I may try 0603 or 0402 on the next rev, that'd offer up more spacing between components. The most frustrating routing area was between the MPU-9150 and the STM32 - I2C and power both run between the two chips, and with the decoupling cap right there, it was very, very tight. I couldn't move the STM32 up, as the other I2C bus is over there. There's too much going on under the STM32 to route the I2C bus for the PCA9685's elsewhere. All power traces on the control board are 32 mils, aside from the power and ground lines for the servo headers - those are 50 mils, and I'll over-solder them for more current handling.

The PCA9685 chips I'm using for PWM will let me "stagger" pwm output pulses, so I'll be able to balance distribution of PWM such that I'm not getting all of them trying to start up at the exact same time (on the Roboard, this can draw so much power as to glitch the board using the standard HSR-8498HB servos).

I'm shooting for 4mS updates for all servos, which should be entirely do-able based on some time measurements I've done for I2C communication with the rewritten ISR.

I'll be doing some more coding today, hoping to get the buffering of I2C transactions off the to-do list.

In hindsight, I don't think I need the opto, but I do need to check voltages of the header pins on the Z530 board - by all standard methods, I should be able to wire right to them instead of using an optocoupler. Getting rid of that optocoupler offers up space to add a 4 input OR gate for Tx lines from hand / foot controllers.

I have realized I did make one mistake, adding the 3 neck servos to the PCA9685 on the left: the HSR-5498SG servos like 100hz updates, but I don't know if the MKS DS450's will like that, as I can't change the overall rate of PWM cycle in the PCA9685 per output pin. Instead, I should have tried to wire to PWM pins off the STM32 for the neck servos (I have some left). But, that's all tight, not sure if it's physically possible to do so. The real thing to do is to see if the DS450's are good at 100hz, then no problem.

Not sure how much I've talked about the audio section (bottom right on control board) - separate ground and power planes, and the audio amp has its own LDO regulator (HSOP8, bottom right on power board). On top of that, power and ground both get ferrite beads, and speaker outputs get ferrite and caps for longer wire runs to reduce EMI (Class D amp).

If I went 4 layer, I could fit more in, but I'd have to upgrade Eagle. 2 layers turned out pretty well so far!! Of course, if I get to selling, I'll upgrade Eagle - but so far, I don't think anything I'm doing / will do will be of use outside of my specific bot config.

The hand / foot boards will be pretty straightforward - I'll start with the controller design and hack off the unnecessary pieces, then change a few things around. I'm thinking it's a one or two day effort, I'll do that after I get the firmware more sorted out (this will also be very similar on these boards). I plan to basically do a packet forward for servo control to the STM32's running the fingers, this'll make for less work to do on the main controller. The foot controllers won't even do PWM, but I may set up inputs for FSR's in the feet.

I might have mentioned, but the MPU-9150's are supposed to have built in capability for tap detection, which will make for bump detection for hands and feet - a feature I've not seen on a small biped yet (bump detection based on gyro / acc). I have some docs on the MPU-9150 that should shed some light when I get to that point. Even if I can't make them do tap detection internally, I should be able to sort it out on the local STM32.

Paul

[ttuuz]

Hi i see you might have to upgrade to eagle 2 but before you send all those bucks go over to rs design spark and down load there free pcb board design program it is aslo linked to there stock of parts with scimatics for these parts find it at http://www.rs-online.com/designspark/el ... -home-page

Cheers Ry.

[ttuuz]

Hi this is the design i made on my resent pcb with design spark hope design spark will be ok for you.

Ray.

[xevel]

Well, if you really want a free CAD package that can handle more complex boards, maybe try KiCAD instead. But that's besides the point, the learning curve might not make it worth it depending on how you value your time. Personally, I recently got a Standard license of Eagle (I use it for work too) and I have to admit that 4 layers mad my life much easier.

I'll get back to actual comments about your project tomorrow, I haven't had time to read all the backlog of amazing posts in this thread, I have a board to finish ASAP!

[PaulL]

Ray,

It's an interesting option, but...

Xevel,

Well, you're right, I've spent too much time in Eagle. I started messing with Tango way back when, then I found Eagle, which I found to be similar - and better. I've been working with it for years (that is, at a hobby level - my day job is mainly focused on writing industrial automation software). It'd be a whole new adventure to switch to something completely different - one that'd make my long-running project even longer. It's worth the money versus the time it would take to become proficient in a different package.

And thanks, Xevel - I tend to write a lot - I type fast, so what begins as "just a quick post" can end up way too long more often than not.

And get that board done!

Paul

[patkangu]

Really nice work.

[PaulL]

Thanks, Pat!!

It's a long-running project with a bunch of different aspects - lots of features, quite a bit different from what I started with, a stock RN-1. I'm shooting for hardware completion before the end of this year, but I have a fairly demanding day job and life, as they say, sometimes gets in the way, so I do what I can when I can.

Today, I'll do some more debug for I2C transaction buffering (3 day weekend). The good news is, I received a used o-scope yesterday (ebay), it should help a lot in pinning down any problems I may run into.

Paul

[PaulL]

Still working on firmware, but decided to take a break from that to start on a hand controller design. For those that have been paying attention, at first, I considered one of two possible Pololu controllers, but these only do but so much.

Main Parts:
STM32F103CBT6 (Processor, connected to controller over UART)
PCA9685 (PWM for Finger Servos and LED's)
L6932H1.2 (Regulator for 3.3v)
MPU-9150 (Gyro, Acc, Mag, Temp)

I really didn't want to make the hand board quite so big, but for what I wanted, there's really not a lot of choice - work from here will be to rework / shrink what I have and perhaps split out the finger LED's to their own board. At first, I used the PWM from the STM32, but the wiring was a lot uglier, so I put in one PCA9685 (I wanted PWM for the LED's as well). This also allowed me to use both sets of I2C connections (separate one for the add-on connector, and I needed UART back to the main controller and specifically UART1 to load the bootloader). I started out putting the USB circuitry (from the Maple Mini design) on the hand board, but I ended up splitting that out into a second board, a "programming board", if you will. This freed up some more space on the board. The MPU-9150 is mid-hand left to right, so that should be helpful.

I'm considering making the board structural, replacing the alu top plate that I'd been planning to use (and is in all the pics thus far). I'd rather have the boards in all black, but OSHPark only offers them in purple - I'm thinking I might airbrush them after they're built, and mask the connectors and LED's.

The location of the servo wires as they come up from the servos is fixed, no real way to change that without taking up more space (thicker hand). The vertical 4 pin connector on the bottom middle is +5v high current, tx, rx, and GND. This will be a right-angle header pointing to the left edge of the hand to keep wires clear when the wrist rotates.

The 4 pin horizontal connector above that will be for add-ons (laser pointer, sensors, who knows what). This will be angled forward and high enough to clear the components. There's +3.3v (at an amp or two), GND, and two pins that can be I2C, PWM, or GPIO.

I initially wanted LED's on the fingertips, but I think that's going to have problems (wires, LED mounting). I'm second guessing myself though, wondering if I really should bother with the LED's near the fingers at all - then I can ditch the PCA9685 for PWM from the STM32.

The main goals were to have an STM32 on the hand to handle servo motion interpolation and the MPU-9150, and to have an expansion connector for whatever ideas may come.

This will get reworked a few times over. Still not sure if I want to keep the LED's per finger.

For the "programming board", I just split out some components, added back a small regulator, and added a power LED. And yes, I need to draw the board outline for this.

For the other hand, I'll do a mirror of the major componets, but obviously the wiring will be quite different.

This will definitely change, there are a number of things I'm not happy with yet.

[PaulL]

Figured I'd put together a diagram to make some sense of the components / electronics - I think this is just about everything...

[xevel]

Hey Paul,

I've finally took the time to read all the thread from the start. It's quite amazing :O

All the machining, the sheet metal bending, the way you use the teflon strip (very cool idea!), re-purposing of stuff, making your on thrust bearings (so cute!!! I'll keep that in mind), the precision end-stop for the bending brake, the hips, the boards, the firmware...
This thread is a mine of information

I hope to see the end result at some point, but reading about the process is very entertaining and encouraging: it demystifies various aspects of "making things" ^^. Makes me motivated to build more stuff!
It also renews my jealousy of the US for having McMaster-Carr (and the part of Amazon that sells hardware like that)...

A remark though when ordering electronics parts: don't order just the right number of resistors and things like that. For components that cost less than a cent, just buy a round number somewhere above the number of parts you need. Sometimes it can be even cheaper to get 10 than 5 parts... It's a shame to have to lose time for a resistor that flew off when buying 10 more would have cost a few cents. You can always just throw the rest of the parts in a spare parts bin if you're not into inventory management - they will be there the day you're pulling your hair because you need a specific part while not costing any upfront sorting time.
Personally, I get so pissed off when I realize when I want to assemble something that there is just one tiny bit missing that I overstock EVERYTHING, the expensive parts I get at least one spare, the not too expensive ones I get at least double the number I'll need, and the cheap ones (like resistors) I get by 50 or 100 even when I need 2. After a while, it also makes prototyping and repairs much easier, when you have a little of everything at hand.

Also, you sure are lucky you don't pay by the via Where I get my boards done when I need them fast (Eurocircuits), they charge a premium when there are too many vias... >_>

Bump detection with accel/gyro is going to be interesting... I have played a little with these things and I would be quite annoyed if I had to do that, it's probably not going to be very easy :/

In terms of tools for debugging electronics communication: do you have a logic analyzer? You said you recently got a scope, which is a good step, but when developing firmware I have to say having a logic analyzer (like the Saleae ones, they even released new versions with analog capacities very recently) has been a TREMENDOUS help. I also find it very useful for code performance analysis, firmware debugging...

About the hand PCB: I would advise against making any board with QFN / LGA / BGA packages structural.

About the system diagram: it's quite the beast!
- What camera do you use? Why NTSC? PAL is much cleaner and your adapter is capable of digitizing it. Most low-cost small analog cams can be found in both variants.
- What kind of mic did you choose? Where will it be, and more importantly, how do you plan on avoiding hearing more noise from the robot than sound from the environment?
- What application did you use to make that nifty diagram ? I make very similar ones by hand for my bot (not as complicated but not by much...) and cleaning all that up would be a relief...

I realized that your design has a central power board that creates all the voltage rails, while the design of my bot is more akin to a main power board delivering one high voltage (equal to VBat but with various relays to power different parts of the bot) and Point of Load regs as close as possible to the load, be it the cameras, the sensors, the full-auto electric BB gun... I guess the fact that the servos are daisy chained in my case (Dynamixel servos) and not in yours makes all the difference... Any additional thoughts on this aspect of power delivery?


Keep it up!

[PaulL]

Hey Xevel,

Thanks!! I've been at it for a while now, and I won't quit until I'm done. The bot is going to be pretty slick, but the PC-side code I've written is something entirely different. I've done what I think is the best work I'll ever do (code), the bot is a means of showcasing that code - so I might as well make it a good one, right? If not for cost and time, I'd go much bigger!! Ok, that's not quite true - I'd still do small for round 1, it's safer. I have some theories about bound forms and learning, but the other point is to prove the work in the robotics market. About the only thing I won't disclose are specifics about the PC-side software. I don't mind discussing firmware, though some of my methods show up there too.

It's possible that I might sell hardware / electronics if there was interest (the work is highly platform-specific at the moment anyway), but that's not really a goal of mine - a lot comes with selling a physical product, more than I personally want to take on, which means I don't mind sharing the details of what I'm doing in hardware - if it can help or inspire someone else, I'm all for it.

I look forward to seeing the end result, too!! This isn't a project I'll let go of until it's finished - may take some time, though. I've tried to put dates on things, and that works sometimes, but too often, my work takes a back seat to other things - life happens, as they say. Currently, I have a pretty big project at my day job that has been looming, and now it's "crunch time", so I may end up losing a few weekends to my day job for a while (currently I have to do a few weeks worth of work in a few days, that's the current task - and it's achievable, I have a few tricks up my sleeve - just need some caffeine and quiet - system integration of a robotic manufacturing cell).

I do have a book of resistors and capacitors and a box of TDK capacitors (purchased with the expectation that I was going to lose a few common components), but I don't have duplicates of certain values. You're right, I should order a few more than needed of some of the odd values. And the resistor, I had one spare, so it didn't hold me up - this time! My old collection of through hole stuff just doesn't have a place in this world, it seems!!

Yeah, there's some good stuff in the US - OSHPark (no via limit! Though, these days, I think any shop with a via limit is just mean!), Sparkfun, Trossen Robotics, DigiKey, McMaster, SDP-SI, OnlineMetals, and a bunch of odd shops online for just about everything else - and ebay, but that's everywhere. What has kind of died is electronics shops - hard to walk in and buy your favorite components locally. We have Radio Shack here, but they seem more interested in selling toys and phones and such. I did see a few Arduino products on the shelf recently, though - marked up, of course!!

Regarding bump / tap detection - I have some code from ST that should work with the MPU-9150 that gives examples on bump detection, so maybe I'll be OK. I've also been toying with the idea of curve fitting - that during some motion, there's an expected response curve from the IMU - not sure how much I can do in the STM32 for that, though. I might be able to create some "expected" curves, and notify on deviation from those, letting the host PC figure out why or what to do for more info (physical interference, etc). Shouldn't be much different than what they do on a Wii, but who knows how that's actually done in code. Now that I think of it, I bet all they do is curve fitting!! Game difficulty being a function of greater tolerance of the fit of the curve... Hmm... Maybe I can teach the bot to play the wii... LOL!! Would have to scale the results, though - he's a bit smaller than I think Nintendo intended their players to be.

Ah, no logic analyzer, though I did look at the Saleae in particular. I was an hour or two from buying one out of frustration when debugging the STM32 I2C hardware when talking to PMBus devices, but I managed to fix the problem in code. It's a DSO scope, so a 2ch logic analyzer - it has a PC interface that should work with the latest software, haven't hooked it up yet, though. Still might buy the Saleae - folks seem to like it well enough.

Structural controller - yeah, now you tell me. I've finally done what should be the last rev of the hand controller bracketry - I was at a point where I wanted the specific board outline for the final rev with new mounting points, but you're right, it probably will fail prematurely. So, I'll lay out the board again and see how much smaller I can make it. Originially, I was thinking separate layouts for each hand, but if I make it smaller, I might be able to do a single design that looks OK.

Camera - it's a BCM26P (480 TVL of resolution) - tiny, here's a post I did for it:

http://robosavvy.com/forum/viewtopic.php?f=21&t=8977

And an inline pic to show size:



And a capture from the camera:



You can see from the pics there, it's quite small, smallest one I could find - I believe it was only available in NTSC, but I could be wrong...

Video is OK for such a small camera, I think - a bit dark, but the lighting wasn't the best when I took that pic. Focus is OK even for room viewing.

Mic - I have an old Gateway one I was using to test SAPI 5.1 (Microsoft's Speech API), which works FANTASTIC in command mode - no problem with fast speech, slow speech, ambient noise (two fans), etc, so it should be OK. I'll vibration-isolate it, rubber or some such, and may do some felt around it. I'll mount either under the chin facing forward or I'll put it on the top of the chest. I considered stereo mic's at one point, but it's something I'll do later if I want to go that far - would need a line level amp for them (single mic input for the Kontron PicoITX SBC), so another board tucked somewhere. I have to say, the results using SAPI in command mode were impressive. It worked extremely well with a handful of commands and lots of ambient noise. In "dictation" mode, it tries to use grammar rules, which easily slaughter the results. Command mode makes much more sense, and is a lot more robust. So, he'll have is own specialized version of grammar - nouns and verbs and not much else. I've been toying with the idea of programming him by speech, that should be interesting. The level at which his configuration will occur shouldn't be tough to implement in a simple voice interface.

App - I used Visio for the drawing, in a flowchart - the lines can be a pain, but they're not too bad. It's good for this kind of work.

Power - yes, the main reason for centralized power is PWM for the servos, which require "home run" wiring. And, I have a fan for the CPU that also will cool the power board, so one fan in the back for the power board and the SBC. Kontron said you can run the Z530 at 1.6 Ghz without even a heatsink or air cooling with shorter board life (Like Compulab does with the FitPC, as is done in any bot that runs it, like Darwin or Nao), but I wanted a fan, and need one for the DC to DC converters anyway. I could go without the converters and run right off 7.4 for the servos, but I wanted more control over power - servo idle current increases with voltage in, so I went with adjustable power - can run the servos from 5v to 6v adjustable through the converter. Also, the PCA9685 will let me stagger the PWM so all of the servos aren't spiking the converter at the same time (this can reboot a bot running a Roboard!).

I lose a little power in the servo wire runs, but not enough to try something terribly different. If I had dynamixels, I'd still do a central power supply (still need to power the SBC and micro and such), albeit with 5 or so feeds (arms, legs, torso) - having one fan for the SBC and for the power converters seems like a better choice. Additionally, any losses on the PWM wiring won't affect other servos - they all come from the same high current bus. The hands are an exception, all power coming down the same pair of wires, 20awg for 5 micro servos at about 8 inches should be OK though - even if power drops, it shouldn't get down to 3.3v without pulling way too much current, which I can check in the DC to DC converter and do a controlled shutoff (ex, shorted servo).

There's not a lot of control over standard servos, the DC to DC converter gives me better control - but they need airflow to get closer to their rated output...

That said, I do plan to do POL (kind of) at the hands, 5v micro servo power to 3.3v reg for the STM32 and such.

I'll have an amp or two available for plugins for the back of the hand (4 pin connector, right angle), 3.3v regulated.

Staying at it!! It's definitely getting closer - torso rev 1 is cut, hand and wrist rotation brackets and such ready to be bent, boards coming along!!

Paul

[PaulL]

An update...

I ended up laying out separate boards (non-structural) for left and right hands. I did this in such a way that a single paste stencil can be flipped and used on both boards (tedious work). I stuck with LED's per finger, though they're just close to the fingers. I also stripped down and reworked a version for the foot controllers. With the programming board, I have 4 boards almost done. I'm thinking one more day of Eagle and they'll be ready to send off to fab.

I'll rework the controller and power board just a bit as well, so it'll be 6 boards (18 total, 3 copies each) that I'll send off, probably this coming weekend - along with paste stencils.

I need to do some testing, I think I'm going to pull the opto off the main controller board and replace it with an OR gate for the hand and foot controller Tx lines and direct-wire to the PC board header (as soon as I sort out the control signals required).

There's some GPIO on the Kontron PicoITX PC board, but I don't think I'm going to tie in to that for any reason - I'd like to keep the interface to the PC board relatively generic, such that any similar sized board with audio and USB ports would work.

In the hand brackets, there is a .003" discrepancy for one of the mounting holes for the top plate - it's not in the transfer of DXF to Eagle or to anything I've done in Eagle, it's in the drawing. Once I figure out why and correct that, the hands will be ready to CAM, cut, tap, and bend.

I wish I could take a couple weeks off work, I'd be nearly finished with electronics and hardware, including any torso revs and such, possibly to the point of having him fully built, or at least ready to finish wiring up.