Show Posts
Pages: [1] 2 3 ... 48
1  Using Arduino / Programming Questions / Re: H bridge controller moves fast in one direction only on: July 26, 2014, 11:21:59 pm
I'll bite.

I was looking at these H bridge drivers and don't like them for the simple fact they have no build in safeguard that both pins aren't high at the same time and "POW!"  You kill the drivers.

They should be better designed....   But anyway.

How are you testing the voltage levels?  With a meter?  With or with out a load?

Get the H Bridge powered up and manually stimulate the inputs.
OF COURSE don't put them both high at the same time!

Set it to go one way then the other.
See what happens.

Is it the circuit "pulling" the arduino's output lower?  (Or:  Is it "shorting" the pin to ground?)

What I would do to cover my self is use a logic gate to prevent both pins ever being high at once.
An XOR gate on one of the inputs would/should suffice.

2  Using Arduino / Programming Questions / Re: INT, BYTE, CHAR, help with maths. on: July 26, 2014, 11:12:05 pm
OK, sorry Peter.

The X and Y values are what come out of the "thingy" which are probably degrees of X and Y.

Or Pitch and Roll.

ZVO is a "Zero Value Offset" so when the X and Y are at zero, the arduino adds this to turn on LED 3 and 9.
I made an excel spreadsheet to test the maths and it works until you are changing the values less than 30 degrees.

OS is the OffSet which I mentioned and also said isn't used yet.

LED_Loop is how many leds in the loop.
QL is .........  12./4 in this case.

The input range is probably going to be -90 to +90 from the "thingy" with which I have played so far.
3  Using Arduino / Programming Questions / INT, BYTE, CHAR, help with maths. on: July 26, 2014, 10:48:20 pm

I am off on another project.

This needs a bit of maths behind it and although I think I have that part down, just putting it in a way Arduino understands is a bit difficult.

The sketch so far is WORK IN PROGRESS, so don't bombard me with "things are missing".

I am posting it here to get help on what I need to define/declare the variables as.

Now, I am trying to build structures into my code to maybe become a better programmer.  Who knows?

Alas the code is called V1 - as it is version 1.
HSI is one of the sub-routines.  Well, the only for now.

It should be self explanatory but just in case:
I have my little Accelerometer/GYRO/thingy sitting there and I turn it on.

Skipping "Zero-ing" it, apart from that in the code,  it works out how to show attitude on an LED ring.
(From ADA fruit and each LED is addressable, controllable, etc..  LED NEOPIXEL)

Given that pitch is 0 to +90 or 0 to -90 I calculate how to "share" the leds to values.
There is a Zero Value Offset to tell the program where to show level.
The other offset is if LED #1 is not at the top.  (Not used just yet)

Roll I shall hope is the same for values.

Excuse the BASIC way I have done it for now, but as the code said:  BASIC PITCH.

There in lies the problem.
0 - 30 is one LED, 31 - 60 is another and 61 - 90 is the third.
Not really good.

Yes, INT() doesn't help.

So if I do (what I seem to remember as "single precision") I will then be able to work out if I need to show TWO LED's.
But what is that in Arduino lingo?

I "need" -90 to +90 range on these two axis.

Sure I can "cheat" and make it 0 - 180 and "-90" from what comes out.
What ever.....

Could someone please help me with this small sticking point?
Thanks in advance.
4  Using Arduino / Microcontrollers / Re: I want to be sure before going to the next step..... on: July 20, 2014, 03:15:21 am

Two replies.  One says yes and the other is concerned with the drivers required.

I dont understand the specifics of the CH340 but a search implies it is the chip used on the board to "decode" the USB signals.

I can see the drivers listed on the web, so I am confused about the concern.

5  Using Arduino / Microcontrollers / I want to be sure before going to the next step..... on: July 19, 2014, 06:11:37 pm
I want to be sure this board will "work" before going to the next stage of project building.

I have a few SMALL projects on which I am working.

If this *IS* arduino compatible for programming, pin I/O (digital/analogue I/O etc) I will be very happy.

(And when/if I get one, what is it called in the board drop down menu?  I've never looked before as I have never changed it.)
6  Using Arduino / Sensors / Re: Long distance motion sensor on: July 17, 2014, 05:56:03 pm
My two cents worth:

It has been suggested a high power IR beam and reflectors......

Another option would be a laser around the edge of the fence.
Reflectors - as with the other idea - and a sensor.

If anything breaks the beam, the alarm goes off.

Yes you probably will get a few errors, but maybe make it multiple beams a good distance apart so grass can't break ALL/BOTH beams.

Then if an animal walks through the beam/s the alarm goes off.
7  Using Arduino / Sensors / Re: My MMA 7361 story. on: July 17, 2014, 02:54:27 am
Thanks folks.

So to ask again about "how to tell it it is level" when it isn't.

This way when I turn it on and it isn't level, I can tell it that this is level.

To do that initially, I have to adjust the "OFFSET" values.

But when the sketch is running, I am wanting to have a button to tell it "This is level" and it adds the right values.

Ok, not rocket science, but would appreciate a bit of help.

8  Using Arduino / Sensors / Re: My MMA 7361 story. on: July 12, 2014, 01:21:10 am

That may be the solution/explanation I needed.

So it is an accelerometer but its reference is EARTH, and NOT itself.

Now I get it.

Is this the same with ALL flavours or just some?

Are some "relative to themselves"?  So ROLL is ROLL irrespective of attitude?

Now, onto the other point about what is and isn't acceleration:
Ok, I accept that "rocking and rolling" the device is acceleration on the X and Y axis.

I'm still stuck on the Z.  Is that "Spinning" it?  With the leads I have, it isn't an option just now, nor is it really needed at this stage.

So what "device" would I need to measure linear acceleration?  Like in a straight line and getting faster/slower.

That aside, on a side to the initial project:  A self levelling platform.
I have learned that when you "boot up" the sensor, how it is oriented is called "level".  This is ok in some applications but not all.

What am I missing so when it boots up it will detect itself NOT being level and so adjust so that it "activates" outputs to make itself level?

That is one project.
Another is pretty much the exact opposite in how it does things.

It will be a box which shows horizontal attitude, and it is PORTABLE!
So when I set it down, and it isn't level, I "tweak" knobs to adjust it so it shows me level.
Or can that be done in a similar way to the first question but instead of outputting to motors/what ever, it changes internal values and makes that the new level?

Thanks though jreminton.  Your reply sorted out the local confusion.
9  Using Arduino / Sensors / Re: My MMA 7361 story. on: July 11, 2014, 04:45:56 pm
Ok, thanks.

It is not that I am being dismissive, but in the mean time I have been "Playing" with it and am still a bit confused.  (thus my name)

It is a THREE axis ACCELEROMETER.  Meaning it measures acceleration.

Initially I was annoyed with my self for getting it as my first use was to make an auto levelling platform.    Why?  Dunno.  Maybe for the sake of it.

Anyway, The three axis:  X Y and Z.

To expand on the axis names, let's call them:  Pitch, Roll and Yaw.

So I have the script/sketch running and the sensor is there:  Level.

X and Y are 0, or there about.

I Pitch up the sensor, X values go up.

Pitch down, and the numbers go negative from 0.

Looks good.

Same with Roll.

Now, to me that isn't acceleration.  Although I am happy it is doing what it is.
I thought "acceleration" was It is sitting there and I MOVE it forward, backward, left or right.  (Keeping to only the two axis for now.)

The Z axis is if I lift it up or down.

So, back to my confusion:

 If I Pitch the sensor to the vertical X is showing 90.  Good.
Then!  While at 90 degrees, I ROLL it:  NOTHING changes.  Or at least the Y stays the same,

Now to explain that a bit further and clarify it:
The roll I am doing is RELATIVE to the sensor, and when it was level rolling it changed the Y values.

Why aren't they being changed when the sensor is vertical?

There may be an argument that at the vertical there isn't any discernible change, but that is only true if you are doing compass headings.

I am not.

Can someone please help me with this confusion?
10  Using Arduino / Sensors / Re: My MMA 7361 story. on: July 10, 2014, 04:27:46 pm
Well, thanks for the help.

I thought 1 G was 9.8 m/s

G*10^-2 is a formula.  Not a number.

Where is G defined in the line of data?

And it would be nice if you had maybe helped me understand what is going on with the Z numbers.
11  Using Arduino / Sensors / My MMA 7361 story. on: July 10, 2014, 05:05:03 am
So as to not take over someone else's thread, this is mine.

This is my sketch:

#include <AcceleroMMA7361.h>

AcceleroMMA7361 accelero;
int x;
int y;
int z;

void setup()
  accelero.begin(13, 12, 11, 10, A0, A1, A2);
  accelero.setARefVoltage(5);                   //sets the AREF voltage to 3.3V
  accelero.setSensitivity(LOW);                   //sets the sensitivity to +/-6G
//  accelero.setOffSets(18,11,100);

void loop()
  x = accelero.getXAccel();
  y = accelero.getYAccel();
  z = accelero.getZAccel();
  Serial.print("\nx: ");
  Serial.print(" \ty: ");
  Serial.print(" \tz: ");
  delay(500);                                     //make it readable

This works better than my posts in the other thread.

This is what I get from it with the sensor as level as I can get it.

Calibrating MMA7361011..................................................
x: -4 y: 0 z: 100 G*10^-2
x: -3 y: 0 z: 100 G*10^-2
x: -3 y: 0 z: 101 G*10^-2
x: -4 y: 0 z: 101 G*10^-2
x: -4 y: 0 z: 101 G*10^-2
x: -4 y: 0 z: 101 G*10^-2
x: -5 y: 0 z: 101 G*10^-2
x: -5 y: -1 z: 97 G*10^-2
x: -3 y: 0 z: 101 G*10^-2
x: -4 y: 0 z: 101 G*10^-2
x: -4 y: 0 z: 102 G*10^-2
x: -4 y: 0 z: 101 G*10^-2
x: -2 y: 0 z: 103 G*10^-2
x: -4 y: -2 z: 98 G*10^-2
x: -3 y: 0 z: 101 G*10^-2
x: -3 y: 0 z: 100 G*10^-2
x: -3 y: 0 z: 101 G*10^-2
x: -3 y: 0 z: 101 G*10^-2

Very good.
If I turn it upside down, the Z goes to -99.

I am still slightly at odds the Z "axis".  I know/understand PITCH ROLL and YAW.

"Spinning" the board (back and forth) on it's Z axis (YAW) nothing really seems to happen.

So why does it go to -99 when upside down?

When it is PITCHED to 45 degrees, the X goes to 45.
ROLLing it side to side the Y "tracks" the movement.
I'm not too sure what Z is doing , but I think it is reducing.

When I PITCH it to vertical X is 90 - fair enough - but "ROLLing" it Y doesn't move.  I think Z starts to track ROLL.

Could someone help me with what is going on?

I think it is working correctly it is just I am having trouble getting my head around the data.

The G scale also confuses me.

Thanks in advance.
12  Using Arduino / Sensors / Re: Help with IMU on: July 10, 2014, 03:09:35 am
The ONLY problem is just sampling rate and trying to increase it, unless you know of another way for me to capture more gyro data?

Again, I shall state that if you go from INT to LONG you are NOT making the samples faster, but slower because there are more numbers to "crunch".

You didn't explain your reasoning on sample rates I mentioned.  (Notes 1 and 2 in my first post)

Good luck with it all and I really hope you get it going.
13  Using Arduino / Programming Questions / Re: Still a bit stuck with { }, return and exit. on: July 10, 2014, 12:35:00 am
Hi guys.

Thanks very much for the help.

I have "shot my self in the foot" with some code I am writing now, so I shall fix it up.

I am sort of coping with variables pretty good, and am trying to do things in a constant way so as to "learn" that pattern.

It is (probably/most likely) different to the INDUSTRY STANDARD way, but hey:  If it works.

My style of programming has really changed since I first started writing code, and I hope for the better.

I am waist deep in a couple of projects just now and needed to really get this resolved to stop future problems.

So:  Onward and upward, I hope.
14  Using Arduino / Programming Questions / Still a bit stuck with { }, return and exit. on: July 09, 2014, 11:32:45 pm
Yeah, I am going to cop some flack for this, but hey......

I'm still learning.

Brief explanation of my "problem":

C is "different" to BASIC in that you write the code in blocks.
Although this can be likened to "sub-routines" in basic there are differences in how the code is defined.

In BASIC you RETURN from a sub-routine and any values are GLOBAL.

C is very different that variable names are local to that routine and passing variables is done a bit differently.

However, the "blocks" of code.

You start with something like:
(Indulge me)

    //  code here

So when I am writing a program it looks like this (sort of):

     // things happen here

     //  a bit more stuff

     // and some more stuff here.
    int(j) = routine_3();
    if(j == 1)
          // what ever
     //  and so on.

Now "routine_1" is a bit of code which is used in many places in the "bigger picture" of the code.

It is made into a routine to save space and reduce duplication of lines.
I get that.
But "how" do I write "routine_1" (and others) code?
Hang on!

So, the routine_ would be like I posted above.
It starts with a name and the {
The first line says if it returns a variable by either having an INT, VOID or other prefix.
How it parses variables is done after the name, like this:  (for instance)
routine_1(int var_1)

Tells it that there is nothing returned and that VAR_1 is given to it.

So: When I an done writing routine_1, how do I "end" it?

Is it simply to "close" off the { }'s?
Or do I "exit"?

Yeah, dumb question, but some one has to ask them.
May as well be me.
15  Using Arduino / Sensors / Re: Help with IMU on: July 09, 2014, 04:20:23 pm

I too am new to this sort of stuff but a couple of things I would like to add:

1 - you gave an example of some code in an early post:
WIRE_SEND(0x0A);  //  SMPLRT_DIV = 10 (50Hz)

Then you went on to say:
WIRE_SEND(0xFF);  //  SMPLRT_DIV = 255 Now will this give me better tracking?

Ok, I'll bite.  How do you get that?

I accept that 0A (hex) is 10 decimal; and with an unseen equation you get 50 Hz from it.
But FF (hex) is 255 decimal, and you get 255 Hz sampling?     Care to check that reasoning?

2 - You are waning FAST readings.
You then go on to say you are making the numbers LONG.
Going from INT to LONG isn't going to make it quicker.  As someone said, it will actually slow it down, as LONG takes more time to compute.

What I THINK you want to do is keep things simple and leave the values as INT but sample them quicker.

End of my two thoughts on that.

Couple of other things I suggest:

Get the I2C scanner program and check it is being seen.  Make sure the address is correctly "modified" in the routine.
I had all sorts of problems when I was playing with the I2C bus and an external IC and the address.
The address seen and reported by I2C scanner is NOT the same address as needed in the code.
You have to rotate/shift the address 1 bit .....  left I think.  So, for instance, 37 (hex) becomes 6D.
Or something like that.

Next thing is to work on only one axis at a time.
FORGET the other two for now!
I had all sorts of problems and I discovered that I had the X and Z reversed.
Set the controller in the "neutral" position and read data from it.
Move it 45 degrees on what you want to call the X axis.
Watch for changes.
That is your X readings.

Check that there isn't an "offset" value you can set.
So, if your thing is always showing +20 when it is level, you enter 20 (be it -20 or +20) as the offset and then it reads ZERO.

Anyway, good luck.
Hope you get it working.
Pages: [1] 2 3 ... 48