RoboSavvy Forum Robosavvy Forum: The largest online community of Humanoid Robot Builders 2013-01-02T09:33:44+01:00 http://forum.robosavvy.com/feed.php?f=17&t=5306 2013-01-02T09:33:44+01:00 2013-01-02T09:33:44+01:00 http://forum.robosavvy.com/viewtopic.php?t=5306&p=36851#p36851 <![CDATA[Roboard Experience...]]> http://www.visualmicro.com. It's a plugin that lets you do Arduino code in the Visual Studio IDE.

As Arduino isn't perfectly compatible with Maple, some changes will be needed, but I much prefer the VS IDE.

I've been slowly working on the method and code to use Maple Mini's for servo control - it's getting there. Work came first, past few months were pretty hectic.

I'm sold on the main board I'm going to use: Kontron's PicoITX based on an Intel Atom Z530, the 1.6 Ghz Standard (not the Plus, that has an IDE connector projecting off the side). It's a tad too wide, but I think I can make it work. If I had a bigger bot, it would be less of an issue, but I don't know if I'd have ended up with a different solution... Maybe FitPC2, maybe not. :)

I looked into other boards, some with faster CPU's and such, but this remains the winner.

Statistics: Posted by PaulL — Wed Jan 02, 2013 9:33 am

]]> 2012-10-15T00:35:44+01:00 2012-10-15T00:35:44+01:00 http://forum.robosavvy.com/viewtopic.php?t=5306&p=35708#p35708 <![CDATA[Roboard Experience...]]> I've been keeping this thread up mostly out of personal commitment, but it's nice to know someone is reading... :)

I've been giving some thought to your post, about kinematics processing and how it fits into the scheme of things.

Compromise, optimization, now we're just playing with words. :)

What this approach does is move high bandwidth / CPU motions off the Roboard (keeps Roboard from handling interpolation), but it doesn't deny the ability to stream motions for use with inverse kinematics / sensor feedback-controlled motions / etc.

It also offers some benefit turning something like an STM32 into a PWM interface. Then, any serial / USB / etc host can plug right in (I'm thinking Atom Z530). As there is no "standard" for servo controllers out there, I figured I'd try a different piece of hardware and method.

If the intent of inverse kinematics is a point in 3D space, this approach can facilitate this. Regarding kinematics, how fine a resolution is intended for a particular instance? Depending on the precision required, this approach could "fill in the gaps" between points, not necessarily a bad thing.

I think active inverse kinematics is overkill for taking a stroll around the house on a "large footed" bot, but this is my opinion. But, a sensor input saying "you're about to lose your balance" can interrupt and offset those rudimentary motions - not outside the capabilities of the STM32.

What we're really talking about is CPU load and priority of complex functions. If the intent is to experiment in the realm of kinematics, sure, you can do that on the RB-100 or other, and use the onboard PWM right on top of the Vortex86DX in whatever language makes you happy. If TTS and Voice Rec is needed, that's a good chunk of CPU (esp on Roboard), and doesn't quite leave enough room for motion to play without some sacrifice (ex, TTS / Voice Rec when standing still, off while moving).

This offboard control gives me options, and it doesn't quite take any away - I think that's a good thing. If I want to fiddle with kinematics and swamp the CPU, I can, and when I want to walk and talk, I can. This aspect of choice is what I think is key here. The heavy hitters are vision, kinematics, TTS / voice rec, and AI. Today, it's simply not possible to do all on the same small bot concurrently.

In people, there is a kind of "mode switch" regarding focus. If we're performing a delicate or unique motion, we focus, and we sometimes don't even talk while we're concentrating. This is possible with an offboard controller that can accept streamed position updates and does kinematics host-side. At the same time, many motions we make don't require concentration, and the same offboard controller can do the interpolation for similar types of motions, even using sensor feedback (gyro, accelerometer). There are other situations such as where we may be walking, but holding a glass of water, perhaps we can talk, perhaps we can't if the water is very near the rim of the glass. This controller approach supports this as well (interpolations + discrete position updates).

I agree regarding the complexity of kinematics / inverse kinematics. For the same reason GPU's exist, the same logically will eventually be true for kinematics (but practically will this be of benefit to semiconductor manufacturers? Maybe as an unintended application of gate arrays and the like).

I agree about the STM32, it's a very slick little processor. The 32U4 isn't bad, but the STM32 is a good bit better. I don't need all that GPIO, but what I really want is a pretty specialized board. For now, I'll just use the Maple Mini as-is. Waiting on Sparkfun to get them back in stock, I need a couple more.

Paul

Statistics: Posted by PaulL — Mon Oct 15, 2012 12:35 am

]]> 2012-10-08T11:50:54+01:00 2012-10-08T11:50:54+01:00 http://forum.robosavvy.com/viewtopic.php?t=5306&p=35633#p35633 <![CDATA[Roboard Experience...]]> Robotis have moved away from having the motion engine in the subcontroller on DARwin to having it on the FitPC, so it can better implement kinematics to work in different space frames. Developers want to use Python, LUA or Matlab to develop their motion algorithms, not work on an embedded device.
As algorithms mature, I assume there will be a partioning and delegation of parts of the motion engine, but I would expect it to demand performance similar to graphics processors and significant bus bandwidth as the number of degrees of freedom increase and the sensory feedback grows.

But I can see it is a necessity in your case and the Maple and STM32 are great devices.

Statistics: Posted by i-Bot — Mon Oct 08, 2012 11:50 am

]]> 2012-10-07T05:03:20+01:00 2012-10-07T05:03:20+01:00 http://forum.robosavvy.com/viewtopic.php?t=5306&p=35618#p35618 <![CDATA[Roboard Experience...]]>
Awesome would be a smaller board with serial, I2C, and PWM broken out, USB available for programming, available without mounted headers.

Large quantities of GPIO really doesn't provide much benefit for 'bot controllers...

Pins for a "wish" Maple Mini Modified (STM32F103CBT6):

12 x PWM pins (and associated re-taskable purposes)
2 x Power pins (+V to regulator to chip / Gnd)
2 x Serial / I2C pins (tx3 / rx3 / I2C2)

That's a 16 pin device, with USB jack mounted on top, perfect for hardware interfacing to a PC. Other boards can be slaved to a main board that interfaces with the PC, expanding PWM as needed.

A few words about control systems / embedded concepts:

In the course of time, computers have grown from single-chip processors that do everything from video to bit-banged serial, to hybrid devices that today incorporate a central processor with purpose-specific processors attached to it that handle tedious and application-specific tasks (GPU's, drive controllers, hardware UART's etc). I believe this fundamental aspect of computer evolution has its place in hobby robotics: there is no reason to limit oneself to a single processor to do motion AND everything else.

I see an outboard motion controller as being no different from and analogous to a controller one can find in a printer. The main PC doesn't control nozzles in an inkjet printer, nor does it control the position of the print head, nor the stepper motor that advances the paper. Instead, the PC tells the printer what to do in macro terms (ex, print a line with these dots of xyz color). The printer's embedded controller ultimately handles the tedious task of printing, allowing the computer to carry on with anything else it is tasked to handle.

Why shouldn't hobby robotics take on a similar form? It makes sense to leave motion control up to a dedicated motion controller, but must that same controller run every other aspect of the 'bot at the same time? My thinking is, no. Now, all I need is my dream board. Meanwhile, the Maple Mini is VERY close. :)

Statistics: Posted by PaulL — Sun Oct 07, 2012 5:03 am

]]> 2012-09-23T00:46:12+01:00 2012-09-23T00:46:12+01:00 http://forum.robosavvy.com/viewtopic.php?t=5306&p=35487#p35487 <![CDATA[Roboard Experience...]]>
SO, I got a Maple Mini, which has 12 channels of hardware PWM - this should be exactly what I need to resolve the issues I'm having with PWM on the 32U4, and the board is so freakin' fast that it should do just about anything else offboard that I want. And, with 2 of these, that's 24 channels of PWM, meaning 20 for stock + hips + wrists with 4 left, and the most I can do for neck is 3 (fwd / back tilt, side / side tilt, rotation).

I still don't know what I'm going to do about hand controllers short of designing up some purpose-specific ARM Cortex 3 boards like the Maple Mini. I've fiddled with the Pololu Maestro board, and I just don't like the accel / decel on it. With the Maple Mini, I may be able to stream position updates to the Pololu boards fast enough to suit what I'm trying to do. I have my doubts if the 32U4 could handle that and servos.

In retrospect, it's ironic that for two Maple Mini's, the cost is around $70 USD from Sparkfun, whereas the MRC-3024 was some $300 USD at some point in the past.

For connecting the two Maple Mini's, I'm thinking of using I2C, and simply maintain timers in the I2C Master for move completion on the second board - this keeps me from polling the second board, or trying to work out some multi-master method between the two boards. Response time / latency for move completion will be better with this approach as well. Not sure what the hardware serial speed is on the Maple Mini, I need to look into that.

***

I keep debating on what to do, whether I want to just slap the audio boards and speakers on the gold RN-1 w/ Roboard and do a video demonstrating Speech / Voice Rec between moves, or keep going on offboard servo motion control so I can get to walking and talking at the same time.

At the moment, my long term goal is winning out, to get motion control offboard so he can talk while moving.

A side note, has anyone here done much with visimes? Visual cues for speech? I'm thinking of doing some head-nod / tilt, maybe some peculiar sideways head ticks or jerky rotations on certain types of sounds to add character... :)

Statistics: Posted by PaulL — Sun Sep 23, 2012 12:46 am

]]> 2012-09-11T07:57:23+01:00 2012-09-11T07:57:23+01:00 http://forum.robosavvy.com/viewtopic.php?t=5306&p=35356#p35356 <![CDATA[Success with Arduino, sort of...]]>
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

Statistics: Posted by PaulL — Tue Sep 11, 2012 7:57 am

]]> 2012-08-26T23:11:51+01:00 2012-08-26T23:11:51+01:00 http://forum.robosavvy.com/viewtopic.php?t=5306&p=35236#p35236 <![CDATA[Roboard Experience...]]>
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. :)

Image

Statistics: Posted by PaulL — Sun Aug 26, 2012 11:11 pm

]]> 2012-08-23T11:53:40+01:00 2012-08-23T11:53:40+01:00 http://forum.robosavvy.com/viewtopic.php?t=5306&p=35210#p35210 <![CDATA[Another Update...]]>
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

Statistics: Posted by PaulL — Thu Aug 23, 2012 11:53 am

]]> 2012-07-31T18:41:52+01:00 2012-07-31T18:41:52+01:00 http://forum.robosavvy.com/viewtopic.php?t=5306&p=35000#p35000 <![CDATA[Roboard Experience...]]> 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!

Statistics: Posted by redfeilds18 — Tue Jul 31, 2012 6:41 pm

]]> 2012-06-19T01:40:26+01:00 2012-06-19T01:40:26+01:00 http://forum.robosavvy.com/viewtopic.php?t=5306&p=34614#p34614 <![CDATA[Roboard Experience...]]>

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.

Statistics: Posted by PaulL — Tue Jun 19, 2012 1:40 am

]]> 2012-06-19T01:52:39+01:00 2011-11-10T10:15:22+01:00 http://forum.robosavvy.com/viewtopic.php?t=5306&p=32788#p32788 <![CDATA[Roboard Experience...]]>
(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

Statistics: Posted by PaulL — Thu Nov 10, 2011 10:15 am

]]> 2011-09-05T00:10:48+01:00 2011-09-05T00:10:48+01:00 http://forum.robosavvy.com/viewtopic.php?t=5306&p=32195#p32195 <![CDATA[Roboard Experience...]]>

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

Statistics: Posted by PaulL — Mon Sep 05, 2011 12:10 am

]]> 2011-07-02T13:39:58+01:00 2011-07-02T13:39:58+01:00 http://forum.robosavvy.com/viewtopic.php?t=5306&p=31644#p31644 <![CDATA[Roboard Experience...]]>

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

Statistics: Posted by PaulL — Sat Jul 02, 2011 1:39 pm

]]> 2011-06-24T10:29:14+01:00 2011-06-24T10:29:14+01:00 http://forum.robosavvy.com/viewtopic.php?t=5306&p=31568#p31568 <![CDATA[Project Update...]]>
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

Statistics: Posted by PaulL — Fri Jun 24, 2011 10:29 am

]]> 2011-05-24T11:27:20+01:00 2011-05-24T11:27:20+01:00 http://forum.robosavvy.com/viewtopic.php?t=5306&p=31334#p31334 <![CDATA[Roboard Experience...]]>
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

Statistics: Posted by PaulL — Tue May 24, 2011 11:27 am

]]>