Help with Arduino project

Howdy, sorry if this isn't the place for this, but I'm really new to this, and would like some help. I've found some code that should work for what I'm working for, but I'm stumped when it comes to putting it all together.

Overview:
I'm looking to create a circuit for a Halloween costume, where a set of two flex sensors will be set inside fingers of a glove, a single adafruit pixel ring set inside the palm, and a sound system hidden in a set of robes. Unflexing both fingers of one of the gloves will turn the corresponding glove LED ring to fade in and flicker, as well as an audio file to play. A similar idea would be what people have built for Iron Man costumes for the hand repulsors.

Materials:
1x Arduino Uno R3
4x 2" Flex Sensors
2x Adafruit Neo Pixel Rings 12 LEDs
1x Adafruit "Music Maker" MP3 Shield for Arduino w/3W Stereo Amp

Reference Matieral:
I've found the following tutorials that provide part of what I'm looking for, at least in terms of code.

Fade LED tutorial - http://arduino.cc/en/Tutorial/Fade
Flex Sensor Tutorial - http://bildr.org/2012/11/flex-sensor-arduino/
MP3 Shield tutorial - https://learn.adafruit.com/adafruit-music-maker-shield-vs1053-mp3-wav-wave-ogg-vorbis-player
Adafruit ring tutorial - https://learn.adafruit.com/superhero-power-plant/overview


Again, the trouble I'm having is taking the provided code and putting it all together for my own needs- to where when one set of flex sensors goes to the unbent/off state, the corresponding LED ring slowly flickers on to 100% on, and an mp3 file starts playing.

I'd really appreciate any help that can be provided to this goal, even if its a helpful link to a tutorial.

You're going to need to provide a lot more info - at minimum pictures of your setup, pin usage, your entire code (please use

Engineers say "Divide and Conquer." In the Arduino world, this often translates into "Write Lots of Sketches."

The neat thing about Arduino code is it is so simple, you can write a code snippet, upload it, and then throw it away and write another. This use of "Sketches" (complete but tiny programs) is at the heart of the philosophy. You problem-solve, test, iterate, proof-of-concept with sketches, instead of using more traditional debugging tools on the longer, more complex final version of the code.

Write a sketch that causes the audio to play. Nothing else -- don't comment out, don't use function calls, just write six lines and upload it. The audio chip works and the sound plays? Throw that sketch away (but remember how you did it!). It doesn't play? Then you can solve the sound issue without having to wonder if it is a loose wire to a button, or your button code is wrong, or some other complicated function is getting in the way.

Same for the neopixels, same for the detector. Best first thing to do with the flex sensor is write something like;

serial.begin(9600);

void loop(){
howMuchFlex = analogRead(flexStrip);
println (howMuchFlex);
delay(5);

Turn on Serial Monitor in the IDE and take note of the values you get as you play with the flex strip.




When you get all the pieces working ON THEIR OWN, you can start to integrate -- using function calls is the simplest way towards clear and easy-to-maintain code in the Arduino environment, particularly because you only have to comment out the function call itself in order to turn off part of the behavior. As an example, say you aren't sure why the LEDs and sound aren't firing when the flex sensor reaches the target value. So comment out the sensor function and insert a line that forces the value to be "true':

if(i){
//FlexSensor(isFlexed);
isFlexed = 1;
...

I haven't assembled the project just yet- the issue I'm more concerned about is actually figuring out how to nest the codes in the provided tutorials together. I'll see to getting a schematic put up later today with what I've got in mind, but in terms of variables and port usage, what I figure will be used are two input ports for each set of flex sensors that will control their respective LEDs, and share custody over the MP3 shield.

As near as I can figure, here's the layout of the board. Please excuse the crudity of the design, but I hope it makes sense. The two LEDs on the left side of the board represent the LED rings from Adafruit, which feature a data in, out, power, and ground outlets. The two photo cells represent the flex sensors, and the purple leads represent data input/output wires. The MP3 shield appears to just sit on top of the arduino itsself, and should not interferre with port availabilty.

GIWillys said:

I haven't assembled the project just yet- the issue I'm more concerned about is actually figuring out how to nest the codes in the provided tutorials together. I'll see to getting a schematic put up later today with what I've got in mind, but in terms of variables and port usage, what I figure will be used are two input ports for each set of flex sensors that will control their respective LEDs, and share custody over the MP3 shield.

As near as I can figure, here's the layout of the board. Please excuse the crudity of the design, but I hope it makes sense. The two LEDs on the left side of the board represent the LED rings from Adafruit, which feature a data in, out, power, and ground outlets. The two photo cells represent the flex sensors, and the purple leads represent data input/output wires. The MP3 shield appears to just sit on top of the arduino itsself, and should not interferre with port availabilty.

View attachment 393051

Click to expand...

Quick thoughts (not guaranteed to be correct) --

1) Check the pinout for the MP3 shield. Most shields will indicate in the documentation which ports are active for that shield, and which are available for through use.

2) Neopixels can be daisy-chained. As I recall, they are fairly sensitive to serial timing so multiple instances of soft serial might be a problem. Safer to have them all off a single serial port and then code which set you want to be changing.

3) Hardware proof-of-concept like this is GREAT idea. Just remember the data write to the neopixels is a very different animal from the digital on/off you'll write to the test LEDs.

Actually, I would modify in one way; go ahead and use the test LEDs as described and keep them there as blinkenlights as you build and trouble-shoot the rest of the circuit. Just use a different port (or ports) for the neos, and each time you call the neos, call the LEDs as well. That will give you direct visual confirmation that your code is at least trying to do something LED-like at that moment.

4) Learn function calls. A little simplified, but basically you can wrap the "void loop()" aka main() of any code snippet in a void myArbitraryFunctionName() and then call it by that name. If all the function does is "write to LED" or "play sound" then "void" is fine. If it has to return a value, is slightly more complex.

The tendency is for example codes to be, well, badly written for examples. As in, lots of extra functionality, and lots of showoff bits that are not as self-documenting as they could be. I find example code often harder to read than simple test functions you write yourself.

GIWillys said:

I haven't assembled the project just yet- the issue I'm more concerned about is actually figuring out how to nest the codes in the provided tutorials together.

Click to expand...

That's not what tutorials are there for. They exist to teach you the concepts in them - not be copy and pasted together in a string. You should read and understand what the example code is doing before you try pasting a bunch of stuff together. Otherwise there is a near guarantee it won't work, and because you didn't learn what it was teaching, you won't understand why it isn't working or how to fix it.

I agree with nomuse, test out each individual component - lights, sound, etc. - and get each working independently. Then you should try stringing it altogether into a single thing. That way if it doesn't work, you will have knowledge and familiarity with the hardware and the sketch you wrote to troubleshoot on your own.

msleeper said:

That's not what tutorials are there for. They exist to teach you the concepts in them - not be copy and pasted together in a string. You should read and understand what the example code is doing before you try pasting a bunch of stuff together. Otherwise there is a near guarantee it won't work, and because you didn't learn what it was teaching, you won't understand why it isn't working or how to fix it.

I agree with @nomuse, test out each individual component - lights, sound, etc. - and get each working independently. Then you should try stringing it altogether into a single thing. That way if it doesn't work, you will have knowledge and familiarity with the hardware and the sketch you wrote to troubleshoot on your own.

Click to expand...

I wouldn't have a problem learning this if I had the time or skill with C++. As it is, I've got very little skill or knowledge with programming, and don't really understand the language that makes up C++.

I'm not necessarily asking someone to outright tell me how I should build this circuit, or to program it. I just need help understanding how I can take the relevant code from each set of instructions

I tried following the tutorial for the flex sensors I linked earlier; I wasn't able to get same/similar results and believe it has to do with the range they mention. In particular, I think that I may need to tweak the line "int flex0to100 = map(flexSensorReading, 512, 614, 0, 100);", as the author mentions "In my tests I was getting a reading on the arduino between 512, and 614. So the range isnt the best. But using the map() function, you can convert that to a larger range." The results I received did not vary much, but I got alternating results of 400 and -60/70.

Yes....in re the second part of your post, that's why I recommended you write a sketch that sends the flex sensor data in a continuous stream to the Serial Monitor. That way you can eyeball the numbers and get a sense of what the sensor is actually doing as per range. The map() function is essentially upsampling; it doesn't create more data, it just moves the points it has further apart. There's a few electronic tricks you can pull to get a larger dynamic range of the original analog signal, but it should be possible to use the sensor as is. Plenty of projects have.

On the code -- knowing bog-standard C can help a little, but only a little. Basically, it can give you grammar, and a conceptual framework. You don't really need to know C proper until you've gotten a lot deeper into the programs.

(Arduino/Processing/Wiring is more or less its own language, but the basic grammatical forms of C carry over (as they do for so many other similar-looking languages). The Arduino IDE (which is written in java, if I remember correctly!) is basically a high-level compiler that takes operations like "digitalWrite(led, HIGH);" and breaks them down into compilable C for the AVR chip selected (the above command works out to something like THIRTY LINES of C!) It is transparent to straight C, though; sometimes there are tasks you want to do in an Arduino that can only be done by writing closer to the metal, and in those cases you can insert bog-standard C inline with Arduino code and the compiler will respect it.)

I'd say the most complex concepts to grasp, outside of the basic mathematical functions, booleans, and program flow common to almost every language (aka the +, ++, =. ==, for, while, if, and other conditionals) is library use and function calls. Functions are defined bits of code that run when called and return values if requested. Libraries are collections of functions (not all of which are written in Arduino, or even in C) which are added to the list of resources for the compiler by the "inc" lines, and thus make available to your program body any functions defined within.

Arrays are also incredibly powerful for a variety of Arduino-typical tasks. Sure, you can look at arrays and strings as just being a subset of data types, but some people seem to have trouble conceptualizing arrays and every language has its own peculiarities about how they work with them (and string manipulation.....urgh!)



Anyhow, you can certainly do a little cut-and-paste, but example codes just tend to be too hairy to make this easy. They are there to be EXAMPLES. So instead of a nicely-behaved "do this when a button is pressed" they wrap the function you are looking for within a nest of "translate all these accelerometer readings into different manipulations of the effect."

Here's the best approximation I can come up with. Load up the example in question. Wire up the example circuit. Now start editing and remove every bit that you don't think you need. Stop when the example breaks. With trial and error and luck, you'll come up with a manageable bit of code you can cut and paste at that point.

Here's a few basic tricks:

1) Rename all the variables. Just pick your own names. This helps you check if you understand what each variable really does -- especially if you change the values a little when you re-name them.

2) Reduce the equations. Because of the nested, recursive nature of a lot of Arduino programs, you can truncate a lot if you make sure to take out the whole loop. Similarly, if nothing happens in a function except returning a variable, cut the whole function and type in a value manually.

3) Replace every complex output with a blinkenlight or a Serial write. If the example is supposed to compose a tweet, knock out EVERYTHING in that if() loop and type in a simple digitalWrite(led, HIGH) instead.

4) Whenever possible, divide the program into chunks. Comment out sections so you can probe just one bit at a time. Add multiple serial.println statements; "prinlin "I got to the part where it reads the flex okay" and prntlin "If the program got here, it triggered the IF statement". Add big delay() statements everywhere so you aren't wondering if the LED blinked and you missed it; use lines like "digitalWrite(led, HIGH); delay(2000);" to make sure the program hangs at that point for a good long while.

To tl;dr nomuse's post: The Arduino language is nothing like C++ and is designed for complete beginners to learn and understand. You are their target audience to not just copy and paste things together, but to actually learn and write things yourself.

I found Arduino a lot easier to grok than BASIC, actually! (It was Tandy BASIC, though -- running on a Trash-80).....

I might also suggest, from a design perspective, that you may wish to write out a state machine for the whole function of your prop.

Everyone thinks it is a very simple case of remembering what your prop should be doing, but I can't stress enough the importance of being able to look back and refer to a diagram that perfectly and clearly dictates what anything should be doing at any one time.

I'll use what I know. An example of a state machine covering a conveyor that has an inverter drive. On the conveyor is a sensor that detects a package/baggage. When the sensor goes high (ie. it has a package in front of it) I want to accelerate the conveyor to cleanly pass over to another conveyor. When the sensor goes low, I want to wait for a time to ensure the bag has left the conveyor, and then slow back down to nominal running speed. The state machine is as thus;

State 0: Conveyor Running Normal
TRANSITION: Rising Edge of Sensor Input detected
State 1: Conveyor Running Fast
TRANSITION: Falling Edge of Sensor Input detected
State 2: Conveyor Run Fast (with 1 second timer)
TRANSITION: 1 second timer finishes
State 0: Conveyor Running Normal

I usually display this diagram as a circular flow chart, so that the last State (State 2 in this case) feeds back to State 0 with the correct transition. Circles being the "states" and the lines between them being transitions. This allows you to fully think about your operation before you commit any code to computer, and is a great way to flesh out problems before they even happen. You also then have states, just like any machine does, that you can use to organise your code with. State 1 might require a function call, State 2 might require 2 outputs to fire after 3 different function calls etc. The nice thing is, you dont need to worry about any other state when you're writing one state. As it is naturally isolated.

Hi GIWillys,

Were you looking to have the 12 LED ring fade in and flicker with just a single color?

propmaster2000

.

Fawbish said:

I might also suggest, from a design perspective, that you may wish to write out a state machine for the whole function of your prop.
....

Click to expand...

Yeah, I'll second that for anything more than "light light and play sound every time you press trigger."

And even for that, it helps to draw a strip chart of when each sub-event starts in the trigger sequence and how long each runs.

Working implicitly as a state machine is what saved me on my Morrow Project CBR Kit; it allowed me to cycle through button position tests and writes to the vacuum fluorescent display and LEDs while "remembering" it was still in the Self-Test mode or in the middle of simulating detection of a radiological hazard or whatever (it had about six global modes, some of which were interruptible and some not.)

As Fawbish so elegantly illustrated, recognizing the transitions between states as distinct events (events which may take multiple cycles of machine code) is an important part of figuring out where your program flow is at various moments. If it sits in "delay()" for forty thousands of a second to debounce a trigger button, that is an interval where no writes are taking place to the displays; the patterns will freeze for that moment.

And I'm not putting this at all well. Where's that morning coffee?



CBR kit under construction.

I imagine if you explain exactly the behavior and timing desired of your prop, some nice person here might crank out pseudo-code or better. But without your specific hardware, such code would have to be tweaked. However, it would at least give you a conceptual framework (especially if said kindly person refrained from showing off with clever tricks like counter overflows or direct register writes...)

By exact, I mean defining it moment to moment:

1) Dark; main power is turned on, but prop is doing nothing visible
2) Power-Up Sequence; over ten seconds, plays sound sample #1, LED clusters on the sides go from dim to full on.
3) Ready; side panels "breathe" with 4-second cycle, 5.25 second idle sound sample loops continuously.
....