Show Posts
Pages: 1 ... 300 301 [302] 303 304 ... 844
4516  Using Arduino / Project Guidance / Re: A Robot Arm on: September 25, 2013, 07:03:53 pm
Quote
ounce-inches of foot-pounds or in kilograms-centimeter (kg-cm)

I guess the "of" was intended to be "or". It's not a universal convention, but foot-pounds are commonly used as a unit of energy and pound-feet as a unit of torque.
4517  Using Arduino / Project Guidance / Re: Intermittent motor drive problem in elevator prototype on: September 25, 2013, 07:01:25 pm
Henry, basically it is a case for ready is neither 0 nor 1 which is an undefined case.

The correct answer to Henry_Best's question is "nothing". Assigning a variable to itself has no effect.
4518  Using Arduino / Project Guidance / Re: Feasibility of multi-stage temp controller (newb) on: September 25, 2013, 06:58:35 pm
Yes, that sounds entirely feasible. You will need to identify relays capable of switching the loads (that will be the hard part, but I suspect you're well qualified for that!) and then use a relay driver circuit to drive it. There are some boards which integrate relays with the drive circuit, and if you can find one of these with a sufficient current/voltage rating then you're sorted. If you need to switch mains voltages then for safety's sake I would suggest you use a standard commercial module. They aren't small and they aren't cheap, but you can buy powerswitch tails off the shelf which deal with all the high voltage issues for you.
4519  Using Arduino / Project Guidance / Re: Simple Arduino Balancing Robot? on: September 25, 2013, 06:52:40 pm
I won't have the time to read through 20 websites.

If you don't have time to read up on other people's projects you certainly don't have time to create your own.
4520  Using Arduino / Programming Questions / Re: output preprocessor variables on: September 25, 2013, 11:48:48 am
Sorry. I'm AFK, and not able to pinpoint the locate the exact spot.  It's all rather interesting...

The relevant part starts about 29 minutes in. What a fascinating presentation!
4521  Using Arduino / Programming Questions / Re: Javascript->Serial Port, Serial Line Freezing on: September 25, 2013, 10:24:13 am
The method you're using to process characters as they arrive only works if the code is in sync with the incoming stream and characters arrive before you try to read them. This is not a good strategy.

Given that you have got explicit start and end markers, it seems to me that the most obvious way would be to discard incoming characters until you get the start marker and then buffer characters until you found the end marker. This is a trivial change from common techniques based on looking for end-of-line markers to denote the end of each message. I mean something like this:

Code:
if(Serial.available())
{
char c = Serial.read();
if(receiving)
{
if(c == '>')
{
// end of message
// TODO: handle the current message content
// TODO: clear the current message
receiving == false;
}
else
{
// TODO: add the received character to the current message
}
}
else
{
if(c == '<')
{
receiving == true;
}
}
}

You could buffer the received characters in a char array and then use strtol() or similar to parse that into a number, but if you know that the message is just going to contain a decimal string then it would IMO be cleaner to parse each character to a decimal digit and add that to a numerical accumulator (i.e. multiply the accumulator by ten and add the new digit).
4522  Using Arduino / Programming Questions / Re: Millis overflow on: September 25, 2013, 10:08:30 am
Quote
if ((unsigned long)(millis() - waitUntil) >= interval)

The name waitUntil is poorly chosen. It implies that the variable holds the time at which the interval ends. In this case it holds the time at which the interval starts, and this is the best way IMO to deal with intervals while avoiding rollover issues.

Casting the return value from millis() to an unsigned long is redundant since it is already an unsigned long.
4523  Using Arduino / Project Guidance / Re: Making a linear encoder (choosing light sensor) on: September 25, 2013, 10:04:22 am
Absolute position encoders require more sensors (cost/complexity) and need you to make a compromise between the travel, resolution and number of sensors you need. For example a 3-bit encoder as you're drawn only gives you eight discrete positions. An eight-bit encoder would give you 256 positions. That's still not much resolution when spread over 2m and you have used up 8 I/O pins (or required the purchase of an external device to do it for you) to provide that.

On the other hand with just two sensors you can detect relative movement and as long as you know where you started from and keep track of each movement event you can get as much resolution as you want - now the only limit is the resolution versus the maximum speed you need to support.
4524  Using Arduino / Project Guidance / Re: gps guided lawnmower on: September 25, 2013, 09:58:45 am
anyone have any thoughts on using radar for triangulation?

Radar isn't really practical for DIY because it involves dealing with speed-of-light signal propagation and some pretty clever signal analysis. What would IMO be more feasible is an optical beacon that a sensor on the mower could detect and do crude direction finding on to discover which direction it was in and then head towards it, then have some other means for the mower to discover when it had reached the edge of the mowing area and turn/move into position to mow the next line, switching the old beacon off and the next beacon on. It would be difficult and fiddly to set up and involve laying beacons and wiring and who knows what else around the outside of the lawn, but it all seems generally feasible for a small area. But before you consider automating it, just designing and building an autonomous mower would be a considerable challenge in its own right. I know that if I'd put all the time and money in to making that I wouldn't want to wait until I had got the SLAM problem solved before I saw it working - a plain old RC system would be all you needed to get it trundling around the lawn causing havoc while you enjoyed a beer.
4525  Using Arduino / Project Guidance / Re: file processing/transfer on: September 25, 2013, 07:17:15 am
The webcam is serial, it has a serial chip, the webcam has a default baud rate because that best matches its data rate to video compression. Thus if you have a serial connection that means the webcams baud rate and the computers/or other serial devices baud rate are equal and they agree to the same packet packaging protocol. If the webcam wants to use a faster baud rate then what the other device can handle, the webcam will use the slower baud rate to match the other device or the connection will simply be rejected. This is what slows down the fps the most, the camera wanted 30fps, but the data rate can only handle ex.2fps, the extra frames that don't sync up with sending just don't get sent.

There is a world of different between an async serial connection and a USB connection. The quote above gives the strong impression that the camera supplies an async serial interface and NOT a USB interface. However, your original post strongly gave the opposite impression:

considering webcams tend to use USB serial to transmit the video (compressed), in theory ...

Which is it? Do you have a link to the camera spec?
4526  Using Arduino / Project Guidance / Re: gps guided lawnmower on: September 25, 2013, 07:07:06 am
Getting position within centimeters as you're describing will be extremely difficult. As far as I know, the commonly available commercial automatic lawn mowers work by patrolling within the perimeter on a random pattern with the idea being that eventually their path will cover every part of it - they don't work in neat lines as you would if you were cutting the lawn manually. If you wanted your mower to follow a set pattern, I think you would need some sort of beacon system so that the mower can aim towards the far side of the lawn, move sideways by the cut width, and then aim for a beacon at the far end of the next row etc. I expect this would need some way to keep track of where the mower was and coordinate that with turning the beacons on and off as required.

As a first step, a simple remote controlled lawnmower would be massively easier to build and a lot more fun than mowing the lawn yourself.
4527  Using Arduino / Programming Questions / Re: new on this on: September 24, 2013, 09:37:26 pm
Increase the size of the buffer array by one.

Append a null terminator after every character appended to it.

You can clean up the serial processing substantially - you only need to know the value of index and that available() > 0, you don't need to keep a separate count of the number of characters remaining to be read.

Your serial handling code seems to assume that every incoming message is complete at the point you start receiving it, which does not seem a safe assumption. It would be much safer to explicitly recognise the end of the message, for example by looking for an end-of-line marker.

The parsing code looks as if it would work when you get the expected message format but does not look very robust - what would happen if you get a partial or corrupted message ending with a '.'?

Here is a sample demonstrating how to buffer characters received from the serial port and only process the message when a complete line has been received:

Code:
// incomplete
void handleSerial()
{
    const int BUFF_SIZE = 32; // make it big enough to hold your longest command
    static char buffer[BUFF_SIZE+1]; // +1 allows space for the null terminator
    static int length = 0; // number of characters currently in the buffer

    if(Serial.available())
    {
        char c = Serial.read();
        if((c == '\r') || (c == '\n'))
        {
            // end-of-line received
            if(length > 0)
            {
                handleReceivedMessage(buffer);
            }
            length = 0;
        }
        else
        {
            if(length < BUFF_SIZE)
            {
                buffer[length++] = c; // append the received character to the array
                buffer[length] = 0; // append the null terminator
            }
            else
            {
                // buffer full - discard the received character
            }
        }
    }
}

void handleReceivedMessage(char *msg)
{
if(strcmp(msg, "on") == 0)
{
// handle the command "on"
}
else
{
// etc
}
}

4528  Using Arduino / Project Guidance / Re: New to programming on: September 24, 2013, 09:21:36 pm
The basic concepts and syntax of Java are so similar to C++ that you should find it very easy to pick up C++ at a basic level. Just stay away from classes, templates and so on until you have got the basics under your belt.
4529  Using Arduino / Project Guidance / Re: Home Security System Project – 60Hz Interference on: September 24, 2013, 09:19:05 pm
To start with, I suggest you check that this noise isn't causing any transient voltages under 0V or over VCC on any of the I/O pins, because that can damage the microprocessor.

If that's all safe, screened cables or UTP should help, but might not be practical since the wiring is all already installed.

I get the impression that your inputs are connected so that they are pulled down to GND when the sensor is active and not pulled down when it is inactive - the internal pull-up being expected to hold the floating wire HIGH in that case.

A stronger pull-up would make the input less susceptible to noise, but make sure you don't go so far you overload the sensor.

The software option would be to debounce the signal in software i.e. wait for it to remain over/under the threshold continuously for some multiple of a 60Hz cycle before actioning the change.
4530  Using Arduino / Programming Questions / Re: Problem with sequence on: September 24, 2013, 08:31:16 pm
Your English is still very challenging to understand but I get that when the door reaches the bottom it starts up all on its own and does not stop at the top.

The only code I can see that would make the door go up is at line 36:

Code:
digitalWrite(MOTOR_UP_PIN, HIGH); //Door start to up

I suggest you put a Serial.print statement here to tell you for certain that this line of code is executing when the problem starts.

If this statement is executing then it implies that (limit_down == HIGH ) and (button_up == HIGH) and (motor_up == LOW) and (motor_down == LOW).

Clearly if you have not pressed the 'up' button then we do not expect (button_up == HIGH) so this should not have happened. So, print out the actual value of button_up at this point and see whether it matches the physical state of the button. If it doesn't match then this implies a wiring fault or a faulty switch.
Pages: 1 ... 300 301 [302] 303 304 ... 844