I have a love/hate relationship with the idea of project managers. On one hand I'm lazy and highly technical. This means that I don't like bookkeeping type work - writing requirements, deciding on schedules, etc. I would LOVE to have someone do all that for me. On the other hand I know the dangers of handing off work to others. I often don't trust anyone other than myself to perform tasks, especially when I consider them important. In that respect *I* want to be the one deciding on schedules and writing requirements because I don't trust anyone else to treat me fairly.
In my ideal world no one would be a project manager. Projects would manage themselves. All the interested parties would sit at a table and the people proposing the project would talk and the engineers would listen and comment, and in the background an ultra-smart AI would listen and pick key sentences out and turn them into requirements, or listen for tasks, define them and estimate the time required. Then at the end of the meeting the AI would throw up the requirements, tasks, roles, etc on the projector and everyone would review them and say 'Wow! What a smart AI! That's perfect!'
Of course, that can never happen. This AI would have to be not only super intelligent but psychic. The customer never tells the whole story such that all relevant requirements can be ascertained just from their words, and the engineers never fully let loose all of their misgivings about requirements or timetables. Plus the AI would have to have insane amounts of very personal information about everyone involved. It would have to know working habits and skills for all the engineers present as well as what resources were available, what would need to be bought, etc. That's a tall order for an AI.
In fact, that's a tall order for a person. A regular-intelligence human being would have problems with these tasks. But we routinely place all project management duties in one person and his secretary. We expect the project manager to be able to estimate schedules, costs and define requirements for a product that doesn't exist yet, with customers he's possibly never worked for before and an engineering team he may barely know.
Ideally we have a program manager to free the engineers from the mundane tasks of scheduling and budget and so forth. But how can a program manager reliably perform all of these tasks when he doesn't have all the information he needs? Scheduling is truly on the individual engineers. No one else is more qualified to determine how quickly they will perform their tasks than themselves. Yet the program manger does this. The customer knows all of the requirements, spoken or unspoken. The engineers are the ones with an idea of how those requirements will be implemented. But a basically unrelated third party - the program manager (and/or system engineer in this case, I'm semi-combining these roles here) - will be the one creating the definitive requirements for everyone. How likely is it that what he write reflect the wishes of the customer and the capabilities of his engineering staff? One of the other is very possible, but not both. And cost... no one knows cost. Cost is based on time and materials. Time you've estimated (however badly), materials are probably also estimated (again, by the program manager, not the engineers) but cost can be wildly changed by unforseen circumstances. Unforeseen by anyone, customer, PM or engineers. It almost doesn't make sense to estimate cost, but we do it. Then we complain when we go over.
So project managers work, and they keep working. They create the initial estimate and then refine it as time goes on and data changes. And by 'when data changes' I mean 'when reality finally kicks in and shows how wrong the program manager's estimates were'. It's true that we cant' expect miracles from program managers but what can we expect? They can look at schedules from other programs, costs, requirements, etc and guess on what to do for this one. But each program is unique. If it weren't, then it's something that has already been done. Just go buy it in that case. The past has little/no meaning for this current unique program. True, statistics can provide us with some basis for estimations. But that justifies a Matlab program to calculate likely costs and schedules - not a full-time human being who has no interaction in the daily workings of a project.
How can the program manager create more reliable estimates than his originals when he has no new information (other than that his estimate was wrong)? The engineer knows why it took longer, and he can tell you if other tasks will take longer as a result or if it's a fluke. Sure the PM can talk to the engineer about it, but at that point the engineer is still involved in the PM responsibilities - why have the PM? The idea was to keep the engineer on task, not writing schedules.
We have to face the fact that the people who know the most about the schedule, costs and requirements are the engineers themselves! It makes no sense to remove them from the process. Both engineers and management are guilty in this respect: engineers consider planning beneath them and management thinks that only PMs have the skills necessary. Both are somewhat incorrect.
Engineers: planning is not beneath you. It is not a waste of your time. It is a necessary part of doing anything. And you are the right person for the job.
Management: PMs do not have a holy mix of difficult skills. They have rules of thumb and past data to work with. While this IS a good way of planning, it can't be considered fool-proof and it doesn't need to be done by a single person. There are products out there like FogBugz that intelligently create and track schedules using nothing but input from the actual developers. The program manager's task would be reduced to looking at the estimates and sending emails about them to the customer. Ok, it doesn't do costs, but the same high-powered math that runs its intelligent scheduling algorithms could be applied to that as well.
And what about requirements? There are whole rafts of collaboration software out there that would allow requirements to be quickly argued back and forth and fleshed out between the customers and engineers alone. Use a wiki. Have the customer write out their first draft of requirements. Let the engineers responsible comment and change. Argue back and forth during development. Use quick-turnaround methods to see if requirements are reasonable.
The moral of the story is: Don't front-load all of your planning and then find out six months in that it was wrong. When engineers spurn project planning and force it on to people who have little idea what's going on then we all lose. Schedules and requirements and cost estimates are living documents. We should spend all of this time to create 'The Plan', find out its impossible, and then scurry around for a while trying to fix a broken plan. You should start quick and revise often. And the people working on it need to be in charge - not a paper-pusher who hasn't ever engineered anything.
This is not possible for all businesses. In fact it's utterly impossible for the company I work for. In all of my examples it's pretty much assumed that the customer has chosen your company and is sticking with it. The bar for that in my industry is VERY high. You need 'The Plan', set in stone and handed down from on high, to even get the business. And 'The Plan' has to be 'The Right Plan' or 'The Best Plan' - the lowest-cost fastest and best ever plan. Otherwise you're not getting the contract.
It's sad, but in this line of work the PMs do have a magic and holy mix of skills. They can take input from engineering, requirements from the customer and a little dose of actual reality, then turn that into a plan that looks perfect to the customer and might vaguely be possible. In other words, productive deception is their skill.
*Sigh*
Thursday, September 17, 2009
Tuesday, September 15, 2009
On Requirements
I like looking at job postings. It's kinda like shopping for a new TV. 'Oooh, this one is for designing analog circuits!' instead of 'Ooooh, this one has three HDMI ports!'
But they're still funny, funny things. There's so many problems with how people are hired nowadays. For instance, I rarely see jobs that ask for less than 5 years of experience in... something. Whatever the job is about. Want a job making circuits? Five years experience in making circuits, mandatory. Your resume is not even considered if you don't have five years of valid work experience. Go work for $random_big_corporation with a well-known name developing circuits for five years and we'll consider you.
What exactly is the value of five years of 'professional' work experience? Surely you have a number of designs under your belt, a list of components you use, probably a few contacts for samples, support, etc? But if you've been hacking together circuits since you were five and have a web page full of stuff you've done, but only two years of work experience then you're not supposed to apply. What does the five years working for a company guarantee them? Certainly not quality. Anyone can remain employed with a certain title and be bad at their job. I see plenty of people like that, but when they leave they'll put right on their resume - '5 years of bad designs, rework, lost profit and profanity. But my title was analog design engineer the whole time.' That guy wins.
And what's with the specific skills? 'Must use Eagle for schematics and layout.' Ok, I'll learn Eagle. Not my preferred solution but I'll do it if it gets me a job. Oh wait, it doesn't say that. It says 'Proficiency in Eagle schematic capture and layout required'. What? When you're looking for a mechanic do you put 'Must have proficiency with Craftsman brand crescent wrenches'? I've used plenty of schematic capture programs and none of them are black magic (except maybe PSPICE. Grrrrr....). I'm sure I can use Eagle very well if you give me a few hours to play with it. Heck, I can DOWNLOAD it and play with it - I'll get it done before I come to work for you! The tool is not supposed to define the job. If anything, arbitrary requirements only diminish the talent pool of people who can help you. (Note I said 'arbitrary' requirements. Some requirements are sadly justified.)
So your resume has to have a bullet point - 'Created 12346463113 circuit desgins for a toaster using Eagle'. Perfect. That gets past the filter. Why do the tools matter so much? True, if I'm going to work for a company that's doing a large program in C#, then I had better have worked with C# before. But that's what coders do. Code monkeys. People who get specifications in and produce code for output. Then a freaking computer checks their work with a unit test and tells them if they did it wrong. These people are automatons. Their job requires almost no original thinking. Engineering is supposed to be about creativity - finding solutions to problems. I always thought I would be sat down and they'd say something like 'This hyperdrive keeps overloading when we turn it on. We need to reach the Tok'Ra in three days before Apophis comes in his mothership and beats the crap out of us.' To which I'd say 'I'll put my engineering mind to work on that problem right away. And I need to work with Major Carter. Alone. Naked.' What's NOT supposed to happen is for them to then say 'Oh by the way, it all has to be done in Lisp. You have 5 years of Lisp experience, right?' Whatever happened to the right tool for the job? You know - how it's supposed to make things easier/cheaper/faster?
And don't you love how every job has its little 'niche'? This position is for an automation engineer, not an electrical engineer. This one is for an embedded application developer, not a software engineer with a specialty in embedded systems. The proposed scope is so small it's like it's not even worth it. Even if you have superior experience it doesn't matter.
'This position requires experience with PLCs'.
'Oh, those are microcontrollers with a whole bunch of electronics. I could design one of those. Can I have the job?'
'No, you just said you don't have any experience with PLCs.'
*facepalm*
Or better yet, your similar experience is worthless:
'I studied to be a controls engineer but I think I fit for this DSP position. DSP and controls stem from the same theoretical background and I've also had extensive training in numerical methods for computer systems. Also, I created an embedded sensor platform that used DSP, so I have practical experience in embedded programming and DSP. Can I have the job?'
'I'm sorry, we're not hiring controls engineers.'
*facepalm*
If I had to boil it down to one question it would be:
Why are businesses afraid to hire anyone but the person who exactly fits?
There are so many modifiers on these job listings that you'd think they had millions of people to choose from and they could afford to be picky. Ideally on the internet they do, but then they do stupid things like say 'Local candidates only' or refuse to pay for people to come out and be interviewed. Or not pay for relocation. Or not help a spouse get a job. So you're limited to whatever people can be found at hand. And they're not going to find their perfect match. I have friends who look for mates like this. Yeah, they're single. And they're missing out on a great part of life.
While it's true that companies cannot afford turnover, they also cannot afford to delay hiring for too long. If a job sits, the work doesn't get done. Or you overwork the people you do have which leads to turnover. All out of an.. ideal? Is it a value nowadays to not train people? To not give people a chance? Not to invest in them? To be picky? To not try new approaches, hire people with new skillsets?
While I can't fathom the reasons that businesses follow these hiring practices I can tell you that it is costing them people. Good people. Specifically, young people. Comparatively untalented, inexperienced good young people. These hiring practices are biased against those who haven't had the chance to develop whatever random skill that is in vogue nowadays.
But that's ok. Soon the baby boomers will retire. And then they'll have to be less picky.
But they're still funny, funny things. There's so many problems with how people are hired nowadays. For instance, I rarely see jobs that ask for less than 5 years of experience in... something. Whatever the job is about. Want a job making circuits? Five years experience in making circuits, mandatory. Your resume is not even considered if you don't have five years of valid work experience. Go work for $random_big_corporation with a well-known name developing circuits for five years and we'll consider you.
What exactly is the value of five years of 'professional' work experience? Surely you have a number of designs under your belt, a list of components you use, probably a few contacts for samples, support, etc? But if you've been hacking together circuits since you were five and have a web page full of stuff you've done, but only two years of work experience then you're not supposed to apply. What does the five years working for a company guarantee them? Certainly not quality. Anyone can remain employed with a certain title and be bad at their job. I see plenty of people like that, but when they leave they'll put right on their resume - '5 years of bad designs, rework, lost profit and profanity. But my title was analog design engineer the whole time.' That guy wins.
And what's with the specific skills? 'Must use Eagle for schematics and layout.' Ok, I'll learn Eagle. Not my preferred solution but I'll do it if it gets me a job. Oh wait, it doesn't say that. It says 'Proficiency in Eagle schematic capture and layout required'. What? When you're looking for a mechanic do you put 'Must have proficiency with Craftsman brand crescent wrenches'? I've used plenty of schematic capture programs and none of them are black magic (except maybe PSPICE. Grrrrr....). I'm sure I can use Eagle very well if you give me a few hours to play with it. Heck, I can DOWNLOAD it and play with it - I'll get it done before I come to work for you! The tool is not supposed to define the job. If anything, arbitrary requirements only diminish the talent pool of people who can help you. (Note I said 'arbitrary' requirements. Some requirements are sadly justified.)
So your resume has to have a bullet point - 'Created 12346463113 circuit desgins for a toaster using Eagle'. Perfect. That gets past the filter. Why do the tools matter so much? True, if I'm going to work for a company that's doing a large program in C#, then I had better have worked with C# before. But that's what coders do. Code monkeys. People who get specifications in and produce code for output. Then a freaking computer checks their work with a unit test and tells them if they did it wrong. These people are automatons. Their job requires almost no original thinking. Engineering is supposed to be about creativity - finding solutions to problems. I always thought I would be sat down and they'd say something like 'This hyperdrive keeps overloading when we turn it on. We need to reach the Tok'Ra in three days before Apophis comes in his mothership and beats the crap out of us.' To which I'd say 'I'll put my engineering mind to work on that problem right away. And I need to work with Major Carter. Alone. Naked.' What's NOT supposed to happen is for them to then say 'Oh by the way, it all has to be done in Lisp. You have 5 years of Lisp experience, right?' Whatever happened to the right tool for the job? You know - how it's supposed to make things easier/cheaper/faster?
And don't you love how every job has its little 'niche'? This position is for an automation engineer, not an electrical engineer. This one is for an embedded application developer, not a software engineer with a specialty in embedded systems. The proposed scope is so small it's like it's not even worth it. Even if you have superior experience it doesn't matter.
'This position requires experience with PLCs'.
'Oh, those are microcontrollers with a whole bunch of electronics. I could design one of those. Can I have the job?'
'No, you just said you don't have any experience with PLCs.'
*facepalm*
Or better yet, your similar experience is worthless:
'I studied to be a controls engineer but I think I fit for this DSP position. DSP and controls stem from the same theoretical background and I've also had extensive training in numerical methods for computer systems. Also, I created an embedded sensor platform that used DSP, so I have practical experience in embedded programming and DSP. Can I have the job?'
'I'm sorry, we're not hiring controls engineers.'
*facepalm*
If I had to boil it down to one question it would be:
Why are businesses afraid to hire anyone but the person who exactly fits?
There are so many modifiers on these job listings that you'd think they had millions of people to choose from and they could afford to be picky. Ideally on the internet they do, but then they do stupid things like say 'Local candidates only' or refuse to pay for people to come out and be interviewed. Or not pay for relocation. Or not help a spouse get a job. So you're limited to whatever people can be found at hand. And they're not going to find their perfect match. I have friends who look for mates like this. Yeah, they're single. And they're missing out on a great part of life.
While it's true that companies cannot afford turnover, they also cannot afford to delay hiring for too long. If a job sits, the work doesn't get done. Or you overwork the people you do have which leads to turnover. All out of an.. ideal? Is it a value nowadays to not train people? To not give people a chance? Not to invest in them? To be picky? To not try new approaches, hire people with new skillsets?
While I can't fathom the reasons that businesses follow these hiring practices I can tell you that it is costing them people. Good people. Specifically, young people. Comparatively untalented, inexperienced good young people. These hiring practices are biased against those who haven't had the chance to develop whatever random skill that is in vogue nowadays.
But that's ok. Soon the baby boomers will retire. And then they'll have to be less picky.
Tuesday, September 8, 2009
On Being 'Well Rounded'
Following up my previous post on how well-rounded I believe I am, I am realizing that being well-rounded is not good. At least, not in my position. Let's consider my position and see why being well-rounded but not deep in any particular skill is not good.
I work for a large company and it employs many people. MANY people. We have all kinds of engineers, technicians, secretaries, project managers, etc. If it can happen on a project chances are we've seen it and hired for it. Need someone to create a schedule and manage a budget? We've got project managers and they've got secretaries. Need someone to design an antenna feed? We have seasoned RF engineers. Need someone to program an 8-bit microcontroller, create interfacing electronics and build an enclosure for everything? Well, no. We don't need one person to do that when we could have three separate people do it. People who excel in their individual areas and can get the job done quicker and better than one person.
Let's be serious - you wouldn't combine all of those tasks into one person unless it was absolutely necessary or desirable. When might those confluence of events happen that make it necessary or desirable? Let's tackle necessary first. It might be necessary to do it with one person because that's all you have. You either can't find people who are skilled in those areas or you can't use them if you did find them. The skillset might not exist in your company if it's small and might not exist in your area if you're in a small town or other backwater type place (like most of where I grew up...). So you use what's available to you and hope that it can get you by. And it might be desirable. You could contract out the work but then you have communication issues and overhead costs and such. If the work isn't particularly difficult then it might not be worth it to bring new people on even if they could get it done in half the time. So a wide array of basic knowledge could be useful if you couldn't hire more people and didn't care too much about time lost and/or wasted.
But at a large company those don't generally hold true. You usually have a ready supply of many differently-skilled people. You probably have at least two people to choose from who have your skill, so you'll always choose the person who is better at what you want to do. Then this person gets more experience and hones his/her skill and eventually becomes an expert. Then, unless this person is unavailable, you will always go to this person if you need his/her skill. In the situation where two people know the skill but have unequal levels of experience, the more experienced person always wins.
And time is usually very important at a large company. There's never enough of it. Competition is fierce and to maintain market position you have to be timely. Contrast with a smaller business: there is little/no market position to maintain so releases of products can be more easily delayed without losing too much money over it. Not that deadlines aren't important to a smaller company, but if they let a deadline slip they are likely to lose less money than a large company, even as a percentage of income.
Both of these factors contribute to drive people to specialization in large companies. With so many people being available, you have to set yourself apart to make an impact. In some circumstances intimate knowledge of a project may make it more worthwhile that you perform multiple tasks with different skillsets yourself. Or they could just put the person with the right skillset underneath you and have you lead him/her.
That's the major difference: A large company is more able and more likely to trade labor for time, where a smaller company doesn't have this luxury. If you aim to be a jack of all trades, shoot for a small company that can't support many people.
Update: I've done a little thinking and I believe there are a couple more things to be said for this line of thinking. 1) The 'time first' mentality tends to push people towards specialization in skills and it also pushes entire organizations towards specialization in skills. If you know Labview and you can do the job in Labview, chances are you'll do it in Labview. So a C# programmer is going to have a hard time. Over time the company becomes a monoculture and tries to apply its one major skillset to all problems (for good or ill). 2) The 'time first' thinking need not be limited to skill sets. If you can buy an off-the-shelf product that does what you need then it makes no sense to build it in-house. You're essentially buying the skillset you need ready-made. This also can lead to a monoculture of suppliers - with certain businesses being preferred over others because of past experience. In and of itself, buying this experience rather than 'growing' it in-house is an acceptable tradeoff for certain decisions but definitely not all decisions. 3) The monoculture induced by either of the above methods can kill a business. If this trend moves forward to its logical conclusion (which is admittedly far-fetched) then you'll have a handful of experts skilled at using a small number of skills/products, or you'll just buy everything from someone else. You run into two problems with this: what happens when your extra-skilled engineers retire/get hit by a bus/find a better offer? Brain drain. What happens when all you do is buy other people's products and put them together? Brain drain again - you now have people whose sole skill is figuring out what other products to buy and re-sell. You're no longer an engineering firm - you're at best a project management firm and at worst a re-seller.
Neither of the above outcomes are guaranteed to happen. There are many other pressures that will come to bear on an organization before this brain drain becomes absolute. However, it may still become terminal before it is absolute and the organization may not survive. There are two ways to combat brain drain: First, never outsource (directly or by means of buying COTS products) your core competency. If you write e-commerce software then outsource your server management, not your programming. If you build Arduinos then outsource your board fabrication, not your board layout. If you do that then you are paying people to develop their skills at the expense of your own. Then, when they are the experts they have no reason to keep you around, or at least, no reason to let you have a big slice of the profit. Second, you must, MUST invest in pursuing different/new technologies and you MUST invest in training less-skilled people. If you have a choice between two people of different skill levels, consider choosing both. Split the work up along skill-level lines and let the less-skilled person cut his/her teeth on the easy stuff and let the more-skilled person handle the hard stuff. But keep them together - working together, seated together and give them the same access to resources/people. Chances are the less-experienced person is younger than the more experienced one and will be around longer than him/her. You'll need the same level of experience if not more in 20 years time, so plan for it!
It is less efficient to make these investments in lower-skill areas and people, but unless you plan for the future you could find your company on the chopping block.
I work for a large company and it employs many people. MANY people. We have all kinds of engineers, technicians, secretaries, project managers, etc. If it can happen on a project chances are we've seen it and hired for it. Need someone to create a schedule and manage a budget? We've got project managers and they've got secretaries. Need someone to design an antenna feed? We have seasoned RF engineers. Need someone to program an 8-bit microcontroller, create interfacing electronics and build an enclosure for everything? Well, no. We don't need one person to do that when we could have three separate people do it. People who excel in their individual areas and can get the job done quicker and better than one person.
Let's be serious - you wouldn't combine all of those tasks into one person unless it was absolutely necessary or desirable. When might those confluence of events happen that make it necessary or desirable? Let's tackle necessary first. It might be necessary to do it with one person because that's all you have. You either can't find people who are skilled in those areas or you can't use them if you did find them. The skillset might not exist in your company if it's small and might not exist in your area if you're in a small town or other backwater type place (like most of where I grew up...). So you use what's available to you and hope that it can get you by. And it might be desirable. You could contract out the work but then you have communication issues and overhead costs and such. If the work isn't particularly difficult then it might not be worth it to bring new people on even if they could get it done in half the time. So a wide array of basic knowledge could be useful if you couldn't hire more people and didn't care too much about time lost and/or wasted.
But at a large company those don't generally hold true. You usually have a ready supply of many differently-skilled people. You probably have at least two people to choose from who have your skill, so you'll always choose the person who is better at what you want to do. Then this person gets more experience and hones his/her skill and eventually becomes an expert. Then, unless this person is unavailable, you will always go to this person if you need his/her skill. In the situation where two people know the skill but have unequal levels of experience, the more experienced person always wins.
And time is usually very important at a large company. There's never enough of it. Competition is fierce and to maintain market position you have to be timely. Contrast with a smaller business: there is little/no market position to maintain so releases of products can be more easily delayed without losing too much money over it. Not that deadlines aren't important to a smaller company, but if they let a deadline slip they are likely to lose less money than a large company, even as a percentage of income.
Both of these factors contribute to drive people to specialization in large companies. With so many people being available, you have to set yourself apart to make an impact. In some circumstances intimate knowledge of a project may make it more worthwhile that you perform multiple tasks with different skillsets yourself. Or they could just put the person with the right skillset underneath you and have you lead him/her.
That's the major difference: A large company is more able and more likely to trade labor for time, where a smaller company doesn't have this luxury. If you aim to be a jack of all trades, shoot for a small company that can't support many people.
Update: I've done a little thinking and I believe there are a couple more things to be said for this line of thinking. 1) The 'time first' mentality tends to push people towards specialization in skills and it also pushes entire organizations towards specialization in skills. If you know Labview and you can do the job in Labview, chances are you'll do it in Labview. So a C# programmer is going to have a hard time. Over time the company becomes a monoculture and tries to apply its one major skillset to all problems (for good or ill). 2) The 'time first' thinking need not be limited to skill sets. If you can buy an off-the-shelf product that does what you need then it makes no sense to build it in-house. You're essentially buying the skillset you need ready-made. This also can lead to a monoculture of suppliers - with certain businesses being preferred over others because of past experience. In and of itself, buying this experience rather than 'growing' it in-house is an acceptable tradeoff for certain decisions but definitely not all decisions. 3) The monoculture induced by either of the above methods can kill a business. If this trend moves forward to its logical conclusion (which is admittedly far-fetched) then you'll have a handful of experts skilled at using a small number of skills/products, or you'll just buy everything from someone else. You run into two problems with this: what happens when your extra-skilled engineers retire/get hit by a bus/find a better offer? Brain drain. What happens when all you do is buy other people's products and put them together? Brain drain again - you now have people whose sole skill is figuring out what other products to buy and re-sell. You're no longer an engineering firm - you're at best a project management firm and at worst a re-seller.
Neither of the above outcomes are guaranteed to happen. There are many other pressures that will come to bear on an organization before this brain drain becomes absolute. However, it may still become terminal before it is absolute and the organization may not survive. There are two ways to combat brain drain: First, never outsource (directly or by means of buying COTS products) your core competency. If you write e-commerce software then outsource your server management, not your programming. If you build Arduinos then outsource your board fabrication, not your board layout. If you do that then you are paying people to develop their skills at the expense of your own. Then, when they are the experts they have no reason to keep you around, or at least, no reason to let you have a big slice of the profit. Second, you must, MUST invest in pursuing different/new technologies and you MUST invest in training less-skilled people. If you have a choice between two people of different skill levels, consider choosing both. Split the work up along skill-level lines and let the less-skilled person cut his/her teeth on the easy stuff and let the more-skilled person handle the hard stuff. But keep them together - working together, seated together and give them the same access to resources/people. Chances are the less-experienced person is younger than the more experienced one and will be around longer than him/her. You'll need the same level of experience if not more in 20 years time, so plan for it!
It is less efficient to make these investments in lower-skill areas and people, but unless you plan for the future you could find your company on the chopping block.
Wednesday, August 26, 2009
Complications...
I consider myself a fairly well-rounded engineer. My specialty is control systems but that's in name only. It doesn't say embedded systems on my MS diploma because I had already taken all of the embedded classes for non-grad credit. It says communications on there because I sat through all of the comm classes (and got A's in them) but even though I know a lot I wouldn't consider that my bag. It doesn't say 'math minor' on my BS degree because I was two classes short (I decided to get a head start on my MS instead of the math minor). I've been programming since I was 6 in BASIC, C, Perl, Python, etc. That doesn't make me a CS major, but the years after that of learning to use source control, taking OOP classes, using unit tests and documenting with Doxygen makes me at least a friend (you guys will be my friend, right?). I built robots when I was a teenager and learned the basics of electromechanical systems as a controls engineer, so I'm claiming some mechanical experience as well. And I can speak German.
But I find as I grow older that some areas I just don't know about. Worse, I think I've built them up so that they seem so difficult that it's not worth it to even try to learn about them. TCP/IP, networking, ethernet - all that is something I've been interested in but thought the barrier to entry was too high. I've fussed about around the edges - I can tell you that the ethernet physical layer uses differential signal and (I believe) a 350MHz signal. I've done web programming and that introduced me to ports and such, but I don't take the time to go and just learn the stuff. I would start and I'd see the 7-layer OSI model and my eyes would just glaze over. Who the hell needs 7 layers (unless it's lasagna)? What are they cramming in there that it NEEDS 7 layers. Is it really this complicated to send data across the internet? I deal with microcontrollers and RS-232. I can send data that way, but for some reason people see the need to make twittering power meters out of the same microcontrollers. Other than being just a foolish idea it seems way too complicated if you have to interpret every layer of this 7-layer monstrosity just to do something as asinine as say 'Your refrigerator is now using 78 watts of power!'
So I figured I wouldn't deal with it. Who needs internet connectivity? I'll get along just fine. But still, it vexes me. It's something I don't know. I have a friend who does all this sort of stuff, makes routers in his free time. So I ask him 'What do you DO? What do you know that I don't know?' And he replies 'I can tell you exactly how a machine responds to a ping request. Where the message goes, where it comes from, what happens. It's complicated but I know it.' Basically, he knows how the OSI model works, what each level does, what happens. And the trick is it's mostly programming after a point. But not straightforward programming: complicated CS-type programming. Layers of abstraction built upon layers of abstraction so in the end you don't know that you're dealing with bits and voltages. You see, software people are TERRIFIED of bits and voltages and they will do anything they can to abstract those away. They have sacrificial programmers that write drivers to interface the bits and voltages to sane, reasonable things like floats and strings. They'd have a minor episode if they saw a character instead of a string. They NEED the 7-layers of the OSI model to be able to effectively ignore the basic truth of what's happening: bits are being represented by voltages. By the time you get to the 5th layer you're dealing with all kinds of structs, connection IDs, sessions and voltagephobia so that you don't know what's going on. If you're me that is.
If he tried to explain it all I think I wouldn't have understood. He could have explained it in Elvish and it would have made as much sense. So I ignore it again BUT IT STILL BOTHERS ME. Especially since I designed what I thought was a very complicated, nice and worthwhile messaging system for microcontrollers built on top of RS-485. It had circular buffers, message queues, priority, timeliness, guaranteed message delivery and all that jazz. It was complicated but I just started at the bottom and worked up. Pretty soon *I* had a few layers just to implement serial communication between a couple of devices. You had to have addresses and ACKs and collision sensing and much more to handle all this. It gets complicated quickly. Even when you start simple you always have the edge case. "Oops, what about this? Better add an address field. Oops, better add parity. Gotta ACK that for sure.."
It adds up. So I thought I might take another crack at TCP/IP and you know what? It turns out it's a bunch of things I already know. Just more queues and buffers and ACKs. When a ping happens (I think this is how it goes...) it's sent to the right computer (as determined by its IP address) where the network layer reads the message, finds it's an ICMP ping packet and puts the information in a special struct then pushes it into a queue for the ICMP handling process to take care of. When it gets around to it, it creates a response packet, tells the network layer where to send it (what IP address) and puts all that data into another struct and pushes it onto a queue for the network layer. That's it. Not too complicated - just data structures, processes and lots of teamwork. I learned something about TCP/IP.
TCP/IP is a complicated system, there's no question. But it does a LOT. It can reliably send data halfway around the world to a computer you didn't know existed in a few seconds. That sort of success is built up on layers and layers of success - each layer being tested and battle-hardened until it has so many special cases that it looks like an insane asylum. But once again - IT WORKS. Simpler systems would not. I don't begrudge the creators of the magical internet their seven layers anymore. It's not simple but it's not incomprehensible. It uses tools and methods that I was aware of - I just wasnt' aware of how they pieced them together. Now I am. The moral of the story is that if there's something you want to learn or need to learn don't think that it's impossible just because it's complicated, and don't condemn the creators of the system just because it's complicated. Just take it slow, re-read a lot and eventually it will make sense. Eventually.
But I find as I grow older that some areas I just don't know about. Worse, I think I've built them up so that they seem so difficult that it's not worth it to even try to learn about them. TCP/IP, networking, ethernet - all that is something I've been interested in but thought the barrier to entry was too high. I've fussed about around the edges - I can tell you that the ethernet physical layer uses differential signal and (I believe) a 350MHz signal. I've done web programming and that introduced me to ports and such, but I don't take the time to go and just learn the stuff. I would start and I'd see the 7-layer OSI model and my eyes would just glaze over. Who the hell needs 7 layers (unless it's lasagna)? What are they cramming in there that it NEEDS 7 layers. Is it really this complicated to send data across the internet? I deal with microcontrollers and RS-232. I can send data that way, but for some reason people see the need to make twittering power meters out of the same microcontrollers. Other than being just a foolish idea it seems way too complicated if you have to interpret every layer of this 7-layer monstrosity just to do something as asinine as say 'Your refrigerator is now using 78 watts of power!'
So I figured I wouldn't deal with it. Who needs internet connectivity? I'll get along just fine. But still, it vexes me. It's something I don't know. I have a friend who does all this sort of stuff, makes routers in his free time. So I ask him 'What do you DO? What do you know that I don't know?' And he replies 'I can tell you exactly how a machine responds to a ping request. Where the message goes, where it comes from, what happens. It's complicated but I know it.' Basically, he knows how the OSI model works, what each level does, what happens. And the trick is it's mostly programming after a point. But not straightforward programming: complicated CS-type programming. Layers of abstraction built upon layers of abstraction so in the end you don't know that you're dealing with bits and voltages. You see, software people are TERRIFIED of bits and voltages and they will do anything they can to abstract those away. They have sacrificial programmers that write drivers to interface the bits and voltages to sane, reasonable things like floats and strings. They'd have a minor episode if they saw a character instead of a string. They NEED the 7-layers of the OSI model to be able to effectively ignore the basic truth of what's happening: bits are being represented by voltages. By the time you get to the 5th layer you're dealing with all kinds of structs, connection IDs, sessions and voltagephobia so that you don't know what's going on. If you're me that is.
If he tried to explain it all I think I wouldn't have understood. He could have explained it in Elvish and it would have made as much sense. So I ignore it again BUT IT STILL BOTHERS ME. Especially since I designed what I thought was a very complicated, nice and worthwhile messaging system for microcontrollers built on top of RS-485. It had circular buffers, message queues, priority, timeliness, guaranteed message delivery and all that jazz. It was complicated but I just started at the bottom and worked up. Pretty soon *I* had a few layers just to implement serial communication between a couple of devices. You had to have addresses and ACKs and collision sensing and much more to handle all this. It gets complicated quickly. Even when you start simple you always have the edge case. "Oops, what about this? Better add an address field. Oops, better add parity. Gotta ACK that for sure.."
It adds up. So I thought I might take another crack at TCP/IP and you know what? It turns out it's a bunch of things I already know. Just more queues and buffers and ACKs. When a ping happens (I think this is how it goes...) it's sent to the right computer (as determined by its IP address) where the network layer reads the message, finds it's an ICMP ping packet and puts the information in a special struct then pushes it into a queue for the ICMP handling process to take care of. When it gets around to it, it creates a response packet, tells the network layer where to send it (what IP address) and puts all that data into another struct and pushes it onto a queue for the network layer. That's it. Not too complicated - just data structures, processes and lots of teamwork. I learned something about TCP/IP.
TCP/IP is a complicated system, there's no question. But it does a LOT. It can reliably send data halfway around the world to a computer you didn't know existed in a few seconds. That sort of success is built up on layers and layers of success - each layer being tested and battle-hardened until it has so many special cases that it looks like an insane asylum. But once again - IT WORKS. Simpler systems would not. I don't begrudge the creators of the magical internet their seven layers anymore. It's not simple but it's not incomprehensible. It uses tools and methods that I was aware of - I just wasnt' aware of how they pieced them together. Now I am. The moral of the story is that if there's something you want to learn or need to learn don't think that it's impossible just because it's complicated, and don't condemn the creators of the system just because it's complicated. Just take it slow, re-read a lot and eventually it will make sense. Eventually.
Thursday, August 20, 2009
Content or Not Content?
That title up there is actually a clever double-meaning. I'll get to those meanings in a second. Suffice it to say I'm smart and it makes me feel smarter to withhold information from you for a few minutes longer. It won't be terribly long, so just bear with me.
I've often heard that writers can't write if they're happy. After all, how boring is happy? Have you ever imagined yourself perfectly content with not a care in the world? How long did you keep imaging that before it you moved on to something more interesting? It takes me about five seconds. I imagine myself sitting in a chair with a smile on my face and... then I repeat that. Forever. That's dull. Writers know this either consciously or subconsciously and strive to keep themselves aggravated. After all, writing is about conflict. Protagonists, antagonists, twists, man vs. man, man vs. nature, man vs. God, etc. So it doesn't do to live a life of contentment because the more conflict you're familiar with, the more you have to write about. Those writers make good books (in case you didn't catch it, the first meaning of the title was 'content' as in 'the opposite of conflicted').
So perhaps I can take it as an indication of my level of contentedness that I don't write here much. That's actually incorrect or at least a confusing argument. For instance, what kind of content could I put here? I started this blog to detail cool ideas I had and hope that other people would say 'wow, that's neat! I didn't know you could do that!'. I have some of those. From time to time. But my day-to-day work isn't exactly to work with super-awesome ideas all the time. It's somewhat hard to breed super-awesome ideas ("Hey guys, let's make robots with neural networks that train themselves to efficiently compete for limited resources against other robots!") when the only ideas you work with are super-pedestrian ("Hey guys, let's use Labview for test software again! All right! Just like the last 50 times! High-Five!"). Now the total contents of this blog are by no means all of the super-awesome ideas I've come up with, but it's enough of them. What I DIDN'T want to do with this blog was to 1) whine about my life and how horrible it is, 2) just post links to cool things OTHER people have done and 3) update about how I haven't had time to update.
I hate whining. And my life isn't awful or even excessively boring. What's the worst thing that happened to me lately? I had a fight with my wife this morning. Sure there was yelling. Sure there was screaming. Sure I kicked a robot (poor Roomba!) Sure we were angry. So what? That's not bad, that's a fight. That's a normal fight. I'll tell you what we didn't do. We didn't threaten to leave each other. We didn't say things like 'My ex-girlfriend never did this to me! That's why I like her much more than you!' We pushed each others' buttons and eventually apologized to each other. Wow. I'll tell you the number one thing I fear is getting in fights with my wife, but that's not the worst thing in the world. And how boring is my life? Well today I had to go through my Labview sub-VIs and re-arrange the connections one-by-one. I have about 20 of them. Yeah it's boring but I grew up on a farm. My dad used to have me stand in front of open gates and keep the pigs in just so he wouldn't have to close the gate and reopen it when he wanted to get out with the tractor. I did that for hours. In winter. I think I'll survive my office.
I also hate when people just link other things on blogs. 'Hey look at this cool kegerator robot!' Ok. That's good. But most of the EE/hacking blogs I read linked to that site on that particular day. It was a little excessive to read about it five different times, and I think we'd live in a worse world if I made it six. Just a link, no commentary, no analysis, no further ideas. Just aggregation. Go blagosphere. If anyone is actually reading this be assured I will NOT do that to you. If you, for some reason, subscribe to this blog you will not get that sort of 'content' (second meaning of the title!). You will get something original even if it's just meaningless ranting like right now (which, honestly probably isn't that original. Read Ecclesiastes).
And posting about how you have no time to post? No. Just Say No. Let me say one thing: it is essential to actively maintain something you want to build a following around. If you want people to read it then update it every day even if it's not particularly useful information or even tangentially related to your subject. People will either read it for the sake of reading or stop reading it altogether. But the people who read it for the sake of reading it will continue, daily, religiously. Then you can put ads in front of their face and get a shiny nickel. But it has to be NEW or at least something they don't ALREADY KNOW. If you dont' update your blog for a while then guess what? People know that. They can see it. So if you update and say 'I haven't updated for a while' they will respond 'We know' and leave. People aren't interested in things they already know. Better to update less often and with actual information than to tell people something they already know.
So that's my rant. Can you expect high-quality updates from me from now on? Probably not. I would actually have to do interesting things, or in fact, things at all. I'd have to have something to write about and it turns out I only rarely have that. And, if I start writing about non-engineering things I risk becoming like everyone else. And I HATE everyone else. They make me angry, hence the name of the blog.
I've often heard that writers can't write if they're happy. After all, how boring is happy? Have you ever imagined yourself perfectly content with not a care in the world? How long did you keep imaging that before it you moved on to something more interesting? It takes me about five seconds. I imagine myself sitting in a chair with a smile on my face and... then I repeat that. Forever. That's dull. Writers know this either consciously or subconsciously and strive to keep themselves aggravated. After all, writing is about conflict. Protagonists, antagonists, twists, man vs. man, man vs. nature, man vs. God, etc. So it doesn't do to live a life of contentment because the more conflict you're familiar with, the more you have to write about. Those writers make good books (in case you didn't catch it, the first meaning of the title was 'content' as in 'the opposite of conflicted').
So perhaps I can take it as an indication of my level of contentedness that I don't write here much. That's actually incorrect or at least a confusing argument. For instance, what kind of content could I put here? I started this blog to detail cool ideas I had and hope that other people would say 'wow, that's neat! I didn't know you could do that!'. I have some of those. From time to time. But my day-to-day work isn't exactly to work with super-awesome ideas all the time. It's somewhat hard to breed super-awesome ideas ("Hey guys, let's make robots with neural networks that train themselves to efficiently compete for limited resources against other robots!") when the only ideas you work with are super-pedestrian ("Hey guys, let's use Labview for test software again! All right! Just like the last 50 times! High-Five!"). Now the total contents of this blog are by no means all of the super-awesome ideas I've come up with, but it's enough of them. What I DIDN'T want to do with this blog was to 1) whine about my life and how horrible it is, 2) just post links to cool things OTHER people have done and 3) update about how I haven't had time to update.
I hate whining. And my life isn't awful or even excessively boring. What's the worst thing that happened to me lately? I had a fight with my wife this morning. Sure there was yelling. Sure there was screaming. Sure I kicked a robot (poor Roomba!) Sure we were angry. So what? That's not bad, that's a fight. That's a normal fight. I'll tell you what we didn't do. We didn't threaten to leave each other. We didn't say things like 'My ex-girlfriend never did this to me! That's why I like her much more than you!' We pushed each others' buttons and eventually apologized to each other. Wow. I'll tell you the number one thing I fear is getting in fights with my wife, but that's not the worst thing in the world. And how boring is my life? Well today I had to go through my Labview sub-VIs and re-arrange the connections one-by-one. I have about 20 of them. Yeah it's boring but I grew up on a farm. My dad used to have me stand in front of open gates and keep the pigs in just so he wouldn't have to close the gate and reopen it when he wanted to get out with the tractor. I did that for hours. In winter. I think I'll survive my office.
I also hate when people just link other things on blogs. 'Hey look at this cool kegerator robot!' Ok. That's good. But most of the EE/hacking blogs I read linked to that site on that particular day. It was a little excessive to read about it five different times, and I think we'd live in a worse world if I made it six. Just a link, no commentary, no analysis, no further ideas. Just aggregation. Go blagosphere. If anyone is actually reading this be assured I will NOT do that to you. If you, for some reason, subscribe to this blog you will not get that sort of 'content' (second meaning of the title!). You will get something original even if it's just meaningless ranting like right now (which, honestly probably isn't that original. Read Ecclesiastes).
And posting about how you have no time to post? No. Just Say No. Let me say one thing: it is essential to actively maintain something you want to build a following around. If you want people to read it then update it every day even if it's not particularly useful information or even tangentially related to your subject. People will either read it for the sake of reading or stop reading it altogether. But the people who read it for the sake of reading it will continue, daily, religiously. Then you can put ads in front of their face and get a shiny nickel. But it has to be NEW or at least something they don't ALREADY KNOW. If you dont' update your blog for a while then guess what? People know that. They can see it. So if you update and say 'I haven't updated for a while' they will respond 'We know' and leave. People aren't interested in things they already know. Better to update less often and with actual information than to tell people something they already know.
So that's my rant. Can you expect high-quality updates from me from now on? Probably not. I would actually have to do interesting things, or in fact, things at all. I'd have to have something to write about and it turns out I only rarely have that. And, if I start writing about non-engineering things I risk becoming like everyone else. And I HATE everyone else. They make me angry, hence the name of the blog.
Monday, July 6, 2009
When the robot is smarter than you...
...then you had best let it drive!
Teleoperation is one of the largest growth areas for robotics. All kinds of robots are being used in situations that are dangerous to people: battlefields, burning buildings, defusing bombs, etc. I don't know about you, but when I defuse a bomb or do any other precision work I like to have all of my senses about me. Heck, I like to have all of my senses about me when I'm walking down the street. You couldn't pay me enough to remove one of my senses or any of the well-tuned reflexes that my body has developed over time.
So why is it when we ARE paying people to build robots we ignore most of those sense? In many of the tele-operated robots I've seen you one sense: a teeny camera. And you have two little sticks that move your tracks or wheels. That's it. And what happens? You drive your robot around half blind into walls. Somehow when we design robots for autonomous operation we give them all kinds of sensors and instructions for how to deal with their input. If an autonomous robot saw it was about to run into a wall it would correct itself and move on. But somehow when we put a human in the loop we forget how difficult it is to control these things so we give it a camera and call it done. There's a human in the loop so why bother?
Why not give a teleoperated robot the same senses and reflexes we give the autonomous ones? The same senses and reflexes we ourselves couldn't function without. If a human operator is about to ram the robot into a wall then DON'T LET HIM! Put ultrasound transducers on there and when the wall gets too close stop. Chances are you're not trying to run into the wall but instead run parallel to it. Then this behavior works perfectly. Get more in-depth with it. There are cars now that will auto-parallel park. This is amazing and probably safer than letting me do it myself. Robots should do the same thing. For any complicated tele-operation there should be a way to do it automatically. Most people can't back up a truck to a loading dock without someone watching for them. Is this any different?
One obvious application of these ideas is an area that technically isn't tele-operation: powered wheelchairs. Have you seen them? They are beyond dumb as far as controls and intelligence are concerned. They consist largely of a battery, motors and a way to steer. Of course, at this stage of the design life for powered wheelchairs the main problems they are dealing with is not enough power and not enough battery life. But when these are dealt with you'll still have a powered wheelchair that is more than happy to run into anything faster than it could before, and for a longer duration!
For the sake of pedestrians in the vicinity and the paint jobs of objects nearby wheelchairs should be semi-autonomous. I hate to make generalizations but for the most part older people's reflexes and fine motor control are on a downward trend. For the people confined to wheelchairs it's likely very well gone. And there are many diseases that impair fine motor control. It's not right to expect our senior citizens to be able to control their wheelchairs perfectly with a joystick (in fact I wouldn't count on anybody's ability to control such a device with a joystick - the input method has to be somewhat tailored to the system being controlled and a joystick doesn't move the same way a wheelchair does).
The most basic of features you could put into a semi-autonomous wheelchair would be obstacle avoidance. All the walls would be safe as attempting to run directly into them would cause the chair to stop a few feet in front. You could not worry about crowding out others if the wheelchair by default hugged a wall as it moved forward and if it deftly maneuvered around a door frame without significant interaction then so much the better. If you wanted to sit at a table without knocking your feet on the table legs just have the automatic systems do it. Perfect fit every time. You could even define more advanced algorithms. If you wanted to be able to open a door from the wheelchair you'd need to move within arms' range of the handle, turn it, then prop the door open with the wheelchair and move through. It might require some extra hardware and a lot of testing to be able to identify the door frame, back up, prop it open, etc. But the benefit to someone who couldn't open that door before would be significant.
Let's face it - no one wants to be stuck in a chair. People weren't designed to move around in chairs we were designed to walk. Trying to adapt our thinking and motor skills to a physical system totally different than our natural method of locomotion is difficult for anyone. Automatic systems can and should make this easier on those who have no other choice. It's an improvement for quality of life for everyone involved just to let the robot do some of the driving for you.
Teleoperation is one of the largest growth areas for robotics. All kinds of robots are being used in situations that are dangerous to people: battlefields, burning buildings, defusing bombs, etc. I don't know about you, but when I defuse a bomb or do any other precision work I like to have all of my senses about me. Heck, I like to have all of my senses about me when I'm walking down the street. You couldn't pay me enough to remove one of my senses or any of the well-tuned reflexes that my body has developed over time.
So why is it when we ARE paying people to build robots we ignore most of those sense? In many of the tele-operated robots I've seen you one sense: a teeny camera. And you have two little sticks that move your tracks or wheels. That's it. And what happens? You drive your robot around half blind into walls. Somehow when we design robots for autonomous operation we give them all kinds of sensors and instructions for how to deal with their input. If an autonomous robot saw it was about to run into a wall it would correct itself and move on. But somehow when we put a human in the loop we forget how difficult it is to control these things so we give it a camera and call it done. There's a human in the loop so why bother?
Why not give a teleoperated robot the same senses and reflexes we give the autonomous ones? The same senses and reflexes we ourselves couldn't function without. If a human operator is about to ram the robot into a wall then DON'T LET HIM! Put ultrasound transducers on there and when the wall gets too close stop. Chances are you're not trying to run into the wall but instead run parallel to it. Then this behavior works perfectly. Get more in-depth with it. There are cars now that will auto-parallel park. This is amazing and probably safer than letting me do it myself. Robots should do the same thing. For any complicated tele-operation there should be a way to do it automatically. Most people can't back up a truck to a loading dock without someone watching for them. Is this any different?
One obvious application of these ideas is an area that technically isn't tele-operation: powered wheelchairs. Have you seen them? They are beyond dumb as far as controls and intelligence are concerned. They consist largely of a battery, motors and a way to steer. Of course, at this stage of the design life for powered wheelchairs the main problems they are dealing with is not enough power and not enough battery life. But when these are dealt with you'll still have a powered wheelchair that is more than happy to run into anything faster than it could before, and for a longer duration!
For the sake of pedestrians in the vicinity and the paint jobs of objects nearby wheelchairs should be semi-autonomous. I hate to make generalizations but for the most part older people's reflexes and fine motor control are on a downward trend. For the people confined to wheelchairs it's likely very well gone. And there are many diseases that impair fine motor control. It's not right to expect our senior citizens to be able to control their wheelchairs perfectly with a joystick (in fact I wouldn't count on anybody's ability to control such a device with a joystick - the input method has to be somewhat tailored to the system being controlled and a joystick doesn't move the same way a wheelchair does).
The most basic of features you could put into a semi-autonomous wheelchair would be obstacle avoidance. All the walls would be safe as attempting to run directly into them would cause the chair to stop a few feet in front. You could not worry about crowding out others if the wheelchair by default hugged a wall as it moved forward and if it deftly maneuvered around a door frame without significant interaction then so much the better. If you wanted to sit at a table without knocking your feet on the table legs just have the automatic systems do it. Perfect fit every time. You could even define more advanced algorithms. If you wanted to be able to open a door from the wheelchair you'd need to move within arms' range of the handle, turn it, then prop the door open with the wheelchair and move through. It might require some extra hardware and a lot of testing to be able to identify the door frame, back up, prop it open, etc. But the benefit to someone who couldn't open that door before would be significant.
Let's face it - no one wants to be stuck in a chair. People weren't designed to move around in chairs we were designed to walk. Trying to adapt our thinking and motor skills to a physical system totally different than our natural method of locomotion is difficult for anyone. Automatic systems can and should make this easier on those who have no other choice. It's an improvement for quality of life for everyone involved just to let the robot do some of the driving for you.
Wednesday, May 13, 2009
Power Power Everywhere...
But specifically from the sun. We will never run out of power (never being equivalent to several billion years) because of the sun. Consider that most of our power comes from consuming things. Basically we burn things - we turn complex hydrogen-carbon chains into simpler ones and live off of the resulting energy output. Coal, wood, sugar - it's all the same. Combustion. The sun is better. The sun is powered by gravity itself. By the very shape of the universe! There's a lot more energy out there than sitting in every oil field, forest or coal mine. But how do we access it? The simplest method is by laying in the sun and getting warm. As much as I like a tan, I LOVE electrical power! So I use solar panels.
Let's talk about them for a second. Solar panels are a lot like batteries in some ways. You start out with solar cells which are maybe an inch square of real estate. They're made of silicon in an extra-special arrangement which causes them to produce voltage and current when light strikes them. But how much of each? There's essentially two main parameters that matter. The first is open-circuit voltage, the second is short circuit current. They're fairly self-explanatory: if you shine sufficient light on the cell and don't put an electrical load on it then you'll measure the open-circuit voltage across its output; if you shine a light on it and put a short circuit on the output then you'll measure the short-circuit current through the output. In between those points is not a straight line, but more of a graph with a knee. Take a look at the graph I show below and you'll see what I mean.
You'll notice that the cells are almost constant voltage sources except when you attempt to draw currents close to the short-circuit current. You can either use a simplistic model of a constant voltage source or you can use a more complicated model that accounts for the actual behavior more:
If my calculations are correct, Il is the short-circuit current and the open-circuit voltage is equivalent to Il*RSh. Props to Wikipedia for having such awesome images that I can steal for free. I like free.
So that's your single solar cell. They're a lot like the cells of a battery as I mentioned last time: to get a useful voltage out of them you have to put a lot in series. The difference between these and batteries is that you also typically have to put several sets of cells in parallel to get a decent current. I have an 18V solar panel made out of perhaps 32 solar cells - 8 in series and four sets of these in parallel. Its open-circuit voltage is 18V and short-circuit current is 300mA. This actually makes it rather useful for charging batteries!
When charging batteries you need two things at the same time: voltage and current. Well lucky for us voltage and current together are POWER! And we can get power out of our solar panel! Success! Just connect wires to things and make it go! Well, not that easy. You need specific voltages and specific currents to charge our batteries. I have some Ni-Cad batteries that need to be charged at a maximum rate of (off the top of my head - don't hold me to this) their total capacity divided by 10. So I have 5 batteries that have a total capacity of 6A-Hours, so the max rate I charge them at is 6/10 = .6 Amps. And for charging these batteries current is the most important part: as you push more current into them their voltage goes up and you stop putting current into them when they reach about 13.8V. So you need your voltage to be at least above whatever the battery voltage is at the moment. Just figure you'll need at least 13.8V to get this to work.
So we have a specific power IN from the solar panel and we need different power OUT. My first guess is to use an LM317 in constant current mode. However this has problems. The main one is that as you try to draw constant current out of the solar panel its voltage will drop. And the LM317 is a linear device. For linear devices the rule of thumb is that the current into the device is the same as the current out, and the voltage out is less than the voltage in. Thus, you will need to make sure that your solar cell voltage stays above the battery voltage. Good luck, because even if you do make sure of that you will be dissipating the 'extra' voltage from the panel IN the LM317 as heat - thus losing it. Solar panels aren't amazing power sources, so I'd rather not waste any of the power that it does generate.
You can also do power transformation with a switched-mode device. The rule of thumb for switched-mode devices is 'power-in equals power-out'. The only loss is due to efficiency. Another great thing about switched-mode devices is that they can produce nearly any output voltage off of its input voltage. So you can always keep your output voltage above the battery voltage even if the solar panel voltage goes below it. The trick is that switched-mode power ICs are usually set up as constant voltage supplies. They employ a feedback voltage to set the output to the right voltage. They're a little control system! I love control systems! SOOOOO CUTE! It's contained in a single IC! Adorable!
Anyway, I know about control systems and I reckon that I can modify the feedback signal so that it's based off of the current going to the batteries instead of the voltage at the output. I would current sense resistor to monitor that current and then use a differential amplifier to amplify and scale the voltage from the current sense resistor. This would be the new feedback signal to the switched-mode power supply. Thus it would regulate its voltage to make sure that the proper current goes into the batteries.
My fingers are yet again getting tired so I'll mention that this is just the battery charging circuit. You still need an output stage connected to the batteries to power things off of the batteries. Also, there's an improvement on the simple battery charging circuit I described here. It's called a Maximum Power Point Tracker that gets even more power out of the panel than before.
Let's talk about them for a second. Solar panels are a lot like batteries in some ways. You start out with solar cells which are maybe an inch square of real estate. They're made of silicon in an extra-special arrangement which causes them to produce voltage and current when light strikes them. But how much of each? There's essentially two main parameters that matter. The first is open-circuit voltage, the second is short circuit current. They're fairly self-explanatory: if you shine sufficient light on the cell and don't put an electrical load on it then you'll measure the open-circuit voltage across its output; if you shine a light on it and put a short circuit on the output then you'll measure the short-circuit current through the output. In between those points is not a straight line, but more of a graph with a knee. Take a look at the graph I show below and you'll see what I mean.
You'll notice that the cells are almost constant voltage sources except when you attempt to draw currents close to the short-circuit current. You can either use a simplistic model of a constant voltage source or you can use a more complicated model that accounts for the actual behavior more:
If my calculations are correct, Il is the short-circuit current and the open-circuit voltage is equivalent to Il*RSh. Props to Wikipedia for having such awesome images that I can steal for free. I like free.
So that's your single solar cell. They're a lot like the cells of a battery as I mentioned last time: to get a useful voltage out of them you have to put a lot in series. The difference between these and batteries is that you also typically have to put several sets of cells in parallel to get a decent current. I have an 18V solar panel made out of perhaps 32 solar cells - 8 in series and four sets of these in parallel. Its open-circuit voltage is 18V and short-circuit current is 300mA. This actually makes it rather useful for charging batteries!
When charging batteries you need two things at the same time: voltage and current. Well lucky for us voltage and current together are POWER! And we can get power out of our solar panel! Success! Just connect wires to things and make it go! Well, not that easy. You need specific voltages and specific currents to charge our batteries. I have some Ni-Cad batteries that need to be charged at a maximum rate of (off the top of my head - don't hold me to this) their total capacity divided by 10. So I have 5 batteries that have a total capacity of 6A-Hours, so the max rate I charge them at is 6/10 = .6 Amps. And for charging these batteries current is the most important part: as you push more current into them their voltage goes up and you stop putting current into them when they reach about 13.8V. So you need your voltage to be at least above whatever the battery voltage is at the moment. Just figure you'll need at least 13.8V to get this to work.
So we have a specific power IN from the solar panel and we need different power OUT. My first guess is to use an LM317 in constant current mode. However this has problems. The main one is that as you try to draw constant current out of the solar panel its voltage will drop. And the LM317 is a linear device. For linear devices the rule of thumb is that the current into the device is the same as the current out, and the voltage out is less than the voltage in. Thus, you will need to make sure that your solar cell voltage stays above the battery voltage. Good luck, because even if you do make sure of that you will be dissipating the 'extra' voltage from the panel IN the LM317 as heat - thus losing it. Solar panels aren't amazing power sources, so I'd rather not waste any of the power that it does generate.
You can also do power transformation with a switched-mode device. The rule of thumb for switched-mode devices is 'power-in equals power-out'. The only loss is due to efficiency. Another great thing about switched-mode devices is that they can produce nearly any output voltage off of its input voltage. So you can always keep your output voltage above the battery voltage even if the solar panel voltage goes below it. The trick is that switched-mode power ICs are usually set up as constant voltage supplies. They employ a feedback voltage to set the output to the right voltage. They're a little control system! I love control systems! SOOOOO CUTE! It's contained in a single IC! Adorable!
Anyway, I know about control systems and I reckon that I can modify the feedback signal so that it's based off of the current going to the batteries instead of the voltage at the output. I would current sense resistor to monitor that current and then use a differential amplifier to amplify and scale the voltage from the current sense resistor. This would be the new feedback signal to the switched-mode power supply. Thus it would regulate its voltage to make sure that the proper current goes into the batteries.
My fingers are yet again getting tired so I'll mention that this is just the battery charging circuit. You still need an output stage connected to the batteries to power things off of the batteries. Also, there's an improvement on the simple battery charging circuit I described here. It's called a Maximum Power Point Tracker that gets even more power out of the panel than before.
Subscribe to:
Posts (Atom)
