10 Arduino Mistakes Industrial Design Students Make the Week Before a Studio Review

The ten most common Arduino mistakes industrial design students make right before a studio review (loose breadboards, delay() traps, bad power plans) and how to fix them in an evening.

It's 2am on a Tuesday. Your review is Thursday morning. The beautiful object you've been modeling for six weeks is sitting on your desk, half-assembled and the LED that was blinking last night is now doing nothing. You have no idea why. You haven't eaten dinner.

This exact scene plays out every semester, in studio after studio, with forty different students and forty different objects. The object changes. The mistakes don't.

Here are the ones that show up every single time. If you're reading this on Tuesday night and you recognize yourself in more than three of them, put the soldering iron down, drink some water and fix the boring ones first.

1. Your whole circuit is held together by friction

You built it on a breadboard. It worked. Then you wedged the breadboard inside your foam-core model for the photo. You moved the model six inches. Something disconnected. You don't know what.

Breadboard jumpers are held in by a tiny spring clip. They fall out if you look at them wrong. They fall out especially if the thing they're inside gets carried up two flights of stairs, shoved into a studio and set down on a table by a tired person.

Before the review, anything that matters goes on perfboard or a bit of protoboard with actual solder joints. Yes, this feels like a huge step the night before. It takes less time than you think. Maybe an hour for a simple circuit. An hour is cheaper than a dead demo.

2. You planned to power the demo from your laptop

You walked into the review with a USB cable trailing out the back of the object like an umbilical cord. The professor asked you to bring it closer. You couldn't, because the cable wasn't long enough. You had to describe how it worked instead of showing it.

Every demo needs a power plan you tested yesterday, not one you're improvising in the moment. Options, roughly in order of how much they cost you in dignity:

Pick one on Monday. Test it on Tuesday. Don't switch on Wednesday night.

3. You trusted delay() and now your object feels dead

Your capacitive touch sensor should react to a hand, but there's a full second where nothing happens. Why? Because somewhere earlier in loop() you wrote delay(1000) for something unrelated and the whole program is just sitting there.

delay() is fine for the first blinking-LED tutorial. It is not fine for anything you want to feel responsive. Learn millis() before the review, not after it. If the difference between the two confuses you, the shortest version is: delay() is a nap, millis() is a clock. You check the clock in a loop and when enough time has passed, you do the thing. Your program keeps running in between, which means sensors keep reading, which means your object feels alive.

Responsive objects photograph and film better. Unresponsive objects look broken even when they aren't.

4. You're using a LiPo you don't know how to charge

Please. Seriously. If you don't know what a protection circuit is, or what "nominal 3.7V" means, or why you shouldn't charge a cell past 4.2V, just use a USB power bank for your first few projects. Power banks have all the battery management built in. They have a plastic case. They don't start fires in the model shop.

Bare LiPo cells are fine if you know what you're doing. You learn what you're doing before the week of a review, not during it. A 10000mAh USB-C power bank is fifteen dollars and will run almost any student prototype for the entire critique session.

5. One Arduino is doing three things at once and all three are bad

You wired a servo, an i2s microphone and a NeoPixel strip to the same Uno. The servo jitters whenever the LEDs update. The microphone picks up clicks every time the servo moves. Nothing feels right and you've spent three hours tweaking delays trying to fix it.

The real fix is noticing that NeoPixels and servos fight for the same timers on AVR chips, that analog mics hate PWM noise and that you're asking a 16MHz 8-bit microcontroller to do more than it signed up for.

The practical fix, at 2am: switch to an ESP32 or RP2040. They have more pins, more speed and separate hardware for most of this stuff. An ESP32-S3 dev board is cheap and will almost certainly make your problem go away without you having to understand timer conflicts at midnight.

6. There's a Serial.println inside your main loop

You put it in there three weeks ago to debug something. You forgot about it. Now your program runs half as fast as it should because it's waiting to write text out to a serial port that isn't even connected to anything.

Worse, on some boards (especially native-USB ones like the Leonardo or the XIAO), your code can hang forever at while (!Serial); if you ever added that line. You tested it with the cable plugged in. On demo day the cable is gone and your object never boots.

Grep your code for Serial before the review. Comment out the prints in loop(). Delete any while (!Serial);. Future you will be grateful.

7. Your sensor wires are thirty centimeters long and you're surprised by the readings

The sensor is at the front of the object for aesthetic reasons. The microcontroller is in the back because that's where the USB port goes. Between them, thirty centimeters of jumper wire runs past a servo and a switching regulator.

Those jumpers are basically antennas. They pick up noise from everything nearby. Your analog sensor looks like it's vibrating. Your i2c line drops a byte every few seconds and your display freezes.

Three things help, in order of how lazy you can be: twist the wire pairs together (works surprisingly well), use shielded cable for analog runs, or put a small microcontroller next to the sensor and send digital data back. The XIAO boards are tiny enough to hide almost anywhere and cost less than a nice coffee.

8. You soldered onto the breadboard layout without redesigning it

You took the prototype apart, laid perfboard next to the breadboard and copied the component positions exactly. Now your perfboard has wires crossing in three places, two bodge jumpers on the bottom and a capacitor that sticks up higher than the lid of your enclosure.

Breadboards are for thinking. Perfboards are for building. The two layouts should almost never look the same. Before you solder, spend ten minutes sketching the perfboard layout on paper (or in a free tool like DIY Layout Creator) with the real component sizes. Put the tall parts where the enclosure has space. Put the connectors where the cables will actually enter.

This saves hours.

9. You powered it from your laptop during testing and from a wall wart for the demo

It worked perfectly all week. You plug in the 12V wall wart in the studio. The Arduino resets every two seconds and the servo is twitching.

USB gives you a clean 5V at around 500mA. A random wall wart gives you whatever the label says, sometimes with a lot of ripple and sometimes not enough current for the inrush when your motor kicks in. Your regulator browns out, the chip resets, repeat.

Test with the actual power supply you plan to use at the review, days before the review. If you're using a motor or a servo, put a big electrolytic capacitor (470µF or 1000µF) across the power rail near the motor. It's the duct tape of electronics and it fixes a shocking percentage of these problems.

10. You have one unit, no spares and no backup video

One physical prototype. Zero backup plan. The professor picks it up, pulls the wrong wire and your entire final grade is now depending on how well you can explain something that used to work.

Every student should walk into a review with, at minimum:

The video is the part people skip. It's also the cheapest insurance you'll ever film. Five minutes, one take, no narration. If the live demo fails, you say "here it is working yesterday" and keep going. Reviewers don't care. They know prototypes are fragile. They care whether you can communicate the idea.

None of this is about being a better programmer. It's about respecting the gap between "it works on my desk" and "it works in a room full of people who want to touch it." That gap is where studio prototypes go to die and the fix is almost always something you could have done on Monday instead of Wednesday.

If you've got a review coming up and you want a shortlist of tools that will save you from half of the mistakes above, the best tools for ID students building interactive prototypes post is the next thing to read. Otherwise: power plan, perfboard, backup video, go to sleep.

Related Guides