Show Posts
Pages: 1 ... 300 301 [302] 303 304 ... 840
4516  Using Arduino / Project Guidance / Re: Modifying R/C receiver output signals? on: September 22, 2013, 05:59:41 pm
I'm still trying to figure out how you plan to use a pistol grip transmitter for an R/C airplane.

I may have got the wrong end of the stick, but I thought the OP was using a pistol grip 2ch system to control cars/boats but wanted to use an ESC designed for use on aircraft. The aircraft ESC would be designed for a throttle that went 0% - 100% rather than reverse-neutral-forwards.
4517  Using Arduino / Project Guidance / Re: Problem with sending an email through GoBetwino on: September 22, 2013, 05:57:22 pm
Since you're evidently running on Windows, you could use PowerShell or whatever other scripting framework you prefer to send the email for you - in PowerShell you can access the Net.Mail.SmtpClient class which supports SMTP over SSL.
4518  Using Arduino / Project Guidance / Re: RC receiver on Mega2560 on: September 22, 2013, 05:53:46 pm
There's a lot of extraneous code in there but it looks to me as if you're using the PinChangeInterrupt library to execute calcMower() each time the mower input pin A13 changes state, and then trying to determine the pulse length by comparing values of TCNT1. Since you're getting non-zero values I assume the interrupt is occurring. However, you don't seem to be initialising timer 1 and I don't know enough about the default behaviour to know whether it's going to give you a meaningful count over the time interval you're trying to measure.

How long do you expect these pulses to be? From the context I suspect they're RC pwm pulses which are typically in the 1500-2500 uSec range, in which case you could easily establish the length by using micros() instead of hitting the timer hardware directly.

Also, have you double-checked that your input signal is connected to pin A13 and that the grounds are connected? If the pin is floating you'd get arbitrary noise on that pin instead of the pulses you're expecting.
4519  Using Arduino / Programming Questions / Re: I need Softwareserial to read 8bit Even parity 1 StopBit on: September 22, 2013, 01:55:48 pm
The standard library doesn't support single pin (unidirectional) operation. I know that at least one person has made modified the library to support this and it may be that they have published the modified version somewhere, but it would be easy to modify the library yourself to support that. (I would just define a magic number such as -1 meaning 'unused' and then disable all operations affecting that pin when it had that value.)

The standard library also doesn't support parity and doesn't give you any option over the use of stop bits - it doesn't seem to be documented anywhere but it only supports 8N1. Changing that would require messing with some extremely timing-critical code and not a task to be tackled lightly.

I remember that there is an alternative software serial library which was developed to overcome some of the limitations of the standard SoftwareSerial. I haven't used it and don't have a link handy but I suggest you try to track it down and see if that would suit you better.
4520  Using Arduino / Project Guidance / Re: How to calibrate a speedometer? on: September 22, 2013, 01:38:27 pm
Tyre pressure certainly does affect the rolling radius

Yes, but the magnitude of the effect is negligibly small in the context of speedo accuracy. It's certainly not as simple as saying that the flat spot has reduced the 'rolling radius' between the road and the axle, which is a common misconception.

More significantly, the calibration will be affected quite noticeably by tread wear. In the UK cars are usually designed so that they may over-read but will never under-read. That means you would need to calibrate the speed so that it was about right with brand new tyres; it would then gradually start reading high as the tread wore away.
4521  Using Arduino / Project Guidance / Re: Modifying R/C receiver output signals? on: September 22, 2013, 01:11:45 pm
So I've already mentioned I'm an Arduino noob, please get me started on what kind of math calculations are necessary. smiley-lol
Also,can this project be done with an ATmega8? That's all I have right now.

You will have to do a bit of experimenting to work out the actual range of signals you get from your transmitter, but let's pretend that the mid position is 2000 uSec and full throttle is 2500 uSec. You'll need to do some testing to work out what range your ESC expects too, but let's pretend that 'no throttle' is 1500 uSec and 'full throttle' is 2500  uSec.

You can use pulseIn() to measure the incoming pulse length in microseconds:

Code:
unsigned long inputPulseLength = pulseIn(INPUT_PIN, HIGH) ;

You can use the constrain function to deal with any input values which are outside your normal expected range e.g. if the user moves the trigger into 'reverse':

Code:
inputPulseLength = constrain(inputPulseLength, 2000, 2500);

You can use the map function to convert your input value in the range 2000-2500 to an output value in the range 1500 - 2500:
Code:
unsigned long outputPulseLength = map(inputPulseLength, 2000, 2500, 1500, 2500);

You can use the Servo library to output the corresponding signal:

Code:
esc.writeMicroseconds(outputPulseLength);

I've used magic numbers in the code fragments above for simplicity, but in your code you should define constants for these values so they aren't all duplicated throughout your code:

Code:
const unsigned long MIN_INPUT_LENGTH = 2000;
etc

If this is all you need it to do then it should be easily within the capabilities of any Arduino.
4522  Using Arduino / Project Guidance / Re: Parallel parking rc car code needed! on: September 22, 2013, 11:04:16 am
Sorry I'm lost as on what I'm supposed to do.

I'm looking at your code and trying to reverse-engineer your logic to work out what the different state values are intended to represent, so that I can understand how it would be sensible to transition between them and whether you have any state transitions that are not sensible.

That's rather hard to do because you didn't do this:

Please define meaningful names for your state values, either by defining const values or by defining an enum type.

I have a suspicion that state 0 is trying to cover two different states at the same time, but without understanding what you intend it to be I can't confirm or deny that.
You also haven't answered this question:

What is this meant to be doing?

Code:
currentMillis >= threshold || currentMillis - previousMillis >= threshold

A way to structure a finite state machine which I find very simple and clear is to use a switch statement:

Code:
switch(state)
{
    case INITIAL:
        // we assume there is a line of parked vehicles to our right, with an empty bay somewhere in front of us
        moveForwards();
        state = LOCATE_REAR_OF_BAY;
        break;
    case LOCATE_REAR_OF_BAY:
        // keep moving forwards until we detect an opening beside us
        if(sideDist > 20)
        {
            // opening found
            // keep moving forward
            state = LOCATE_FRONT_OF_BAY;
        }
        break;
    case LOCATE_FRONT_OF_BAY:
        // keep moving forward until we detect a vehicle beside us i.e. the front edge of the bay we'll be parking in
        if(sideDist < 20)
        {
            // vehicle found
            // keep moving forward a bit further
           state = MOVE_TO_READY_POSITION;
           startTime = millis();
        }
        break;
    case MOVE_TO_READY_POSITION:
        // move past the bay slightly before trying to reverse into it
        // here the distance is defined by how long we move forward for
        if(millis() - startTime >= FORWARD_DURATION)
        {
            // we have moved forward far enough, start reversing into the bay
            stop();
            reverseRight();
            state = REVERSING_RIGHT;

    ... and so on

I don't know whether the logic above is anything like the algorithm you're actually using, but all I'm trying to show is how to structure your code so that each state corresponds to a specific part of the overall maneuver and the code for each state implements the tests to decide when to move to another state. I recommend that you aim to keep your states as simple as possible (even if that means you end up with a lot of different states).
4523  Using Arduino / Programming Questions / Re: Controlling a 180 servo speed and position with 3 push buttons on: September 22, 2013, 10:38:50 am
One step at a time. Get the behavior of the code working, and understandable, then improve it.

That's fair enough, but given that the current problems center around an inability to code a for loop correctly, eliminating the loop entirely seems like an easier approach as well as giving a better end product.
4524  Using Arduino / Programming Questions / Re: Problem with sequence on: September 22, 2013, 10:09:53 am
The new English code is much easier to follow, thank you.

You don't seem to have any code dealing with IR sensing.

The code is not structured in a way that makes it easy to follow the logic, but as far as I can see the logic would result in the sequence you want: where the door is initially closed and you press the 'up' button the door would start opening and would then stop when it reaches the fully-open position, delay briefly and then start closing again. When it reaches the fully-closed position it will stop.

I can't tell whether you have got the switches wired correctly (so that they actually read HIGH when they're pressed and LOW when they aren't pressed) and I can't tell whether the motor is wired correctly so that the door moves up when you set MOTOR_UP_PIN to HIGH and down when you set MOTOR_DOWN_PIN to HIGH. It's easy to imagine a collection of wiring faults which meant that the sketch appeared to work but actually had the reverse logic to what you intended so that when the sketch thinks the door is open it is actually closed - this would result in the sort of problem you had at the beginning.

I agree with PaulS's suggestion to use a finite state machine since this would make the logic much simpler and more robust. However, before doing that I suggest you create a test sketch that just prints out the switch positions and proves that when you try to move the control the motor is actually does what you intend. Unless the basic inputs and outputs are working correctly, nothing else is going to work no matter how you structure your sketch.
4525  Using Arduino / Programming Questions / Re: String.startsWith in big routine on: September 22, 2013, 09:52:32 am
I'm not sure what happens when you append a null character to a String object (line #27) but at best it's unnecessary - at worst it might confuse some subsequent processing leading to unexpected behaviour.

I'm not sure what the result of this expression is when serialbuffer is a String object but at best it's unnecessary (you can print the String object directly) - at worst you may end up referencing memory which is outside the bounds of the String's buffer leading to unexpected behaviour.

Code:
&serialbuffer[0]

The String class offers minimal benefits over just using plain old c-strings (null-terminated char arrays) and introduces several issues of its own, so if you have re-written your code to eliminate use of the String class I would regard that as a good move. However, the most recent code you posted does still use the String class.
4526  Using Arduino / Programming Questions / Re: Problem with sizeof in a function on: September 22, 2013, 09:44:59 am
To be fair, the problem is caused by some extremely unintuitive behaviour of the 'C'/C++ language.

When you refer to a variable which is an array, the reference is syntactically equivalent to a pointer to the first element of the array, but the compiler knows the length of the array and sizeof(array) will give you the number of bytes occupied by the whole array.

When you refer to a function/method formal parameter which is an array, the reference is syntactically equivalent to a pointer to the first element of the array and the compiler has no knowledge of how long the array is; sizeof(array) will give you the size of the pointer. (In fact the array may be different each time the function/method is called; the array size is not a compile-time constant.)

To remove the potential confusion, it is better to explicitly declare function arguments as type pointer rather than type array - it is syntactically the same from the compilers point of view but clearer to the human reader.
4527  Using Arduino / Programming Questions / Re: Controlling a 180 servo speed and position with 3 push buttons on: September 22, 2013, 09:34:31 am
Rather than use a for loop to move between the current position and the newly commanded position, I suggest just incrementing the servo towards the newly commanded position and making a brief delay (to control the speed) then let loop() complete. This way the switches will remain responsive if you want to select a new position before the servo has completed the previous movement.
4528  Using Arduino / Project Guidance / Re: Modifying R/C receiver output signals? on: September 22, 2013, 09:28:15 am
I may have misunderstood, but as far as I can see you have got a handset which is designed to support forward and reverse and is mechanically designed so that the 'at rest' position is mid travel. This would make sense when used with an ESC which supports forwards and reverse, where the mid position corresponds to stationary.

You have a plane ESC which (obviously) doesn't support reverse and which treats the minimum pulse as stationary and the maximum pulse as full power. This means that when the handset throttle is in the 'at rest' position you are getting half power from the motor; you need to pull the throttle control to the 'full reverse' position to stop the motor.

If that is the problem then it seems to me that the easiest approach would be to mechanically modify the throttle assembly so that it is sprung to the minimum/reverse position instead of the mid position. If it's a decent quality system you may find that it is designed to make this easy just by moving an internal spring - this change is commonly available on twin stick handsets designed to be used for cars or aircraft. A pistol grip handset probably isn't designed to support aircraft use so may not have that easy adjustment designed in, but you may still be able to find a way to modify it so that the trigger is sprung to the 'fully back' position.

If the mechanical approach isn't possible then it would be possible to put a signal modifier between the RC receiver and the ESC to shrink the pulse so that mid position on the input corresponded to minimum pule length on the output, and you could use an Arduino to do that. You would need to read the incoming pulse length, do some simple arithmetic to calculate the required output pulse length, and then use the Servo library to output that pulse. However, I suggest you exhaust all the options to solve the problem mechanically before you try to tackle it electronically.
4529  Using Arduino / Project Guidance / Re: Parallel parking rc car code needed! on: September 22, 2013, 09:16:11 am
I don't think your reply has addressed any of my comments.
4530  Using Arduino / Project Guidance / Re: arduino uno aquarium water changer on: September 22, 2013, 09:12:01 am
If you want something to happen every hour on the hour then read the hour and compare the value to what it was last time you read it - if the two differ, you've just rolled over an hour so start whatever it is you want to happen. This is just like edge detection on a switch input, and the StateChangeDetection example sketch demonstrates how to do that.
Pages: 1 ... 300 301 [302] 303 304 ... 840