General project planning methodology?

Hi all,

I was wondering how you are planning your projects. I usually go the same way I did when I was playing Legos... I think, do, rethink and redo and so on until I get it right making up new things as I go along.
This works for small or not so complicated projects but I would like to know about a method that would work with bigger and more complex projects.
So, how do you go from a vague idea to a prototype and a final design? Maybe I wasn't googling the right words but I couldn't find any good howto on the matter.

Thanks!

My usual method is to think what the final product will be...what you want it to do. Then break it down into smaller, more managable steps. Build and test those smaller parts and gradually add them together, testing all the way, until you have your final product. Unless you have something positive to aim for, you'll be forever breaking and rebuilding your Lego structures.

I don't know if you'll get answers that really enlighten you.. At least for me, how I go about a project varies based on what I'm doing.

Some of it starts out with a solid idea of what I want, and then tackling parts of it, then putting those pieces together and applying whatever "glue" (metaphorically) it requires to be a completed project. Very rarely could I ever draft a procedure from start to finish until I'm done. Even then, I would probably do some things differently. If I did it again, I'd probably change further things still. Revisions, ya know?

I find the stress of trying to get everything right the first time is not usually worth it. So, I pick a place (code, the enclosure, a breadboard with the key components, whatever..) and get the ball rolling, then build around that. Maybe I'll make the PCB next. Or find where it'll live permanently (if it will be permanent at all), and imagine what parts will be on a front panel, accessible after it's built, and then design the PCB. It all depends.

My most complex completed project so far is a powered subwoofer. I had an unusual 6" subwoofer I found and bought years ago because it looked interesting, but I had no plans for it. So, one day I decided I was ready to put it to use. I found plans for a horn-loaded enclosure made for that speaker. It looked relatively easy to build, had incredibly low response (down below 40Hz), and it's esoteric (which I like), so I got the wood and made the box.

Then, I needed an amp. I knew I'd first need a power supply, and those are generally simple, so I started there. I got a toroidal transformer, some high-power diodes, large caps, and pos/neg linear regulators for the preamp stuff. You can hardly go wrong, but I simulated a basic design in software, and it seemed sound, so I ordered PCBs. Turns out, I didn't get the right pinout for the negative regulator, so that went up in smoke. Easy fix, but another $90 in PCBs and a week for delivery. Tough teacher, but I won't make that mistake twice!

I had been looking at some of the National power op-amp ICs, which seemed easy to use, so I found some schematics, and designed the amp PCB. (Couldn't really test it due to the pins not being particularly breadboard friendly.) The first PCB worked OK, but had some grounding issues, so I revised it. Second one worked great.

Obviously low cost was not my prime motivator. By now I could've bought something nice for the price in parts and PCBs. But what fun is that?

I wanted some fancy features -- a variable crossover, gain control, auto power-off -- so I found examples online and built what I could on breadboards. Each stage is basically a block you can build and test by itself, so I did just that. The auto power-off part was the hardest. I found something similar, simulated it in software, tweaked some values, then decided I didn't like the flaky response, so I redesigned parts of it, simulated again, tested with real parts, and finally got what I wanted. Then, I designed the most densely populated PCB I had ever made up to that point. I printed it, tested the fit of all the parts, checked each connection, and then checked them again. I went over all the ground points, all the positive and negative power pins, the signal path.. and ordered those boards too. Success on the first time! Still found something I'd like to change, but it was a minor tweak.

Finally, I found an ad for a site that will design metal faceplates in the back of Make magazine. I carefully measured all the controls and mounting holes, reading data sheets and verifying with a ruler. Then, I printed my design and put my PCBs and parts in / on / through it. After a few fixes, I sent the design off for manufacture and got back the powder-coated plate. It was almost perfect -- had to enlarge one hole a little with a Dremel.

The last step is to cut a hole in the box, have a metal backing enclosure made for the amp (so it doesn't leak air through the holes in the plate!) and paint the box, but I've been enjoying it so much that I haven't wanted to take it apart long enough to finish it.

So there ya go. I don't know if this is exactly what you're going for. Did you have something in particular you're stuck on?

I usually go the same way I did when I was playing Legos... I think, do, rethink and redo and so on until I get it right making up new things as I go along.

That seems like a good approach. I like to "develop" or "grow" the project...

The "right way" is to develop your requirements/specifications first. With a hobby project, you don't need all of the details nailed-down first, in fact you might get some good/better ideas as you progress. But, you should have an idea where you are going...

Then try to figure-out if it's feasable and economical, and try to get some ideas of how you are going to approach it. What's it going to take in terms of time, materials, knowledge, and skill? (If you wanted to build a motorcycle, you wouldn't use Legos, etc. )

For me it seems like I usually start with the hardware. I try to figure-out what kinds of parts I'm going to need (is the Arduino going to work, or do I need something different?) and I sketch-up a schematic, even if I don't know details like exact resistor/capacitor values, or what transistor I'm going to use, etc. Then I order some parts, and probably a few extra parts. It's not unusual for me to make a 2nd parts order as the project moves-along, but hopefully I'll only have to order parts once or twice.

Then I start development... What I mean by "development", is that I break it down into parts/modules that can be built & tested separately. I do this with both the hardware and software, and where I start depends on the project... Typically, there is input and output. I may be able to test the output-hardware (i.e. relays, or an LED matrix, etc.) by itself by hooking-up voltages, or I may be able to use a little test-program. Same with the input-side hardware (i.e. switches, op-amps, etc.). I may be able to test it by itself, or with a multimeter, or I might need to hook-up the Arduino and run another little test-program. Or, maybe I need the Arduino and the output-stuff working before I can fully-test the input side... That's stuff you have to figure-out.

For "prototyping", my standard practice is to build the final circuit on a plug-in "breadboard" whenever possible, so my final-prototype is my final-design.

The same "development" is true with the software (even more true with software). You generally need to write the output-stuff first, so you can "see" what your program is doing. If you try to write the whole program (sketch) at once, you will have lots of errors, it won't work, and you won't know why. And, you usually cannot just start at the top, and work down... You need to start with things that you can try/test and when they work, add more.

When you write a function, you can start-out with a simple function that does part of what you need (and maybe it blinks an LED, or sends a message to the serial monitor) and then add to it, testing as you go-along. Whenever you add a function, or a bit of code, make sure you can test it before moving-on. If you can't test your code/function because the program isn't finished, you are porbably working on the "wrong" part of your program. Or, sometimes you have to write some extra "test code" just to check-out your "real code". You can remove or comment-out the test code when you're done.

And if you are dong it the "right way", the final step would be to test and confirm you've met all of your requirements/specifications. With a hobby project this isn't usually necessary... You know if you are happy with the result.

I do a lot of concept design on paper. What is the end product (or desired function)? What sub-functions do I need to accomplish it? Break it down into as small pieces as possible and get the pieces working in their simplest form first. What are the inputs and outputs? What format or what kind of data or signals? Is there a simpler way to accomplish this? What have others done? How are the functions going to work together? How am I going to keep track of everything? Flow charts, bubble diagrams etc. can help visualize how the system is going to work together.

Don't try and make everything work the first try. Get one simple function working then save the working code or design in a separate file. Now move to the next function. Move up to the more complex functions as you learn.

You need to think about the system architecture - how all the pieces are going to work together. Look for holes in the logic and (if possible) all the combinations of inputs you might get or if the order in which you process the data matters.

How can you organize your design so that it will be easy to troubleshoot and modify? This is critical for all but the simplest designs. Document your design as you go. If you are doing the same thing in two places in code, use a functions so you don't have to correct errors in more than one place; trust me, you will forget one If possible, only modify a parameter in one spot in code. If more than one function can modify a parameter, think about how they might conflict with one another.

When building hardware, take the time to carefully wire and label the circuits and don't try to make the circuit super small the first time. Make a larger prototype then when the design is stable make it small.

Have a "debug function" built in from the beginning. This might be print statements if the project is SW only, a couple of spare LEDs that you can blink in different patterns in different sections of code (to see if the If/Else statements are working correctly for example) or a serial port that spits out print statements to an LCD or PC. You need to be able to see if the code is working through the logic correctly.

IMO the most important thing to remember is that you will spend a LOT more time debugging, troubleshooting and modifying the system than you will writing the original code or building the original prototype. Make that job as easy as possible and you will avoid a lot of frustration.

Thank you for your interesting answers!

I am trying to put together an automatic plant watering system that will use recycled rainwater. I was thinking about using gravity to pour the water and use a small water hose on a gliding rail to move from plant to plant in a linear fashion with a valve to control the water flow. But I'm kind of going in every direction without anything concrete to really start on simply because I didn't know where to start.
I will try to apply what has been said in the posts above and see if I can get something done

It sounds like your assembly that slides on the rail is the heart of the system - start with that. How will you determine at what points along its travel water should be dispensed?

hfp777:
I was thinking about using gravity to pour the water and use a small water hose on a gliding rail to move from plant to plant in a linear fashion with a valve to control the water flow.

Why so complicated? Just run a small hose between each plant and seal up the far end. Punch a small hole in the hose near each plant (more than one for thirsty or larger plants). Use your arduino to control a pump (duration and/or pressure) dependent on the moisture content of the soil (has it rained today?), average ambient temperature (on hotter days, plants require more water.) and light level (you shouldn't be watering plants in direct sunlight. Dusk is the best time.) You could also use the arduino to keep a check on the level of water left in your rain butt so that it doesn't attempt to pump when there's no water left.