Project: Melissa Hands - Perhaps a little easier..

[PaulL]

Final soldering on the custom boards is done (aside from wire lengths to be determined later). Parts are sanded and washed, ready to be bent.

SATA interconnect boards arrived, all fits well, soldering needed to finish (two plugs, two wires).

This past weekend, I began work in earnest on reading the scale on the backstop for the bending brake with a Maple Mini to display the scale data on an LCD (where it can be more easily seen).

I have the levels from the scale (1.5v) working with the Maple Mini. I'm using a 5v HD44780 LCD, no problems there. I tried to use a 9306 level converter, but that didn't work. I ended up using an LED to regulate 1.5v to the scale, and that works fine - its ground is floated using a resistor (actually one each side of the power / gnd) to make the voltage levels work on the Maple Mini. I added a library I found (digitalWriteFaster) for the Maple boards - I used a "read from pin, write to pin" to validate sampling rate and logic levels working from the scale, works fine viewing the clock on my o-scope.

I still need to define some code that looks at the full 48 bits, for now it looks at 24 bits, and switches between the samples it finds. I just need to do a bit more code to parse all 48 bits and clean up the result (format it for display), and it's done.

It's a step or two away from dialing position in with a stepper or servo, but I don't think I'll go that far with it. Primarily, I need a display I can read more easily than the one on the scale (far under the bending brake on short bends).

Remote display for the scale using parts I had laying around - works for me.

The code for sampling scale data is decent, a bit more robust than some other implementations I've seen.

I'm still tempted to add a sliding stop (arc shaped alu, slotted for adjustment) for setting 90 degree bends in 1mm alu sheet. That would be made from 1/4" alu plate, but I don't have a big enough piece around for that. We'll see. I am also tempted to set up an adjustable stop for the clamp since it moves the part, might wrangle in the last .002" from the bend.

[PaulL]

Oops... Finally bent the torso brackets this past weekend - after adjusting the bending brake a little too far forward. Several test pieces bent without issue, but most of the bends on torso parts cracked. I'm still not clear as to why the torso parts snapped when the test pieces didn't. These parts were sanded, but not much - just enough to clean up the surface, leaving it with a nice looking brushed finish. I think I was on the edge for the brake finger position, perhaps the sanding was enough to provide a point of failure in the bend. I'll need to do more testing to figure out what needs to change.

For certain, I'm going to reduce the amount of material in the bends - I'll cut slots along the bend, like I did for the hand brackets. Something else I found was that getting a proper 90 degree angle depends on the width of the material due to increased springback in a wider part.

Something to note: you can only attempt a bend once. Twice is too much. In trying to get 90, I bent one part twice, which caused it to change from not being cracked to severe a severe crack in the bend.

Still, these cracks weren't as bad as when attempting to bend by hand (which resulted in greater level of cracks, to the point of snapping completely). I'm simply right on the edge with the tightness of the bend, a little too far this time.

Good news: there was enough material and strength left in the bends to go ahead and build up the torso. No pics yet, but the overall results were mixed - very tight fit for everything, so I'm going to make a little more room (maybe half a mm all around). I have the boards (PC Board, custom boards) in the torso, and even mounted the hip joint to check clearance. The hip joint is great, the servo spacing in the hips is perfect, and the boards do fit. I see where I need to add some more space, where I need to make some finer adjustments. In all, the first torso design is workable, and I could even use the parts as is (the torso is quite strong, despite the cracks in the bends).

But, as some may have guessed, it's not acceptable to me - I'm going to rework the parts in CAD, re-cut, and fine tune the brake a bit more.

As for the scale - I finished up the code, and that's what I used for setting the backstop, which worked great. I have some LED displays I ordered, they showed up Monday. Some protoboards showed up Tues, so I'll move the scale display circuitry over to these boards. Swapping out the display and related code is on the to-do list.

I forgot to mention in this thread - I've weighed the parts, done some math, and figured out the approximate (but close) all up weight: very near 4.2 pounds, all parts included, with some additional weight thrown on. There was more wiring on the scale than there will be in the bot (long wires until I get lengths sorted), so I should be OK. 4.2 pounds is the approximate limit based on scaling of torque from the stock configuration (HSR-8498HB to HSR-5498SG servos), using the upgraded servos at 6v. He may be a bit sluggish, but I don't intend to fight with this guy. He should be able to walk just fine.

I have some holes to cut, and I think I'm going to do a bit of lightening of the parts while I'm at it. There is a lot of metal in the torso, and visually, it looks like it's more than necessary. I'll work on the look as well.

So, more focus on hardware for a while.

Was the bending problem I encountered a total loss? I'd say no - I knew I was going to cut revisions of some of the brackets anyway, I was still able to check fit, and fitment shows I need to make adjustments to all of the brackets. After all, it is the first revision for a completely redesigned torso!

Now for some more fun:

The fit is very tight inside. Wires abound - on the edge of too many wires. I've been noticing more and more powerful processors in smaller and less power-hungry boards. I've seen COM Express boards in the past, but I didn't look too far into them. Recently, I looked, and there's a Celeron J1900 COM Express Mini board that is quite impressive - 4GB RAM, 2 Ghz, 4 cores.

With the Z530 board I have coming end of life this September, I have a choice - I can stick with the one I have (likely buying at least 1 spare), or move to something else.

I'm leaning towards building one carrier board for a COM Express module, just one board to host the custom circuitry and connect to the COM Express board. If I go with COM Express Type 10, I should have an easy upgrade path for longer than a specific SBC can provide. The main question is: can I fit the design into 2 layers on a PicoITX sized board?

There could be a market for a COM Express carrier board specific to bots with PWM AND Robotis interfaces and the various usual hardware...

I've started on a design to see how feasible it would be to fit everything on such a board. So far, it looks possible.

For now, I am sticking with what I have, finishing the bot as originally intended. The goal for any future carrier board would be for the whole thing to fit inside the torso I've designed, an "upgrade" after I have proved out everything else.

[erbay]

PaulL, This is the type of project I have been looking for, the excellent problem solving skills, design knowledge and hard work shown in this project are perhaps the best I have seen in a long time. I have been reading your updates regularly and I’m a little surprised that you haven’t posted any for the last few months. Anyways, being an electronics engineer who loves such projects, I must say I’m hoping for a quick update.

[PaulL]

Hi erbay,

Thanks for the compliment!! I often wonder if that last interested soul has given up reading my posts here, if interest has been ultimately lost in reading my sometimes long and unintentionally rambling posts on a forum that sees only a handful of posts and a mere trickle of users per month.

It's nice to know someone is reading what I'm doing here.

I try to do the work I do to a level I consider suitable - I constantly struggle with "good enough", I think I've mentioned that somewhere here. When I find I'm not sure if a design is good enough, I either go ahead and build it to see where it falls short, or I let it sit and bake in my mind while I work on some other aspect. I try to be as accurate at first attempt as is feasible, sometimes successfully, sometimes not!

My formal education is in EE, but in my day job I write software. I'd like to do EE work as a career, but switching my career path now wouldn't be easy - I've been doing software / IT stuff for too long.

In my day job, I'm constantly making judgment calls, sacrificing what I consider to be a better but more involved design for a less optimal solution in light of a deadline. I like to over-deliver, but they're catching on to what I can feasibly do in a certain amount of time, meaning I don't have time to invest in better designs. My work at home is my attempt at doing what I can't do in my day job - to implement designs I believe to be the best solutions, particularly in software.

In part, my day job is one reason I haven't posted recently. We are in the final implementation stage of release of a huge project with numerous machines, and this is when I'm busiest - software I've written controls these processes. Scope creep is absolutely a problem I face daily at this stage. Can we change X? Can you do Y? Yes, yes, of course, but is it NEEDED? Long hours, long weeks, long months. I am burning out, sure.

This isn't an excuse, though - I have done some work on my project (not as much as I would like, but then it's never enough!!).

I don't know if it shows, but I was pretty frustrated with the results of the torso design, particularly re-adjusting the brake and inadvertently pushing too far on tightness of bend. I like to think at some point I've figured out how to do certain things, but the brake problem was discouraging. I had to adjust the brake though, the fingers weren't parallel to the rest of the machine. The result of this is that one side of a piece bends tight, the other side has a larger radius. I needed a consistently tight radius for the full length, so the machine had to be adjusted. When one side is adjusted forward, the other side must be adjusted back to offset the first adjustment since the position of the piece is between these two adjustments. It would be nice to have some reference surfaces on the casting, but without them, re-adjusting both sides in a test and re-test mode seemed to be a suitable method.

I bent a number of pieces in an attempt to make sure I still had good bends - I used some 5052 (more giving than 6061) at first to get the fingers parallel to the machine, probably 10 pieces. I then bent some 6061 to see if I was in the sweet spot. Same batch of aluminum the torso came from, same methods I'd used before. Those five or six test pieces seemed OK, I only checked for cracks in the bend and didn't examine closely enough. Even in looking at these pieces after bending the torso parts, they definitely don't have any cracks. The differences in the test pieces versus the torso pieces are that 1) I sanded the torso pieces, and 2) the width of the torso pieces was more narrow and required lower clamping force (another reason a clamping lever stop would be a good thing).

I bent something over a dozen test pieces, but something was different in bending the torso parts. Same alu batch, same methods. When I looked at the test bends post torso disaster (perhaps that is too strong a word - I should post a few pictures of it), one thing I could barely see was that the outside of the radius on the 6061 test parts show a very slight flattening on the outside corner of the bend. The radius was too tight, and that flattening is from pulling the material around the corner. This flattening isn't on prior bends, and is from the adjustment I did on the brake - too tight. On closer inspection, I found a fine hair sized sliver on one of the brake fingers - I'd gone from bending action to sheering action, so that was the last bit of proof that the adjustment was the problem.

The brake must be adjusted again, the fingers are too far forward - the change needed is somewhere around .010 inches or less. There is a very fine point of adjustment where too tight seems to be mere thousandths away from good results.

The next time I do this adjustment, I'll do testing on 6061 only. I'm out of 5052, so I won't be using any of that for testing in the future. I'll definitely be more cautious when testing the adjustment now that I know to look at the contour of the bend as well. I'm debating on making a few changes to the brake. One, setting up a stop for the clamping lever, and Two, to set up some stops for a more scientific means of adjustment.

The adjustment itself is simply two cam levers locked in place with setscrews. Just tightening the setscrews moves the top part of the brake.

I've also done some work on the PC to controller communication protocol, working out the PC software side of things.

The biggest work I have to do at the moment is design work on the torso and then to re-cut it. Also, the brake needs to be adjusted again, very carefully!! And I need to take a few pics of the torso as built, I'll try to get those up this week.

Thanks Again!!
Paul

[xevel]

I often wonder if that last interested soul has given up reading my posts here, if interest has been ultimately lost in reading my sometimes long and unintentionally rambling posts on a forum that sees only a handful of posts and a mere trickle of users per month.

I haven't, that's for sure Just been... busy, and therefore quiet :/

Always nice to get some updates.

Good luck with that fiddly brake.

[PaulL]

Thanks, Xevel - wasn't sure if you found a more interesting spot to hang out - kind of slow here...

I have to say, I'd like to know - "Where'd everybody go?"!! There used to be quite a few here, I wonder what they're up to now.

And as for this brake, I'm going to beat it into submission!!

Take Care,
Paul

[PaulL]

Ok, so I've been busy with my day job - very busy, USD $4m project I'm involved in - but it's close to the finish line.

Meanwhile, here's a vid of the scale display (the LCD isn't easy to read as mounted to the pan and box brake, this is just so that I can see the measurement):

phpBB [media]

http://www.youtube.com/embed/R9q5zhM7WSs

It is difficult to capture due to brightness of the 7 segment display, but this shows how the values on the scale track with the remote display. I'll move this to a prototyping PCB next.

This uses the libmaple libraries, with Hardwire and DigitalWriteFaster libs added. I'm not using the Adafruit libraries for the 7 segment display, it's not directly compatible with libmaple and was easier to write my own code for it. The code does timeouts and such in order to stay in sync with the scale data frames.

I still need to take pictures of the torso work, hopefully I'll actually get to that in the next few days!!

Hopefully, I'll make more progress here before long.

[PaulL]

A quick update - I've been doing a lot of thinking about a COM Express carrier board. The PicoITX board I have now is officially obsolete, and its successor leaves no room for an adequate fan in the size I have to work with. The Roboard was a great start, this board is faster but not bot-specific, so it needs other boards to get the functionality needed. A COM Express carrier board could do both and would have some amount of future proofing.

For those that don't know about COM Express, it's essentially a spec encompassing a connector (or two, depending on COMe type, I'm interested in type 10) and a form factor consisting of a plug in PC board with no external connectors (generally speaking - there are a few exceptions, FAN, LVDS), that is what the carrier board is for. On the COMe board is a CPU, RAM, BIOS, graphics processor, and sometimes even SSD (though counting on it limits a carrier board design, and integrated SSD boards tend to be more expensive).

COMe Mini is the size I'm interested in, as it is the smallest. There are single, dual, quad core boards available, with different amounts of RAM, different CPUs, etc. I'm looking at a quad core J1900, 2 Ghz, 4 Gb RAM - a bit more than an Atom Z530. Power dissipation is about 10w, so not impossible to do in the size I have with the power constraints I have.

There's a lot involved in the design of a board that has to carry SATA, Ethernet, display, and USB, which means the design will take longer to implement than a board using lower speed signals.

I've done a lot of reading and research, and I'm almost to the point of committing to a COM Express board. No one has built a COMe carrier specific to bots yet, this would be the first as far as I am aware. I'd like to pack all of the power, PWM chips, etc, etc, onto this board, leaving one board in the torso with the COMe module instead of the PicoITX board, a power board, control board, and breakout board (not to mention, seperate purchased board for NTSC video digitizing). This also means less wires, less weight, and hopefully I can get it all to work in the space available. It does require a 4 layer board (impedance reasons), meaning I have to upgrade Eagle. I also should buy the COMe spec from PICMG. Who knows, maybe there will be some interest in the market for such a board. Would be nice at least to recoup some cost, it won't be cheap. I'm hoping I can make the design fit in the space I need, but I won't know this until I get a design mostly done.

Take Care,
Paul

[PaulL]

An update!

I have committed to building a COMe carrier board specific to robotics. I bought a license for Eagle in order to do 4 layer boards a few weeks ago, and I bought the COMe spec a few minutes ago. I want to make sure that when I build this thing, I don't a) fry the COMe board when I plug it into my carrier, or b) waste time working with outdated info. Further, having a copy of the spec is worthwhile if I ever sell these boards in the future.

I think back to a post from iBot to one of mine from time to time, about whether motion control should be on a main controller (ex, kinematics processing) or offloaded to an embedded controller. The point I ultimately made was that my approach allows either - I probably sounded cocky, but at least I was sincere. Bottom line is, the embedded controller (currently STM32F103CBT6) I have been working with is about to get upgraded (ARM Cortex M4 series, 180 Mhz, down to just a few choices at this point). A faster processor is, well, faster. I was concerned with the 72 Mhz STM32F103 as to whether or not it could handle all the comms I plan to throw at it. The external controllers (hands, feet, 2 layer boards) will remain as STM32F103CBT6 - it's plenty for what they do. The upgraded main controller should leave a good bit of room to play: faster, and a LOT more memory.

I'm sticking with ST for these chips, as at least I'm familiar with them, and they offer a lot of flexibility for pin / feature config. Much of my code should work on the upgraded STM32, but I'll need to let go of LeafLab's bootloader and their LibMaple code. At least the toolchain will be more flexible this way. Otherwise, I'm doubtful I'll use ST's code, they use a lot of "blocking" calls, as I've seen in their I2C code. The hardware itself can do better!! The chip is fast enough to use an embedded OS, so that choice is there, too - though I doubt I'll do that, there is too much risk of overhead in using someone else's code.

This will be an interesting bit of work, a long way from where I started with the Roboard RB-100 - but then, I think the results will be worthwhile.

So why do I think COM Express makes sense for robotics? Small form factor, low power requirements, minimal dissipation, PC-based high level control, and ultimately, UPGRADABILITY - at least, until something obsoletes the spec - but at least a carrier like this can use just about anyone's COMe board (well, Ok, COMe Mini Type 10).

Of course, I'm a bit put off that I have to go through another round of board development, but I think in the long run, the results will be MUCH better. One custom board in the torso (the carrier) instead of 4 custom boards (and one video capture board), and a LOT fewer wires, better airflow, overall, a better design.

Ah, forgot to mention: I've been doing some research on a video capture solution to integrate into the carrier board, something to take a composite video signal and digitize it, sending it over USB to the COMe board. Conexant makes a complete Video to USB chip (this would be PERFECT!), but they don't sell small quantities, and they don't even publish their datasheets. Instead, I'll have to build some sort of frame-by-frame capture - not sure what I'm going to use yet, still trying to find some suitable chips. Again, I have a small 3 wire camera: power, gnd, video - and this will be in his head, it's the smallest one I could find for purchase.

What's to do? Wait on the spec to show up (it gets mailed, no download), and do more research on video decoder chips and pick which STM32 I'm going to use.

Take Care,
Paul

[PaulL]

In working out a video capture USB interface, I have decided to use a Cypress FX2LP USB interface chip (CY7C68013A-56LTXC). This is advertised to support 480 mpbs via USB, so video capture should be fine with this chip.

I ordered the development kit for the FX2LP the other day, and it should arrive today. The dev kit should make the work faster and less problematic.

As for the STM32, I have decided to go with the STM32F427VIT6, 2MB flash, 256K RAM, 180 Mhz.

Just need to look for an HD Audio codec (2 mic inputs, low pin count, 3.3v supply) and choose a Video Decoder (TI or Analog Devices, the lower the support component count, the better).

I think I'm up to 10 or 11 chips for this board:

USB Interface for Video Capture
Video Decoder
HD Audio Codec
STM32F4 Microcontroller
PCA9685 x 2
MAX1614 FET Controller
MPU-9150 Gyro / Acc / Mag
OR Gate for Hand / Foot controller interface
TS2012 Class D Amp
CP2103 USB to Serial for programming STM32F4?

Basically, this will be my previous design, stepped up a few notches.

[PaulL]

I've got an Audio Codec in mind: Cirrus Logic CS4207. After I found this chip, I found a COM Express carrier that uses the same chip, so I'm on the right track.

I'm fairly certain that I'm going to use a TVP5150 or TVP5151 video decoder from Texas Instruments. It's been around a while, but it has the right capabilities. I'm thinking I'll send uncompressed video over USB via the FX2LP, that's the plan for now. I don't see much reason to compress the video stream since I'll just be decoding it on the other end anyway.

The spec arrived, I've been reading through it.

The FX2LP dev board showed up, and I've been playing with that as well. I'm thinking of using a seperate FX2LP for the STM32F4, but that depends on space.

I've also been reconsidering the DC to DC converters, they do take a good bit of board space. Still, they offer a few nice features for their size, and they're very efficient. I can't make a decision about keeping them or not until I'm further along with the board design.

An interesting note, I have only 1mm of height below the COMe board for components with the 5mm COMe connector (shorter of two options). If I use the 8mm one, that increases, but the total height of the stack will be that much taller. The cooling solution will be affected by height changes due to available space. I really don't want to do components both sides of the board!

For PC related connectors, I'm thinking of doing one external USB and ethernet combo jack, with a USB hub for kbd and mouse externally when needed. There will be two SATA connectors.

This weekend, I'll work on the schematic and start seeing what can fit on the board.

[PaulL]

Short post: It's coming along. I have made quite a bit of progress, but there's a lot more to do. The PC connectors are huge, not quite enough room for an RJ-45 for ethernet, Mini DisplayPort connector is pretty long, USB and SATA look a lot bigger when placed on the board.

I'll have to make some compromises somewhere, but it's shaping up, bit by bit.

I'll have to make a board just for testing the TVP5151 video decoder, I'll do that after I'm a bit further along with layout. I'll copy out the chip and related components to a 2 layer board, that'll let me figure out if I want to do uncompressed video or add a chip to compress the data, and get video capture through the FX2LP working before I make a 4 layer board with a bad design.

Take Care,
Paul

[PaulL]

Here's a picture of what I have so far. The dashed box is the COMe board's outline. There is 3mm clearance between this board and the COMe board above it, meaning big things like that RJ-45 jack overlapping isn't going to fit. The connector in the front is a SATA connector, data and power.

[xevel]

As always: wow.
The thing about compressing or not video: make sure you have enough bandwidth for the resolution/framerate you are interested in, without completely killing the bus if you want to put more stuff on the same controller.

[PaulL]

Thanks, Xevel! There's a ton of work to do, but I think it's going to be a lot better than what I had - far fewer wires, more capability. I'm trying a number of things I haven't done before, so it will be interesting!! I shoehorned a lot with the last design, which meant I skimped on connectors (lots of wire-to-board), but I'm hoping to do something nicer on this board.

Video - yeah, it's a 27 Mhz clock for data out of the TVP5151 over an 8 bit bus, so it's a good bit of data, I think 30 FPS. The FX2LP USB interface is supposed to be capable of 480Mbps, but there are a lot of "what if's". Building the TVP5151 and related components on a test board will let me plug it into the FX2LP dev board to see how it works out (schematic, FX2LP config, PC-side software). The FX2LP also has I2C, so the I2C slave on the TVP5151 can plug right in. I'm planning on keeping the FX2LP dedicated to video, though I'm still debating on what I want to do with the STM32F4 (between the F4 and COMe USB).

I'm concerned over what it will require of the CPU - it's BT.656 data, interlaced and not RGB, so it needs to be converted for display at least. Not sure if it will be better to use YCbCr video or convert it to RGB for processing PC-side...

As I look around the web, it seems a lot of guys recommend an FPGA for working with video in this kind of scenario, but do I really want to slap an FPGA onto this as well (ex, like a Mojo board), and have to program that, too? I could remove a few chips if I put in an FPGA, which would make it a bit cleaner, so I'm considering it. May buy a Mojo to play with. It may make more sense to do an FPGA, would open up some flexibility.

The high speed signal routing is where this board is going to be a pain - not a lot of tools in Eagle to help with that - it will be a very manual process. I've calculated my trace widths and whatnot based on the 4 layer board stackup from OSHPark and the required impedance for the various signals, it's going to take some work to meet the specs (SATA, DisplayPort, etc).

The constant question I have right now is, can I get the first board to work?

Take Care,
Paul