Project: Melissa Hands - Perhaps a little easier..

[PaulL]

Good News, Bad News, and Progress.

So, there's this:



I've done some work on placement. What I've found is that I can't include Ethernet, USB (1, let alone 2), and DisplayPort video on the board. And, the Mini DisplayPort connector I found in the Eagle libraries is out of production, and there isn't anything that small available anywhere that I could find - most have a bigger footprint, which won't fit beside a USB connector as it is in the pic.

In all, there just isn't enough room for all of the PC connectors. So, I asked myself: is this a PC board, or a Bot controller? Of course, it's a bot controller. Do the PC connectors HAVE to be ON the board? No, they don't have to, but it sure would be convenient. Since they don't all fit, what are my options?

* Eliminate the DC to DC Converters.

This is tempting, but even then, I can't get rid of all of them. I can only pull one of the small ones - maybe. Here's why:

** The 5v micro servos I have won't take any more than 5v - they'll fry. So, 5v DC needed, substantial current handling.

** The board may end up with 3C Lipo at some point, so around 12 volts charged, which is more than the main body servos can handle. I also plan to power this off a 12v bench supply for testing. So, about 6v DC needed, substantial current handling.

** The fun one is 5v DC for Logic. This one is a potentially interesting option. The COMe board (the PC Board itself, not the carrier I'm building) I am planning on buying can do 5v in. COMe spec says can go up to 20v or so, 12v would be fine, but some of these boards like 12v. So, I could add a MOSFET switch for battery to the COMe board (don't want always on), but the slew rate for power on would have to be controlled. There is a need for 5v in places, so 5v still wouldn't entirely go away, but I could use a smaller regulator instead.

Since all power wouldn't route through all DC to DC converters (these converters can measure volts and current), I couldn't keep an eye on all power handling without some circuitry for that. Using the 5v Servo converter for digital stuff is just not a good idea. Then, there are the two 3.3v regulators - one for 3.3v logic power, the other for the high current class D audio amp. These two need more than just tens of mA, and running off of 12v in would heat them up a good bit. Less is lost to heat in keeping these powered off 5v instead of 12+.

In all, does the separate 5v DC to DC for digital make sense? In all ways but 2: COMe boards needing more than 5v won't work using a 5v DC to DC converter, and it takes up space - but any other solution would take more space. Also, there is room remaining under the COMe board where such components would fit (DC to DC converters are too tall, and so have to be at the board edge). For >5v COMe boards, I could provide a means to switch to battery, but slew rate for power on would still need to be controlled (which the DC to DC converters do).

Sounds like a lot less work and better design to keep all 3 DC to DC converters to me...

Back to fitting options:

* Get rid of mounting holes to make room. Well, I can't ditch the 4 for the COMe board, but I could do something with the other 3. But then, how would I mount the whole thing? It was one thing when I was working with smaller boards, but this one must be mounted. I could reduce the size of the mounting holes, but the one for the bottom left corner would be different, and that won't gain much.

* Use smaller connectors. Not possible, can't find smaller USB, can't find compact Mini DisplayPort (ones I've found have a larger footprint than in the pic), don't want to try something other than RJ-45 for ethernet.

And lastly, the one I'm strongly considering:

* Use a breakout board for PC connectors through one multi-pin connector.

This seems like the best option, except for one problem: DisplayPort. There are a number of signals, and they're high speed differential pairs. Hosting DisplayPort offboard would mean increasing the signal length as well, potentially causing other problems. DisplayPort is simple in that it needs minimal support components, but the reality is that the high speed signals are a pain - and is it really necessary to have that kind of video bandwidth on a bot controller? No. So, I found a chip, NXP PTN3392 - and it converts from DisplayPort to VGA. VGA signals are far less finicky than DisplayPort, and I could keep the numerous DisplayPort signals shorter in placing this chip close to the COMe connector.

So, offboard could be: Ethernet via RJ-45, VGA via standard VGA connector, 1 (maybe 2?) x USB via standard USB connectors. This should be sufficient for a dock for a bot controller.

How many pins? VGA takes 9 (including 5v power and gnd), USB uses 2 (shared power with VGA), Eth uses 8. 19 total, 21 with 2nd USB port.

So, if I re-task a connector for all of these signals (ex, slightly larger Mini DisplayPort connector), I have a solution.

In thinking about this, one must wonder why no specification exists for a port for embedded systems, like a docking port, with these kinds of interfaces attached, using minimal space. It seems I'm about to create something like that, though it will be proprietary.

Well, after a search, I found DockPort, but the one chip I've seen so far for interfacing doesn't do ethernet (TI HD3SS2521). Interestingly enough, DockPort uses a Mini DisplayPort connector. So there's a spec, but it is relatively complicated to implement (ex, could I use it to host the main display device?) and fairly new (compatibility issues?).

I could just do a USB hub externally, and hang a USB to ethernet adapter off of that, then I wouldn't have to route the 8 ethernet signals through a docking connector.

At the moment, I am debating on ethernet over USB, routing just USB and VGA out off the board through a connector (which one?) to a docking board. This docking board would contain at least 1 USB to connect to a USB hub, or contain a USB hub itself (ex, TI TUSB2077APTR, up to 7 ports!!). It would also host a standard VGA connector.

Right about now, I'm thinking of using a good ole' pin header male / female right angle set between the dock and the bot board.

Take Care,
Paul

[PaulL]

Latest pic. It's coming along, but there's no room for the same Xilinx FPGA on the Mojo - it's way too big. Of course, there are smaller FPGA's (seems most smaller ones are BGA), but I have some work to do before I seriously consider adding another chip to this thing, let alone a BGA (very dense pin layout).



This includes the DisplayPort to VGA chip, and a bunch of other changes. Note the right angle header for offboard connections, top middle. I think this is going to be the best method.

Yes, I've put down a bunch of traces, but mostly just to see how things will go together. I'd be surprised if any of these traces last to the end. This is on 4 layers, I just have the other two hidden until I find a color combination that looks nice when visible with the others.

There's a lot of room to situate things better, which will be the bulk of the work for a while.

Something I forgot to mention in the really long last post - enlarging the board to accomodate the PC connectors. If I do that, my torso will get resized in X and / or Y. It's probably going to need a Z adjustment as it is - the stack of this board, an 8mm COMe connector to the COMe module, the height of the COMe module, and the cooling on top will end up taller than I would like. The cooling solution will be a tradeoff of acceptable temp versus height. The top and bottom are limited by the shoulder servos on the top of the torso and the battery and hip rotation servo swing on the bottom of the torso.

Miles to go, but it's moving along.

Take Care,
Paul

[PaulL]

An update. Moving things around...

[PaulL]

Changed some more things around, it will be a lot like this for a while, but this is with the schematic about 95% complete. Board has a long way to go.

[PaulL]

Animated - Progress up to now...

[PaulL]

A month and a day. Stalled? Not at all. I've done a small amount of board work, but I've been working with my software for the most part. It would be nice if the bot was built, if all I had to do was software, but that isn't the case. I haven't been particularly focused towards completion, so I suppose now is a good time to re-evaluate what is remaining and build a plan from that.

What remains, in approximate order:

* Design (copy from my schematic) and Build a board for the TVP5151.
* Set up an interface for the TVP5151 using the Cypress FX2LP USB Dev Board.
* Incorporate any changes between the TVP5151 and the FX2LP into the schematic.
* Buy the Kontron Celeron J1900 2.0Ghz, 4GB RAM, Type 10 COMe Mini board.
* Finish the COMe Carrier board design, build, iterate as necessary.
* Dev on STM32F4 code from what I have so far - motion controller, power mgmt, etc.
* Hardwire the bending brake remote LCD display proto board, mount to brake.
* Get the bending brake back right again.
* Finish the Hands!!
* Bend the 2 remaining hip rotation and wrist rotation brackets.
* Rework torso in CAD to fit COMe and Carrier, build, iterate as necessary.
* Build up the bot, hardware and electronics.
* Code, code code.
* Whatever else I'm skimming over (ex, neck brackets, mic and cam mounting, etc)

Coding:
* Hand firmware
* Foot firmware
* STM32F4 firmware
* My PC-side code

Looks like 2 or 3 years worth of work to me...

I've been wondering if all of the time in hardware and electronics is worthwhile, if I shouldn't just buy something like the HR-OS5 and focus on software - but the problem there is, well, the HR-OS5 or any other bot with a ton of performance isn't exactly affordable. And, what I've got in the works isn't exactly available off the shelf. Even with a purchased bot, I'd be making compromises I really don't want to make.

At this point, I think persistence is the name of the game...

Take Care,
Paul

[limor]

so are you working on the hands or full humanoid?
HR-OS5 is $16k - there are alternatives..
and the Kontron board for $400.. what kind of computation do you need ?

[PaulL]

Hi Limor,

This thread started about hands a few years ago, but ended up being where I put everything else since then.

I started with a Robonova-1, but at this point, no stock servos (all replaced with HSR-5498SG - far better!!), no stock torso, no stock plastic mittens for hands, no stock chest / back plate, no stock controller, and no stock brackets (blue on final build) and some of the stock position brackets are to be replaced with custom stuff. It would've been easier to state what IS still RN-1: same physical size servo, same basic dimensions, same foot coverings, some of the brackets and head from a Hitec bracket set.

Yeah, the price of the HR-OS5 is discouraging. I have a few "unique" features in my bot target design, here's a relatively brief list:

* Custom COMe carrier, module upgradeable, audio amp, video capture, advanced power management, hardware PWM, ARM Cortex M4 for motion control and other functions.
* Separate ARM Cortex M3's in hands and feet (with MPU-9150's).
* Custom 5 DOF hands (e-chain, micro servos, etc).
* Custom cable-actuated hip and wrist rotation (bearings, brackets, etc).
* SSD Plugin (power and SATA, one connector).

One of the issues I had with the Kontron Atom Z530 board is that, well, it's not upgradeable. The one I have, I built into the space of - a direct replacement isn't possible. There are other PicoITX form factor PC boards, but physically the envelope for PicoITX is rather large, and all require support electronics for bot-specific stuff.

Upgradeability just isn't something you find in bots - not without a good bit of custom work. No "standard" has been chosen for any bot I know of for the sake of controller upgrades. Most controllers are custom, to a specific bot, even. FITPC, not upgradeable. Even the board in the HR-OS5 isn't upgradeable. PC's are themselves a standard. With that, the smallest "standardized" PC module type I've found is COM Express Mini - and that's where I am. As I will be doing this work for who knows how long after I'm done with the bot build itself, other processor candidates are likely to show up, and if they're in COM Express Mini form factor and standard, then the upgrade is simply and unbolt, unplug old, plug in new, re-bolt, and just software load from there.

As for processing power, the whole focus of my project is ultimately software. The more power I have available, the more complex I can go with software configuration. Having a plugin for the SSD (single connector) means that I can swap out the SSD easily, and effectively change the bot's software completely rather quickly. And, this also makes the SSD's easy to remove and keep externally. I know some tether via WiFi to more powerful PCs, but I am going for a fully autonomous and independent bot.

Upgradeability-wise, having STM32's in hands and feet is a bit unique, for certain. The hand controllers serve another purpose, to control motion and generate PWM for the servos in addition to providing feedback from the MPU-9150's. Some would say the STM32's in the feet are overkill, and they may be, but at minimum, I plan to do bump detection in the feet with them. They're not particularly expensive - some up-front planning on the controller is all it really takes to provide a means to integrate them. And if I decide to do some kind of other sensors in hands and / or feet beyond the interfaces there now, it's not a big deal to modify the board design and build a few new ones.

Still, I sometimes ask myself if it is worth it, spending the time and money I have in hardware (electronics, CNC work, etc). I think it will be, but I've got a pretty long way to go to find that out. What I'm doing in all certainly isn't the "easy way". In the end, I'll have something that is pretty tough to copy (my goal isn't sales, though if there's interest, I may build and sell some boards), and will be a unique platform for my software efforts.

Thanks,
Paul

[PaulL]

TVP5151 Dev Board, designed, built, ordered. This will be used with the Cypress FX2LP to determine how I'm going to set up the connections between these chips and prove out the design, and will allow me to evaluate performance and to build the PC-side software for video capture. The TVP5151 offers a feature called "AVID Cropping" that will let me focus in on a portion of the image for even lower bandwidth. What I don't yet know is, is it worthwhile to integrate an FPGA for video processing before moving the data to the PC? I'll go ahead and order a Mojo board to play with.

Why do this, why do video capture of NTSC signal on the COMe carrier board? Space savings is the primary reason. I have a Hauppauge USB2Live board, and that is a nice board, but even though it is quite small, it's one more board, with additional wiring, to try to shoehorn in. The design is much more compact with only running 3 wires from a camera with NTSC out (Power, Gnd, Video) right to the COMe carrier board. I haven't found any USB webcams as small as the NTSC cam I have. On top of that, I really don't want HD video off the cam, as I intend to process the images as quickly as possible. Simply resizing a large image is heavy on a CPU.

[PaulL]

Got the TVP5151 dev board built. I've been pouring over the Cypress FX2LP documentation, and there's a lot to go through. Meanwhile, I haven't bought a Mojo (Xilinx Spartan 6 FPGA board) yet, but the more I think about it, the more likely it is that I'll end up with an FPGA. This will replace a few chips, and provide a lot of flexibility / capability. I've been asking myself - do I even need the STM32F4 if I have a nice FPGA? As I have no experience with FPGA's, there's a learning curve, one not to be taken lightly. Decisions, decisions...

[PaulL]

Wow, hadn't realized it's been a couple of months since I last updated this thread...

I've been working with the TVP5151 board, the chip isn't acting right - I'll have to do some more troubleshooting and maybe replace the chip. I've done some more work with the Cypress FX2LP USB dev board / chip, but before I go too far with that, I'm setting up the TVP5151 with an STM32 to get it talking over I2C - no success yet.

Also, I've been working on the COM Express carrier board design a bit more, and I think what I'm going to do is to slim the design down a little in order to build it all up to test the fundamental COMe stuff, then option-in the fancier stuff as I go. At the least, I'll have a physical example of the full stack up - carrier, COMe board, COMe heat sink (though I may do something more compact, ex, heat tubes, etc), board-to-board connectors, etc (which will be helpful in case I need to modify the torso design, which I expect will be necessary). I think it would be handy to have a more basic COM Express carrier to use for testing at this point.

I've done some more work on PC-side software, but that is an entirely different discussion.

[PaulL]

More months gone by...

Am I gone? Nope, still here, project still going. I've been working on software more than anything else.

I've been asking myself just what I need, what I should focus on, and if I've gone too far in any particular direction. The reality is that I may not have as much time in the future for this work, so I've stepped back to take a look with that in mind. Even if I do have the time, I think it's better to trim down the hardware design and get it all finished sooner than later.

The onboard video decoder is getting scrapped. It's experimental, and is based on NTSC video, which frankly, isn't exactly a "modern" standard. This also means that I am going to do away with the Cypress USB chip. Great chip, but more to learn and do than is really prudent for what I ultimately need. I'll stick with a complete off-the-shelf USB camera solution. Yes, video processing performance may not be as good, but the pros outweigh the cons, I think.

I am planning on going with the Xylinx FPGA chip. I think a COM Express carrier board with the STM32F427VIT6 and Xylinx FPGA will be a powerful combination.

With these changes, the chip count is reduced - no FX2LP, no TVP5151, no PCA9685 x 2 (also means PWM pins can become general purpose outputs), no discrete OR gate. Overall, that means adding the FPGA and removing 5 chips, so 4 fewer chips. Less complex design, more options for implementation. I may be able to put some (maybe all required?) connectors back onto the board (versus external dock), that would be a better as well.

If I can fit a DisplayPort video connector back onto the board, I may do away with the VGA chip, which means one less chip, but I'll have to route the DisplayPort signals to the back edge of the 4 layer board, which will make things more interesting. I could relocate the COM Express module, but that causes its own issues!

Of course, the design may change a bit as I rework the requirements - I'm trying to balance requirements and ease of implementation at this point.

What I'm doing software-wise is pretty complex, but that won't change.

Take Care,
Paul

[PaulL]

Long time, no post!! What's been going on with my project? I've moved into AI, though not in the typical sort of way. I'm trying something different in contrast to other AI efforts, work that has evolved from some of my past efforts. The work remaining in software is going to take some time, so I probably won't post much for a while.

As for the bot, I can't say for certain how far I'm going to continue with past efforts. Frankly, I haven't even thought about the mechatronics in a while, as I've been very much focused on the work at hand.

Make no mistake, I intend to drive a bot with the software I'm working on, I just don't know if or by how much my requirements will change by the time I get back to hardware.

For now, I can imagine:

* PC based bot, without a doubt. Probably will contine with the COM Express carrier board design, as more CPU is more CPU!!
* Biped, because I like Bipeds!

What could change??

I may end up foregoing the Hitec servos, which aside from some bracketry and bits, is about all that's left of the RN1 in my design up to this point. The main reason for this is that I think the design might be marginal on torque with the HSR-5498SG servos. It may be on the far edge of what works, but I don't know for certain yet. I'll likely end up building the COM Express carrier board, then a cage / torso for that, and see if the servos I have are still worthwhile. If not, I'll move to Dynamixel servos, and try to keep the design RN1-ish in appearance. If I abandon the Hitec servos for my target platform, I'll probably build out some command-and-control solutions for my RN1s and finish off a few bits and pieces.

My main bot-specific requirement right now is to stuff as much CPU into a biped as I can, without spending a fortune (though it still won't be what one might call cheap!). My goal is still to have a standalone bot, with no wireless tethering. I'm far less concerned with run time than with CPU performance, but I'd like to manage at least 7 minutes of run time per charge for a physically active operating state.

I think I've said it before, the point of the bot is to be a demonstration platform for my software.

[xevel]

Hey Paul!

Great to have some news, and to hear that you are making progress on the AI part. I'm still very curious about it

If and when you upgrade to Dynamixel servos, I would recommend you pay special attention to the communication aspect, as coming from a steup with PWM control, it can be the thing that gets you the most for a biped - because of the need for fast whole-robot control loop.
Communication with the servos is done on a serial bus, and it communication is done in a naive way (one after the other) with basic equipment (USB2Dynamixel from a PC), it could ruin the reactivity of the whole robot.

I depending on what type of gloabl control you want (open loop, closed loop with a simple algorithm, or closed loop with full IK and FK), the best solution could be different.

If you work in an open loop like most hobbyists out there, only sending commands to all servos at once, the simplest (hardware) and most versatile (software) is to use a USB dongle from your computer running the motion code and the sync_write command [writes values to many servos without checking] as fast as possible. The USB2AX has very slightly better perf there than the alternatives I know of.
This also works if you have a control loop that is not based on all the positions of all the servos like when you have use an IMU or other non-dynamixel sensors.

If you have a simple control loop based on data collected from the servos, then the approach of having a secondary controller talking to the servos and controlling them while following slower-rate high-level commands is the most efficient. This works if you have moderately complex interpolation computations too.

If however you have very computing instensive control that uses data from many servos (like an approach with full FK and control look comparing that to the model used to generate IK to give a much more complete proprioception to the robot), then the solution might shift back to having a computer do the computation. In this case (and that's the one I've been the most interested in since I started playing with robots), I would suggest using multiple interfaces that could both control and read back data from servos very fast, nad here is where the USB2AX shines the most (well if you're using Dxl 1.0 servos, as with the Dxl2.0 ones they made the original protocol much more efficient for this situation), with huge perf improvement compared to other USB solutions.

Obviously, if you have an RTOS running on a powerful SBC, then these are all moot, and you might, with an adapter board to handle the voltage conversion and half-duplex nature of the bus, get even better perf. I haven't tried this, so far I always stayed within the real of non-RTOS linux and just tried to squeeze the most out of it...

Anyway, have fun!

[PaulL]

Hey Xevel,

Thanks for the info!! I'll probably end up doing a lot of control PC-side, and I may do closed loop control, haven't made up my mind yet. I'm even on the fence about using an STM32 for low level control (was what I originally intended), but it all depends on how things start shaping up performance-wise. I've fiddled with a chip, a CP2103 USB to UART interface, and have managed 960k through it, not sure how that compares to the Dynamixel bus - I think I read somewhere 1.5 M bps serial? I forget.

Take Care,
Paul