Roboard Experience...

[PaulL]

Sound Card Efforts:

I've been going through the Cirrus Logic CS4281 Reference Design PDF, and have pruned out about 90% of what I don't need (MIDI / Joystick, unneeded inputs, etc). I am now going through the parts list piece by piece and identifying suitable replacement parts for those that are unavailable or can not be ordered in small volumes.

My initial schematic was based on the CS4281 and CS4297 Datasheets, but the Reference Design is much more thorough. Once I'm done trimming the design and spec'ing parts and have selected a suitable 1 to 2 watt amplifier, I'll transpose the schematic to Eagle PCB and get the boards done. I've had a change of thought, to get a prototype done by GoldPhoenix. They seem to have pretty good prices. Sunstone seems better for volume, GoldPhoenix for prototypes.

Hand Efforts:

A good while back, I ordered 2 serial Pololu servo controllers, mostly based on size. I have since ordered a couple of Pololu Micro Maestros. They are quite impressive so far. I have some testing to do regarding position updates. The Maestros are capable of internal scripting for moves. This offloads some CPU effort, but this also breaks my universal servo approach. I bought the USB-connectable Maestros out of concern for throughput for servo position updates. I will test / compare the two head-to-head and see which works out best for my application, if there's any appreciable difference. Even in TTL mode, the Maestro can do 115200, whereas the serial-only board is 9600.

The biggest problem with the Maestro versus their earlier version serial board is that the Maestro is larger, and thicker due to the mini USB port. I will need to take this into account, and adjust the hand bracket design if the Maestro proves to be better. Either way, the Maestro is a pretty nice servo controller.

I also scored another RN-1, waiting for it to arrive. At this point, I have a blue one w/ HSR-5498SG's, a gold one that is mostly stock, and the new one will be all stock. I will end up getting at least 1 more RB-100 in the near future, maybe 2 for the robots alone. I have been trying to find colored bracket sets, but they seem to be very hard to find lately.

The sound card has to get done, period. I can't do what I want with Roboard's USB sound, and no other solution is available.

The hands have to get done, as it's one of the coolest things I can do for my bots.

Take Care,
Paul

[PaulL]

I have bought a load of parts and another full RN-1, so my lineup is going to be:

RN-2:
HSR-5498SG's
Roboard RB-100
Blue Bracket Set

RN-2:
HSR-5498SG's
Roboard RB-100 (need to purchase)
Red Bracket Set

RN-1.1 (Hitec Hand Kit):
HSR-8498HB's
MRC-3024 at first, then maybe Roboard RB-100 (need to purchase)
Stock Orange Brackets
Hitec Orange Hands

RN-1 (fully stock "reference model"):
HSR-8498HB's
MRC-3024
Stock Orange Brackets

I'll put sound cards in the RB-100's, and 5-fingered hands on the RN-2's.

I really want a weekend where I'm NOT working! Ugh!

Take Care,
Paul

[PaulL]

I've been working on the Bill of Materials and fiddling with Eagle. I took a good hard look at the Mini PCI device I downloaded from Cadsoft's site in conjunction with the mini pci form factor specs, along with a dial caliper and my Volari video card. Well, not only was the edge connector fouled, but the dimensions are wrong and will not work. I built a new component for the Mini PCI form factor, one that is more correct. I've already had to build components for the sound chips, but at least the packages were able to be copied from elsewhere!

I'll chalk all this up to the ails of working with obsoleted hardware.

Laying out the card form factor was a pretty tedios exercise, but it had to be done. The card is almost right, just clearance issues with pads on the card edge and the ground pads by the notches in the sides (the Sunstone DRC file doesn't like the clearance). I'll fiddle some more and make the DRC file happy, then I need to transpose the schematic from the reference design.

Here is a bit of what I have, using a test schematic (not enough filter caps, part positioning has to be tuned up, PCI_CLK line needs to be lengthened, etc). Mostly, I ran this one just to see if what I have for the Mini PCI card so far would behave properly in an actual design. Not bad.

Take Care,
Paul

http://robosavvy.com/Builders/RN1AsOf091407/PCIBoardR1.JPG

[PaulL]

Another update, starting to take shape! The components outside of the board are all associated with a TPA2000D2 Class D amplifier. I had them inside the board area to see how things would work (everything physically fits, but routing is another issue), but moved them out to optimize the layout (just getting started on that aspect).

Chips:

CS4281-CM: Audio Accelerator
CS4297A-JQ: AC'97 Codec
TPA2000D2: 2 Watt Class D Stereo Audio Amplifier
MC1458DT: Line Out / Headphone Out Amp
24LC00: EEPROM for sound chips (not needed, may remove)
MC30078D: Microphone Preamp

I/O:

Unregulated Power Input (+V / Gnd, regulated to power amp and audio)
Mic Input (x 1, optional Bias power for condenser microphones)
Line Out / Headphone Out (L / R)
Line In (L / R)
Speaker Out (L / R)

From here, I need to add some Mini PCI slot-related caps and such, rearrange and reorganize components, do some manual trace routing (PCICLK has to be 25.4 mm, +/- 2.5mm for timing), add analog and digital ground planes, re-verify everything a few more times, and buff and polish until I'm satisfied.

You can also see the bottom of the card, this was my fix to work w/ clearance issues (manuf specs) at the card edge. I figure I can edge-sand until the edge is flush with the "stops" (notches left and right at the bottom), then sand a bit of a "v" for better slot insertions.

DRC is fine with all components physically on the board, except for the audio amp w/ the vias and ground plane in the middle, DRC says that there's overlap. Going to fiddle with that, see if there's another way I can do the same thing as what was done in the TI library.

Parts add up fast, but I'm not building this for economy. I could have used a few cheaper parts, but I could also have made more expensive choices.

Tedious work, but it is coming along...

Hey Roboard - If you read this thread, can you tell me if I need to worry about a few unused 3.3v / GND connections towards the middle of the mPCI slot on an RB-100 / RB-110? Also, I believe there is no power management support on Roboard, so the mPCI slot doesn't mess with the PM pins either, right? Are there any non-standard things about the Roboard's mPCI slot I should know about? I know it doesn't use the modem/AC97/LAN/audio connections, anything else?

Take Care,
Paul

http://robosavvy.com/Builders/RN1AsOf091407/PCIBoardR2.JPG

[roboard]

Hi, Paul,

that 3.3V/GND pins are for 3.3V power supply and you don't need to connect them if you need no 3.3 power supply.

The miniPCI of RoBoard only employs the standard PCI interface, and non-PCI standard interfaces are unused. PM pins are also unused.

[PaulL]

Hey Roboard,

Thanks for the reply!

I intend to use the most physically convenient +3.3v and GND pins (tough to route the signals tight on 2 layers), but wanted to check with you regarding noise / etc on unused pins.

That's good news on the rest of the pins, less connections to the Mini PCI card edge!

Thanks!
Paul

[PaulL]

What have I been up to? I've been working on the sound card design. I had gone so far as to include an audio amp and circuitry for generating a panning signal for stereo microphones so I could turn his head towards the loudest noise source. I pulled out the CS4281-based sound card (this full sized PCI card uses the same chips I bought off ebay), and noticed a LOT less circuitry. I hadn't looked at that card in quite some time. It ONLY uses the CS4281-CM audio controller and the CS4297A codec chip. No op amps for microphone input, no headphone amp, no external EEPROM, etc.

After reviewing the full-sized PCI board, I rethought the design. While having the sound card incorporate all the features I want directly would be nice, the configuration needed for the Mini PCI PCB (thickness, gold plating, etc) will be about 3 times the cost of a "standard" board.

I decided to focus ONLY on sound card-specific aspects for the mini PCI card. I can add a more experimental daughter board in a standard type PCB for the application-specific features I want. This means less risk in problems in the first run for the mini PCI sound card, and the ability to do whatever I want with less cost risk for the daughter board, and more area to work with on the daughter board as well.

The daughter board will have the audio amplifier, two microphone inputs with analog volume level outputs (to be read by the Roboard's ADC - will try doing this in software to see if this is necessary), a mixer for 2 microphone inputs to produce 1 microphone output for the sound card, digitally controlled DC-to-DC converters for power management, and shutdown circuitry for Roboard w/ the "shutdown" BIOS update.

Other sensors and such will be located in various other places on the 'bot (accelerometer, gyro, etc).

This approach means I have removed MUCH circuitry from the board, and has eliminated the problem of board space I was starting to have. I'll probably just use pin headers to mount and wire to the daughter board.

I had been following the CS4281 reference design which included more hardware than is actually necessary. The Cirrus Logic guys simply overdesigned the reference design.

This means that the sound card is much closer to completion, and with a simpler design.

There is only 1 issue remaining, and that is the issue surrounding the mystical VDD5REF signal on the CS4281-CM. This is referred to as the "pseudo supply for the PCI bus drivers", and "For a 5 Volt PCI Bus, VDD5REF must be connected to +5 Volts.", but what about a 3.3V bus? There is no documentation or literature regarding usage on a 3.3v PCI bus, such as Mini PCI. However, the chip itself is 3.3v, and I've seen designs that claim 3.3v / 5v compatibility with this chipset. The question left is simply "how?". I will probably have some pads to try gnd or 3.3v, etc.

I hadn't actually tested this particular chipset on my IM380A PCI to Mini PCI adapter until recently. At first test, Windows XP recognized the card, but gave it a code 10 error in device manager. The guys at Interface Masters were kind enough to provide me with schematics for the IM380 so I could make sure I wouldn't fry anything, and I added 12v. This CS4281-based PCI card gets analog V+ power for the CS4297A codec from +12v on the slot, through a 78L05 regulator. This voltage is supposedly just for the analog circuitry in the chip, but apparently somehow this causes a code 10 in device manager if not powered. Regardless, it is tested and working in full duplex w/ text-to-speech and voice recognition, with better performance than onboard USB sound (as expected, PCI bandwidth is much higher!).

I'm getting close to placing the order for the board!!! There are probably a few full days worth of work left, but this has to be shoe-horned in amidst the other things in life - job, family, etc.

Take Care,
Paul

[PaulL]

As we have a holiday weekend in the U.S., I have THREE DAYS to work on the sound card!!! I'm going to push hard and try to get that done amidst the typical homeowner tasks for such a weekend.

The other day, I ordered a hot air reflow workstation from Sparkfun (HR906). I'm pretty adept at soldering (my first job some 15 years ago involved building thousands of boards, so I even have some "real world" experience.. We were even hand-soldering SMD boards back then, too!), so getting used to the hot air tool shouldn't be too hard. I'm going to practice on some PCI sound cards, removing and replacing the codec and controller chips on those.

Regarding soldering - I have a 25 watt iron I bought when I was 15 or so. I bought it from Radio Shack, cost about $25 USD back then. I have put significant time on it over some 20+ years, and I've never had to replace the tip. How is that even possible? I have a method: I ALWAYS wet the tip with a blob of fresh solder when I put it back in the holder (for some reason, I've never seen this advice elsewhere!). I keep my sponge damp (same sponge!!!), and wipe off the solder as I pull the iron from the stand, and apply a bit of fresh solder before I use it. I wipe it again and apply fresh solder before putting it back in the holder. The element has never been replaced, either. It's always been around for me whenever I need it. It does have a big wedge tip, so that does help. I used fine (1/32" wide) tips on a Weller iron at work years ago, and the tips eventually ended up fouled no matter what we did.

Conversely, I have an old 135 watt soldering gun I use for 12 gauge wiring and RC battery packs, and it has seen probably a half dozen tips in the same amount of time. The copper wire-stype tips break down over time.

As for solder, I have organic core (water solluble flux) and rosin core, no less than 7 years old on both rolls (started out as 1 lb rolls). These are very thin, as thin as I could get at the time. I also have a 1 lb roll of thicker rosin-core solder that is 10+ years old and almost gone that I use on heavy jobs like thick wiring and batteries.

Old solder, old irons, and I can still do tight-pitch work with no problems (like soldering to Digitrax DCC decoder terminals when wiring from the motor back to the board for boiler installs on n-scale steam engines - another hobby of mine).

I seldom use solder wick or any solder removal tools in my usual work - solder is heavy, and a little gravity and flux will allow the solder to flow back on to the tip - "gravity desoldering" if you will.

Sometimes I use a wire leg from a resistor to draw solder out of through-holes. Sometimes I use an x-acto blade to act as a dam to separate molten solder from adjacent pads (solder doesn't regularly adhere to the X-acto blade).

Once when I was a teenager, I had some LARGE (something like 10 x 14 inches) boards with MANY 74?xx series logic chips on them. I went out in the back yard with pliers and a blowtorch, heated the back of the board, and gently pulled the chips. I still have several hundred various TTL chips I reclaimed from these boards. Whenever I've needed a 7404 74LS245 or whatever, I've never had any problems with them being fried!

All that said, with the new hot air rework station, I added a flux pen, 50g of solder paste, 25' of solder wick, and a replacement heating element. I've been checking out the Sparkfun SMD soldering videos, and can see that I may need wick to do SMD work.

I'll probably end up getting a paste stencil (from Pololu or elsewhere) and try the "frying pan" reflow method if I end up making a number of these sound cards.

So, hopefully, without much interruption, I will be able to have a set of gerber files for GoldPhoenix by the end of the weekend.

Take Care,
Paul

[PaulL]

I edited the board screen shot posts above to be URL instead of inline IMG, the graphics were too wide and made things hard to read.

An update!!! It's been a while, eh? I am still steadily working on my project in one way or another, though!

I've been mainly working on my sequencer engine (the core framework for my robotic control system). I've done a number of major overhauls as the picture comes into clearer focus. I've also been keeping in mind my future interests in AI with these overhauls, and have introduced some interesting "features" recently, including the ability to nest the sequencer engine with itself, and the ability to add / edit / modify sequences at run time (so I can do things like modify the system via voice interface). These will give me some required capabilities for my approach to AI, as well as provide some helpful tools along the way (not a bad thing, two birds, one stone).

Today, I've been reworking my Roboard class, which includes servo motion code, register code, everything that is Roboard-specific. I did some major refactoring (moving things around) earlier, and am about to resume from a break to clear my head.

I have to say, from a programming standpoint, the approaches I'm using are worthy of a book. But, that can wait. Let me just say, most (not all!) of the "standardized" methodologies out there have been tossed into the wind to make way for some really useful stuff.

This code base I've been working on has seen more changes than any code I've written in my day job, and at times, it has shown more wear and tear from revisions than anything else I've ever written. That said, it is also emerging into one of my finest works. I've gone through rewrites that add layers and layers of objects, then I've reworked the code to boil it down to much simpler mechanisms. Repeating this process over and over has resulted in what is to me, a lean and simple approach like nothing else I've ever done. I've tried and tested things, I've examined performance of varying libraries and approaches, and a few things keep coming back into focus as the right ways to do this kind of work.

It's coming along! May only be a few more years to go.. LOL!

Take Care,
Paul

[PaulL]

An update...

(removed overly grandiose verbiage )

I've been coding, sure, but I also worked on the hand design a bit this last weekend. I had a bit of a "duh" moment. I was going to use the case screws on the bottom of the MKS DS-450's to secure the servos to the hand base plate, but realistically, there isn't much thread and the screws are tiny.

I was planning on countersinking the screw holes to leave some bite for the screws in the servo case, but there wasn't much room to play with anyway. Instead, I'll skip drilling and countersinking 20 holes in the base plate, and do servo tape for mounting the servos.

And, instead of machining a servo horn hub and tendon strip as one piece of teflon, I'll machine a sleeve / hub for the horn, cut some strips of teflon from .020 inch sheet stock, and thread and screw the strip to the hub. The bracket design got a bit more simple, too.

I'll probably buy Vectric's Cut2D (DXF to G-code for my mill), as I fiddled with it more this past weekend, and I think it's a pretty good piece of software. Cheaper to buy that than to spend time manually generating G-code or building my own tool (which would take me away from my dev focus). The tab feature alone is worth it!

The sound card design is on hold for now, I can do proof of concept w/ the IM380A adapter and full-sized PCI card. Using a custom mPCI audio card or the adapter and full-sized PCI card makes no difference to my code, so I'm not worrying about it for now. Clearly, at some point, I'll get back to it. The design is basically done, but I found myself over-designing, another good reason to step away from it for now. When I've got things proven out, I'll finalize the board work and send it off. I don't see it as a money maker - the interest in such a product is very limited, and heck, the parts are obsolete.

Regarding the hand design - it seems MKS bumped up their prices a while back, the servos seem to be no less than $31.00 USD now, meaning $300.00 USD for servos alone for one pair of hands. Luckily, I bought 11 of them at around $25 / each a while back, but ultimately I want to have at least 2 pair for 2 bots. Why am I so stuck on using these servos? Size, torque, and metal gears!

I'm still trying to work out a few hardware aspects. The hip rotation design should be fine, still need to cut up some Nylatron and see what the friction is like (simplifies the design). I will probably use the same design for wrist rotation as for hips, but the problem there lies in what servo to use to rotate the hands. The DS-450's in the fingers aren't a problem, individually they don't need much torque.

It's tough to fit a wrist rotation servo in without affecting range of motion. Using a micro servo for wrist rotation would be minimally intrusive, but the wrists need to be fairly strong if I'm going to have him do push ups or cartwheels or push up from a fall and so on. If I go with a full-sized servo, it will be bulky and weigh more. Still not sure what to do with this.

And yet another concern is in the neck motion. I WANT head tilt (2 axis) and rotation (a 3rd axis), but getting a mechanism in there without jacking his head up, one that will withstand headstands and one that I can run wires through, will not be easy. I can draw up a design (and I have a few), but manufacturability is a problem. Clearly, the servos will have to be micros, and will have to be remote located - pushrods, guided wires, in all, no easy answer here yet.

The hands are a big deal for me, as they'll convey expressiveness that I won't be able to convey otherwise. The neck motion will also help, but who knows, I may have to stick with just rotation (and maybe some limited range of motion in his neck will keep him a bit more "robotic", who knows). Hips should be OK, but wrists may end up getting full-sized servos slung off the back side of his arms.

He'll be heavy, which is another reason I went with a bunch of HSR-5498SG's (and yes, I have enough for 2 bots, hip rotation servos included). And run-time? I have no idea at this point. Maybe I'll have to shop for batts again, see if I can somehow shoehorn more amp-hours into his battery compartment. Advanced power management is definitely an "in the future" goal. The shorter the run time, the more quickly I will push to improve power use.

I've thought of some demo videos, picturing two (red and blue, already bought the bracket sets) talking amongst themselves about their technology. I am thinking of taking the silver bracket set and weathering it w/ airbrush / etc, make that one (w/ stock setup) look worn and aged beyond his years, and have the tougher two interact with him (his name will be Rusty - LOL!). Lots of potential.

Take Care,
Paul

[PaulL]

A short update.

I have had some health issues this year, but I'm getting back into my project again. I had an unresolved issue in the scripting engine, one I managed to solve this past weekend - the issue revolved around storage of datatypes in a non-type-specific way while avoiding boxing / unboxing issues in .Net. The scripting engine has nothing left to be "figured out", so what's left is implementation (I just need to sit down and put a few weeks of effort into it). Beyond this, I can get back into my motion control engine (I ran into an issue regarding generic control of varying specific devices - servo hardware interfaces, this is no longer an issue as of this past weekend).

Regarding servo control and motion sequencing / scripting, my goal is to build a non-hardware-specific motion control engine capable of using any hardware that a servo "driver" (poor word choice, it's not a true driver, more of an abstraction layer within .Net or a .Net wrapped, unmanaged C++ lib) can be written for.

Since the last update to this thread, I bought Vectric Cut2D, and it works well enough. Since the last "hands" thread update, I've done another version of brackets, a tweak to get some dimensions right and relocate the controller to the back side of the hand. It was going to be too tight a fit to put it among the servos. I've also settled on 6061 for any metal going into my bot, and ordered and received more 6061 sheet. I've started on the hip rotation servo mount brackets, and am reworking the hip rotation bearing a bit. I'm going to try to get away with teflon sheet (.025 inches) as a thrust bearing, will see how that goes.

I'm pretty well set on using the pulley design for hip and wrist rotation, with full-sized HSR-5498SG or HSR-8498HB servos (depending if I have enough HSR-5498SG, can't recall how many I bought at the moment). The test pulleys I have should be plenty strong even with significant tension on the fine cable (25 pounds breaking strength, tension needed should be a good bit less than that). It's trial and error, though - I won't know how the pulleys work out until I try them. I could use a pushrod, but no 180 degrees rotation. I could use gears, but the backlash would be a huge concern. The fine stranded cable will be fixed to the pulley using the servo hub mounting screws - the result is very strong. But, what I can't easily tell is how much "spring" these cables will have under the tension needed to rotate wrists / hips. If it's too much, I may end up trying to use a toothed belt instead of cable.

[redfeilds18]

i am having few problems...
does anybody have the same experience like this http://robosavvy.com/forum/viewtopic.php?t=6975

please help me out if you know what to do!

[PaulL]

... Yes, I have motion working, that's all well and good. I've worked with the speech / voice recognition and it seems I will not be able to do TTS / voice rec simultaneously on Roboard. Even using an off-board PCI sound card via MiniPCI to PCI adapter (better than internal USB for CPU load), the processing still spikes. Either the servos stutter for a split second, or the speech / voice rec drops out. There just isn't quite enough CPU in Roboard to do it the way I'm trying to do it.

One possible next step is to put the servo motion off-board, much as computers use separate microcontrollers / processors to handle tedious things best done in hardware (GPU's, HDD controllers, etc, etc). In this case, I'd command a move from the onboard PC, then the outboard hardware would execute the motion.

To that end, I bought a bunch of parts from Sparkfun, including some misc parts for fun: .96" OLED, Arduino Pro Micro 5v, 6 DOF Accel / Gyro, BlinkM, I2C Level Converter, 2 x Class D Audio Amp, a couple Pololu digital switches (Roboard auto shutdown testing), etc.

I have the Arduino working the BlinkM and 6 DOF board very nicely. I didn't know much about Arduino until I got this board this past Fri. Come to find out, it's got a servo lib, too. SO, if I can fit my motion stuff into the Arduino, I can free up the PC board for its proper role, supervisory control (And TTS / Voice Rec!). Doing servo motion via USB also opens up my bot to being able to put in an even faster board on my bot. I'll need two, maybe 3 of these tiny Arduino boards for motion control.

I can do TTS / voice rec with my bot, as long as I'm not doing motion at the same time. Might post a vid of that after I get the audio amplifiers installed. But, that's not what I want, so I'll be working on putting my move code into an Arduino.

Take Care,
Paul

[PaulL]

I've been playing with the Arduino Pro Micro (Arduino Leonardo, but smaller), and have my motion calculations ported and generating proper values over time. The results are below. Next step is to set up handling for initiating moves and responding when complete.

I want to be able to start a group of servos while others are in motion, responding to Roboard when the move can't be started due to servos in use. I also want to be able to interrupt servo motion when needed. The Arduino will also signal Roboard when a move is complete. There's a bit of handling to do for serial, but it should work.

I'm essentially splitting the motion controller code I have in Roboard, putting the actual motion work on Arduino while Roboard handles orchestration of moves. This is intended to correct the dependency on available CPU on Roboard for motion so I can do Speech / Voice Rec on Roboard while in motion.

There's more to do, like I2C between two or more of these boards to handle more servos (using I2C between Arduinos, I can have up to 10 servos on a Pro Micro at a time). I won't know if this is too much for the Arduino until I try, but I'm guessing it should be OK.

The main constraint is - can this little Arduino process my motion calcs fast enough to do updates for 10 servos at <= 4mS while handling I2C and serial commands / responses? I hope so.

[PaulL]

I have a bit of a communication protocol with a host computer working, along with 10 servo position updates using motion calcs concurrently. I can move different groups of servos at different times, etc. Move completion is reported back to the host PC. Serial data does not interrupt motion at all (using serial via USB on ATMEGA 32U4).

By "sort of", I mean that the Servo lib for Arduino isn't perfect. Every so often, rotation starts with a negative "bump" in position. I think this has to do with changing position values at the low end of the PWM range frequently during the gradual start of acceleration. I can't say exactly why, I need to have a closer look at the ISR in the Servo lib.

But, it's more or less working. The next big "test" is to run one side of my RN-1 off Roboard's PWM and the other off the Arduino performing the same motions "side by side". This will be a really good test. It'll also prove how significant latency resulting from the serial connection to the Arduino board will be.

For some reason, the bench tests for servo motion just don't seem as smooth from the Arduino as on Roboard's PWM. I'll know for sure when I try it on the 'bot. One thing's for sure: The Hitec servo resolution sucks (about 256 for 0 to 180 degrees, about 8 bits). Future project: Robonova form using Robotis servos (RN3?).

And btw, a link about interpolation and calcs and such (would've been handy if I had found this a while back):http://sol.gfxile.net/interpolation/index.html