I need a project or what do YOU use arduino's for?

[greywuuf]

I cant believe i am saying this, but I have no idea what I needed an Arduino for , let alone three work alikes and almost two dozen Attiny chips. SO heres the score, a Menta, two DC boarduino's, the adjustable bread board power supply, an FTDI friend, two Xbee pro's a Breakout board for the Xbee's and 10 each ATtiny 85's and 84's ( the 85's are dip and just to make things interesting I got the 84's as SOIC.... quite small )

I have big plans for a drone type autopilot board to go with my 1/2 scale gas engined Gyro copter... but even getting that flying is a ways down the road. I decided to learn about vacuum infusion molding with that and am having fun making a carbon fibre fuselage for it, and the rotor blades. I am not so much interested in home automation, or controlling my house from the web. I might try designing a timer/relay board/ temp monitor to control some hydroponics ( or a small aquarium scale aquaponics program) and I am also interested in maybe doing a few small stand alone camera's ( logging to SD or some such )


if anyone can think of something Fun/ or practical that I am overlooking please speak up. I am in need of something to focus on and Ihave some hardware to mess with!

What are YOU all using arduino's for ?


Dan

[adafruit_support_mike]

That's the trouble with general-purpose hardware.. if it can do just about anything, it's hard to narrow it down to a specific 'something' (NICE list of toys BTW).

Given your inventory and goals, I'd suggest you start with just the Menta and build a state machine. Start small so you don't overload yourself with bookkeeping, and make a device with two bits of memory, two bits of input, and six bits of output.. that all fits in a table of 16 chars and is surprisingly powerful.

Here's some sample code:

Code: Select all

/*  THE MACHINE:

    This is a two-bit state machine, meaning it has four possible states
    (00, 01, 10, 11).
   
    -  It has two I/O channels, each capable of sending and receiving
    one bit of information.
   
    -  It has four general-purpose outputs, each capable of sending one
    bit.
   
    For each combination of state and inputs, there's an 8-bit value in
    the lookup table.  That bit pattern breaks down like so:
   
                  next state --- vv
                                 ss cc oooo
      outputs to channels 1 & 2 --- ^^ ^^^^ --- general-purpose outputs

    To keep things simple, the main loop simply polls the input channels
    at a fixed interval.
   
    On each pass, the machine reads the input from both channels and
    combines that information with the state to select a bit pattern
    from the lookup table.  It uses that bit pattern to advance to a new
    state and send output to all the channels.
   
*/

#define     CH1_I   4   //  use pin 4 for input 1
#define     CH1_O   5   //  use pin 5 for output 1
#define     CH1_B   5   //  bit position of the output (as above)

#define     CH2_I   6   //  use pin 6 for input 2
#define     CH2_O   7   //  use pin 7 for output 2
#define     CH2_B   4   //  bit position of the output

#define     OUT1    8   //  use pin 8 for general output 1
#define     OUT1_B  3   //  bit position of general output 1
#define     OUT2    9   //  use pin 9 for general output 2
#define     OUT2_B  2   //  bit position of general output 2
#define     OUT_3  10   //  use pin 10 for general output 3
#define     OUT1_B  1   //  bit position of general output 3
#define     OUT_4  11   //  use pin 11 for general output 4
#define     OUT1_B  0   //  bit position of general output 4

void setup () {
    pinMode( CH1_I, INPUT );
    pinMode( CH2_I, INPUT );
   
    pinMode( CH1_O, OUTPUT );
    pinMode( CH2_O, OUTPUT );

    pinMode( OUT_1, OUTPUT );
    pinMode( OUT_2, OUTPUT );
    pinMode( OUT_3, OUTPUT );
    pinMode( OUT_4, OUTPUT );
}

char STATE = 0;

char LUT[16] = {
    B00000000,      //  state 0 + no input -> state 0
    B01010101,      //  state 0 + ch1 -> state 1
    B10101010,      //  state 0 + ch2 -> state 2
    B11111111,      //  state 0 + ch1 + ch2 -> state 3
     ...
};

void loop () {   
    char next = LUT[ readInput() ];
    STATE = stateFor( next );
    doOutputFor( next );
    delay( 1000 );
}

char readInput () {
    char s = STATE;
    s <<= 1;
    s += digitalRead( CH1_I );
    s <<= 1;
    s += digitalRead( CH2_I );
    return( s );
}

char stateFor (char s) {
    return( s >> 6 );
}

void doOutputFor (char s) {
    digitalWrite( CH1_O, (s >> CH1_B) ^ 1  );
    digitalWrite( CH2_O, (s >> CH2_B) ^ 1  );

    digitalWrite( OUT_1, (s >> OUT1_B) ^ 1  );
    digitalWrite( OUT_2, (s >> OUT2_B) ^ 1  );
    digitalWrite( OUT_3, (s >> OUT3_B) ^ 1  );
    digitalWrite( OUT_4, (s >> OUT4_B) ^ 1  );
}


NOTE: The lookup table isn't complete and I haven't tried to compile it. It's just 'general idea' code to get you started.

Play around with that until you're comfortable with it, then use one of your Boarduinos to do the I/O on channels 1 & 2. Once you're happy with that, use some of your Tinys as actuator controls that get a 'GO' signal from the Menta. Then expand the I/O channels so you can pass more than a single bit from one device to another. Then turn your second Boarduino into another state machine that gets control signals from the Menta. Then throw in interrupts and timers, other sensors, and more complex state-selection logic.

That kind of thing forms the core of most process control systems, and you should be able to adapt it for flight control, hydroponics or aquaponics without too much trouble. It's easy to throw LEDs on the I/O lines so you can see what the system is doing, and it's easy to plug in a board that generates signals so you can test your machine before hooking it up to the actual system it's supposed to control.

[greywuuf]

EXCELLANT suggestion,
I am still trying to understand it but still an excelant suggestion. I understand and can work out a truth table, but I am unclear on the next state concept...it seems as though you are trying to make it progress through each state sequencially. I may be mistaken, I did not have time to review it carefully but I will and I can certainly see myself going down this road and least for a ways. Thank you ! thank you very much. interestingly enough it gives me some increased insight into the genious of the "original" Lady Ada, as unless I am mistaken she advocated ( originated?) a state machine before the advent of electronics.

any more suggestions ? anyone ?

Dan in Alaska (keeping on keeping on, through 4 hours of daylight and -42 temps)

[greywuuf]

UGHHHHH!!!!!
My brain hurts. Mstone....not only Did you spark an interest in reaquainting myself with the Lady Ada Lovelace...(which is a painful matter in itself as social history is NOT my thing, as I dont particualrly like people on the whole ) I have also come to realize that I am failing to grasp the relevance of a deterinistic ( or non deterministic) State machine. it must be my rigid lack of an "artistic bent" as I can not for the life of me see the need ( for myself) to ever work with strings in such a fashion. Maybe I am to short sighted to understand the power of patterns or something. I can readily grasp the concept and power of a truth table.....listing all the possible combinatons and the results..... or even an array,,,,but I cant seem to mesh a state machine with

" if a switch is closed I want this output, if both are closed I want some other output."

I dont seem to get how knowing after all is said and done if the last thing done was this or this is important... I kind of want to react to ALL of the switching.
Also in your example I dont grasp why there are six outputs to match only 4 possible states


Can some one Dumb this down for me? Is the purpose of a state machine to operate on any state change ? or only as the one article I read the resultant state ( had to do with string matching and patterns it sort of left me feeling that a state machine was an answer in search of a specifc problem to answer)

I thank you for the suggestion, and I feel rather sheepish that I can not after several hours of research even grasp the concept enough to continue with the code you have provided, and I would love to discuss it further as there is nothing I hate worse than NOT understanding.

Thank you again

Dan

[greywuuf]

I guess I should ammend my previous confusion , you siad this .....

and make a device with two bits of memory, two bits of input, and six bits of output..

italics mine, after looking again I assume you meant Sixteen ? as there are 4 digital outs?

[adafruit_support_mike]

UGHHHHH!!!!!My brain hurts.

That's a normal first reaction.. In their raw form, state machines are too abstract to make much sense. They're easier to grok if you assign meanings to the individual states and transitions. That reduces the central operating principle to "if I'm here, and I see that, go there."

To make things more specific, let's work an example: say we have a kit that uses LEDs and current-limiting resistors. We want those to be paired, and we have a vibrator bowl that will bring parts to us one at a time. We've just walked into the workshop to find Igor dumping a bag of LEDs *and* a bag of resistors into the bowl.

Rather than freaking out, we pat him on the hump and pull out some hardware. With a bit of tinkering we make a device that can tell resistors from LEDs (two leads on one end -vs- one lead on either end), put that at the vibrator bowl's output, and hook it up to state machine.

To test it, we start running parts through and keep track of what we've seen. In this case, we have four states we care about: "haven't seen anything yet", "saw a resistor, still need an LED", "saw an LED, still need a resistor", and "saw a complete pair".

- The machine starts in "haven't seen anything" state. If the next part is a resistor it moves to "saw a resistor", if the next part is an LED, it moves to "saw an LED".

- If the machine is in "saw a resistor" state and sees another resistor, it stays in the same state. If it sees an LED, it moves to "saw a complete pair".

- If the machine is in "saw an LED" state and sees a resistor, it moves to "saw a complete pair". It it sees an LED, it stays in "saw an LED".

- If the machine is in "saw a complete pair" state, it can go back to "haven't seen anything" no matter what it sees.

That's nice, but it doesn't pack kits. To do that, we need some 'auxiliary outputs'.. values that are associated with a transition from one state to the next, but don't change the way the basic machine works. In this case, we want to add a couple of servos with cups that will catch and move parts.

The first servo catches parts directly out of the resistor-or-LED recognizer. If you send it one signal, it tips the part back into the bowl. If you send it another signal, it tips the part into the second cup. The second cup catches parts from the first, and dumps them into the kit bag.

Running through the states again to add the auxiliary outputs, we get the following:

- If the machine is in "haven't seen anything" state and sees any part, we want servo 1 to tip the part into servo 2's cup, and we want servo 2 to stand still.

- If the machine is in "saw a resistor" state and sees another resistor, we want the machine to stay in the same state, we want servo 1 to tip the part back into the bowl, and we want servo 2 to stand still. If the next part is an LED, we want to move to "saw a complete pair" state, we want servo 1 to tip the part into servo 2's cup, and we want servo 2 to stand still.

- We want the same actions the other way for "saw an LED" state.

- If the machine is in "saw a complete pair" state, we want servo 1 to tip the next part back into the bowl no matter what it is, we want servo 2 to tip the pair we've collected into the kit bag, and we want the machine to go back to "haven't seen anything" state.

Reducing all that to numbers, we can have the parts recognizer give us a 0 when it sees a resistor and a 1 when it sees an LED. We can define the states as: 00 (haven't seen anything), 01 (saw a resistor), 10 (saw an LED), and 11 (saw a pair). When we combine the states with inputs, we get keys into a lookup table:

- 000 (haven't seen anything, next part is a resistor)
- 001 (haven't seen anything, next part is an LED)
- 010 (saw a resistor, next part is a resistor)
- 011 (saw a resistor, next part is an LED)
- 100 (saw an LED, next part is a resistor)
- 101 (saw an LED, next part is an LED)
- 110 (saw a complete pair, next part is a resistor)
- 111 (saw a complete pair, next part is an LED)

Our basic state machine would tell is what state to choose for each condition:

{ 000:01, 001:10, 010:01, 011:11, 100:11, 101:10, 110:00, 111:00 }

and then we can tack on the following auxiliary bits:

- servo 1: tip the part into the bowl (0)
- servo 1: tip the part into servo 2's cup (1)
- servo 2: stand still (0)
- servo 2: tip the parts into the kit bag (1)

which gives us the following bit pattern for the whole machine:

{ 000:0110, 001:1010, 010:0100, 011:1110, 100:1110, 101:1000, 110:0001, 111:0001 }

That table is an extremely consise way of expressing everything I said above.

That's a two-bit state machine with one bit of input and two bits of auxiliary data. We can extend the auxiliary data as far as we want without having to think too hard, since it doesn't change the actual machine. Say we want to add an RGB LED that shows us what state the machine is in ( 00:red, 01:yellow, 10:cyan, 11:green ). We just tack the appropriate RGB values onto the end of the values in our transition table like so:

{ 000:0110100, 001:1010100, 010:0100110, 011:1110110, 100:1110011, 101:1000011, 110:0001010, 111:0001010 }

The item '011:1110110' parses out as '[state:01][input:1]:[move to state:11][servo 1:1][servo 2:0][rgb:110]'

[adafruit_support_mike]

after looking again I assume you meant Sixteen ? as there are 4 digital outs?

Hopefully this makes a bit more sense after the (humongous) example. If we only use two bits for state, the remaining six bits of an 8-bit byte (a char in C) will be auxiliary bits. We can combine those any way we want, but it will always parse out as:

[state:xx][input:xx]:[move to state:xx][everything else:xxxxx]

For the specific machine I half-coded earlier, the parse is:

[state:xx][input 1:x][input 2:x]:[move to state:xx][output 1:x][output 2:x][misc aux bits:xxxx]

[greywuuf]

The example makes sense, however i think I am getting hung up on semantics......when you say " next state" or "move to state" that throws me, as these are only possabilities. It seems that I am only going to act on something WHEN a state change occurs and i can not predict what the next state is going to be. I will think on it some more and see if i can not make sense of it, I admit to not having spent much time on it lately as i got my xbee's in the mail and I was programming an ATtiny85 to work with it, and building a programming shield for my menta ( which I managed to brick )

Also I am not good at or familiar with "C" so i am having to spend a lot of time on your code schooling myself on the bitwise portions....I will get there.

Thank you SOOOO much for taking the time to have this conversation with me.

Dan

[adafruit_support_mike]

The example makes sense, however i think I am getting hung up on semantics......when you say " next state" or "move to state" that throws me, as these are only possabilities. It seems that I am only going to act on something WHEN a state change occurs and i can not predict what the next state is going to be.

Basic rule of state machines: The next state is completely determined by the current state and the input.

Think of it as a pub crawl with some randomness thrown in to make it more fun: Every time you enter a bar, you have a beer, then flip a coin that decides where you'll go next.

- Everyone starts at The Vine, has a beer, and flips a coin. Those who flipped Heads go to Murphy's. Those who flipped Tails go to The Deadwood.
- If you're at Murphy's, Heads will send you to John's, Tails will send you to Qito's.
- If you're at The Deadwood, Heads will send you to Qito's, Tails will send you to Murphy's.
- etc

There *is* a fencepost issue with states and transitions.. every transition has two states at its ends: the one you just left and the one you just entered. People have faffed around to the point where you can make good arguments for:

- actions you take as soon as you enter a state (like ordering a beer as soon as you enter each bar).
- actions you take while in a state (drinking the beer)
- actions you take before leaving a state (pay your bill, tip the bartender)
- actions you take before starting a transition (make sure you have the whole group)
- actions you take during the transition (sing loudly so everyone knows it's a pub crawl)
- actions you take before ending a transition (stop singing far enough away that the bouncer will let you in)

The example I gave used 'during the transition' actions because those are easiest to store in a simple lookup table. They're functionally equivalent to:

- If you're walking from The Vine to Murphy's, sing "I Want to Break Free".
- If you're walking from The Deadwood to Murphy's, sing "We Are the Champions".

I will think on it some more and see if i can not make sense of it, I admit to not having spent much time on it lately as i got my xbee's in the mail and I was programming an ATtiny85 to work with it, and building a programming shield for my menta ( which I managed to brick )

Ouch.. good luck getting it back.

Also I am not good at or familiar with "C" so i am having to spend a lot of time on your code schooling myself on the bitwise portions....I will get there.

Oh geez.. I was bitmasking there wasn't I? Sorry.

- The '&' symbol is a logical AND.
- Logical OR is '|'
- XOR is '^'
- '<< N' means 'shift left N bits'
- '>> N' means 'shift right N bits'.

You can write bit patterns explicitly with the 'B0101010' notation. Hex looks like '0x1234abcd', and octal is '0777'.

I don't recall if I used these, but C also has 'assignment operators' which are just syntactic sugar to save some typing: "x <<= 1" means exactly the same thing as "x = x << 1". We tend to pronounce the first one "left-shift x by one" and the second one "x equals the value of x shifted left by one."

Thank you SOOOO much for taking the time to have this conversation with me.

Deeply ingrained 'academy' mindset (state your thesis then defend it from all challenges) combined with lots of kung fu movies (same basic idea, slightly more kicking, slightly less screaming).

[greywuuf]

I am usually pretty good at following a program figuring what it will do if I understand the operations....or figuring the operations from what the program does (and they are in the referance material. But when I am unclear on both it is a little harder
Good note on brick'n the MENTA, I have all ready been messing with ups programmers (arduino as an ISP) and have gotten good at it....3 bucks an I am back in business.

Hang with me I am sure to code this out and mess with it, just going to take me some time both to figure out the language and the concept.....thank you again.

[greywuuf]

- 000 (haven't seen anything, next part is a resistor)
- 001 (haven't seen anything, next part is an LED)
- 010 (saw a resistor, next part is a resistor)
- 011 (saw a resistor, next part is an LED)
- 100 (saw an LED, next part is a resistor)
- 101 (saw an LED, next part is an LED)
- 110 (saw a complete pair, next part is a resistor)
- 111 (saw a complete pair, next part is an LED)

Our basic state machine would tell is what state to choose for each condition:

{ 000:01, 001:10, 010:01, 011:11, 100:11, 101:10, 110:00, 111:00 }

That parts seems to be key to my understanding, ie: if I just got that it would make sense

How do you go from a two bit state with a a single bit input, to a three bit number with a two bit index?

I realy am trying hard to grasp this but I keep failing the little leaps like this. I have tried several times to complete the look up table you started but I fail to be able to expand the concept to two inputs ... it almost seems like I need to pre define what is going to occur .. am I wiating for a coin cell and a holder or a on/off switch ( for a delux kit, and none for a basic kit ? to use your example

[adafruit_support_mike]

That parts seems to be key to my understanding, ie: if I just got that it would make sense

Sorry for the late reply.. the thread kinda fell down the page a bit.

How do you go from a two bit state with a a single bit input, to a three bit number with a two bit index?

It's the other way around: the three-bit part that comes first is the index into the lookup table. The two high bits of the index are the state number, and the low bit is the input value. The two bit value to the right of the colon is the number of the next state.

To demonstrate, let's just declare that the machine is currently in state 0 and that the next part is an LED. That gives us the bit pattern '00' for the state number and '1' for the input. We combine those to make '001', which is our index into the 'what state do I use next?' lookup table. To condense the notation, I'm going to reduce the bit pattern to decimal and use TRANS[n] to mean 'the nth value in the lookup table'.

TRANS[1] is '10', so our next state (reducing binary to decimal) is state 2.

So now we're in state 2 and the next component is another LED (input '1'). The bit pattern for our next lookup will be '10' combined with '1' to make '101' = 5. TRANS[5] = '10', so our next state is state 2 again.

Again we're in state 2, and the next component is a resistor (input '0'). The bit pattern for our next lookup will be '100', and TRANS[4] = '11'.. so we advance to state 3.

Now we're in state 3 and the next input is another resistor (input '0'). The bit pattern for our next lookup will be '110' and TRANS[6] is '00'.. so we advance to state 0.

I realy am trying hard to grasp this but I keep failing the little leaps like this.

The little questions are the killers.. there's always one that focuses "do I understand this or am I totally confused?" into a hot little ball of frustration.

In my experience, this is one where comprehension sort of sneaks up on you.. instead of a grand 'aha!' moment, you get the 'empty carton in the fridge' effect when you reach for the next "I don't get it" and realize you can't find one.

I have tried several times to complete the look up table you started but I fail to be able to expand the concept to two inputs ... it almost seems like I need to pre define what is going to occur .. am I wiating for a coin cell and a holder or a on/off switch ( for a delux kit, and none for a basic kit ? to use your example

It's an alternating sequence: First you get a state, then you get an input. Combining those gives you enough information to choose the next state. Then you wait for an input again.

You do have to prime the pump by just declaring "I'm starting in state X dammit!", but from there it's all 'read the input to calculate the next lookup table index', 'read the lookup table to find the next state', 'read the input to calculate the next lookup table index', etc.

[greywuuf]

OK, I think I have it now. It was purely a semantics thing, and a mental block on my part. Was getting hung up on "next part" and "next state" we actually are IN a state and actually HAVE an input (001) and that results in the "next state" (:01) quite simple once I quit being "thick"

I am still unclear on the second input expansion......as to me that would result in more possible states, either that or I need to know what I am defining (not a general propose thing)

In other words I have defined the resultant states for each of the single inputs but it is not intuative to me what state will result from a second input.....or is that up to me to define?

[adafruit_support_mike]

OK, I think I have it now. It was purely a semantics thing, and a mental block on my part. Was getting hung up on "next part" and "next state" we actually are IN a state and actually HAVE an input (001) and that results in the "next state" (:01) quite simple once I quit being "thick"

You've got it, and there's no 'thick' about it. Getting the ideas to interleave properly takes some time.

It's 'fencepost' logic.. you have to remember whether you're dealing with the posts or the spaces between the posts. And like they say: "there are only two really hard things in programming: cache invalidation, choosing good names, and off-by-one errors."

In other words I have defined the resultant states for each of the single inputs but it is not intuative to me what state will result from a second input.....or is that up to me to define?

You're probably getting caught by my sloppy use of the term 'input'..

Technically, state machines use 'input symbols'.. the machine I've used for discussion so far has two: 0 and 1. I've combined those under the name 'input signal' or 'input channel', both of which are synonyms for the official concept of an 'input variable'.

Variables are a human thing.. they allow us to assign meaning to groups of input symbols: "the signal on this wire tells me whether the sensor sees a resistor or an LED". The underlying concept is called 'representation' or 'interpretation', and it's one of the bottomless pits of computing theory.

Machines don't 'understand meaning', they just chug through the patterns of symbols you feed them, so all any digital machine sees is a bit-vector. Being able to translate between human meanings and machine-navigable bit patterns is the fundamental skill in computer programming.

The machine-navigable units of a state machine are 'states', 'input symbols', and 'transitions'. In hardware -- especially digital circuits -- the states and input symbols will always be fixed-width bit vectors.

A transition is a function that takes a state and an input symbol as input, and produces a state as output:

Code: Select all

state = transition(state, input);

So, with all that out of the way..

Adding new input symbols will force you to define new transitions.. you have to do something with the input or you may as well not collect it. The mapping itself -- the output of transition(state, new-input) -- is something you choose.

Every state needs a transition for every possible input symbol. If you miss one, transition(state, input) will return 'WTF?' and your machine will probably crash.

The maximum number of states you can have is the same as the number of possible transitions. That kind of machine isn't very interesting though, because it only has one input symbol. There's no "what should I do with this input?" choice at any point, so you can reduce the machine to a simple list of instructions.

The largest useful number of input symbols is equal to the number of states. If you have more symbols than states, some collection of input symbols can be reduced to a smaller number of symbols.

The simplest way to implement a transition() function is with a lookup table, and that table will have (number of states) x (number of input symbols) entries. I did it using a one-dimensional array and mapping 'state + input' to the index value, but you could also use a multidimensional array like so:

Code: Select all

state = transition[state][input1][input2]...

[greywuuf]

Hmmmm,
I went back to the code and got dense again. Now I am having trouble correlating the "actual condition" the machine is in to the look up table

IE:

- 000 (haven't seen anything, next part is a resistor)
- 001 (haven't seen anything, next part is an LED)
- 010 (saw a resistor, next part is a resistor)
- 011 (saw a resistor, next part is an LED)
- 100 (saw an LED, next part is a resistor)
- 101 (saw an LED, next part is an LED)
- 110 (saw a complete pair, next part is a resistor)
- 111 (saw a complete pair, next part is an LED)

Our basic state machine would tell is what state to choose for each condition:

{ 000:01, 001:10, 010:01, 011:11, 100:11, 101:10, 110:00, 111:00 }

this I get... ( I think)

but this ( which comes from the code you wrote) again does not quite click with me yet

char LUT[16] = {
B00000000, // state 0 + no input -> state 0
B01010101, // state 0 + ch1 -> state 1
B10101010, // state 0 + ch2 -> state 2
B11111111, // state 0 + ch1 + ch2 -> state 3

I do not understand why the look up table witll be usefull when they dont add up .... either that are we are not looking up yet....for instance B01010101 to me says state one input one and outputs on chanels 1 and 3 ..... where did that come from ? so that is the result ot the look up ? not the index in ? because you the comment says state Zero .....getting closer , actually working towards understand the code now... and not just the concept