Show Posts
Pages: 1 ... 4 5 [6] 7
76  Forum 2005-2010 (read only) / Interfacing / Re: 10 stepper motors & Arudino Mega on: August 27, 2010, 12:41:40 am
You are right, you don't want to power the any motors from your Arduino board.  You'd be likely to burn out some components by drawing too much current from the board itself.  So you'll need an external power supply.  For my motors, I use a generic DC power adapter that I plug into the wall.  (You can get cheap ones from a second-hand store for $1-$2... otherwise they're $12+ each)  Just check the specs which are printed on the outside of the casing to make sure of the voltage and current they supply.

You can get simple transistors to act as very fast switches to power your motors.  Basically, you connect your external DC power supply voltage and ground to the outer two pins of the transistor and the middle is the control line from the Arduino.  By sending a PWM signal on the control line, it turns on and off the power very quickly to move the motor.

A nice neat package is the NTE1749 or equivalent  (~$15).  It's a 4-channel H-Bridge.  Basically it powers 4 different control lines, as found on most stepper motors.  You may be able to find a different model with more channels or a cheaper one to suit your needs, but this is the one I use.

Your limitation here would be that you need 4 control lines for each stepper motor.  The Arduino doesn't have 40 digital output pins as you would need to run 10 stepper motors.  Servos commonly use less control lines, so that would probably be a safer bet.  But I'd still check how many you require before you buy anything.

As for the drive shaft question.  I've done a bit of robotics with legos myself, and ran into the same question.  Turns out there's a very good method for mounting gears to drive shafts.  Check out the robotics --> motors section of sparkfun's website.  (or google "universal mounting hub")  It's a round metal hub that connects to the drive shaft with a set screw.  The hub has other screw holes that you can use to connect your lego gears.  The holes work very nicely because the lego gears also have holes that match up pretty well.

You can do pretty much the same thing with whatever plastic gears you can find at a hobby shop.  Just get one that connects to the drive shaft (many have pressure fitting gears), and then you can drill holes in the plastic gear, and then use small nuts/bolts to connect the lego gear you want.  That solution works well as a gear adapter for cheap.

In essence, the ATMEGA168 / 328 microcontrollers are fast enough (16-20 Mhz) to control 10 steppers and lights and such, but the difficulty would be getting them all connected to the microcontroller.  You could do some multiplexing and resolve that issue, and easily connect the 10 motors, and use a few pins (4) to address which motor you want.  Though, multiplexing would cause it so you wouldn't be able to control all of the multiplexed devices at the same time... just one at a time.  All that would take is a few AND/OR/NOR/XOR gate chips which are cheap, and do a bit of digital logic.

I think you could do what you want with an Arduino Mega, just requires some imagination / ingenuity... which from your project description sounds like you have plenty of.
77  Forum 2005-2010 (read only) / Interfacing / Lego Gears on: September 13, 2010, 11:42:04 am
I've been working lately connecting my Arduino to drive a LEGO car I've built.  I know that LEGO makes motors specifically for this application, but I'd prefer not to buy one of those.  I've got some higher quality motors I'd rather use instead.

I have a few simple DC motors that I'd love to connect to my car.  The current setup I'm using is a universal mounting hub which then lets me fasten the lego gear to the hub.  It works well, but it's a bit bulky and could be done more simply.

I want to connect a pinion gear directly to the shaft of the DC motor.  Lots of hobby stores sell gears that will connect to the motor shaft using a set screw.  That setup would work nicely for my application.

But how do I know which hobby gear will mesh into my LEGO gear?  Are there standard gear sizes that will work?
78  Forum 2005-2010 (read only) / Interfacing / Re: Serial communication between 2 different boards. on: August 23, 2010, 07:22:54 pm
The data coming across may be converted to ASCII.  So a digit "0" appears as decimal 48.  check out http://www.klcconsulting.net/images/ascii-full.gif

If you're just sending integers, you can just subtract 48 from all the serial.read() results.  

If you're sending more than just integers, you'll need to parse out the data.

To help debug the issue, could you paste the sent data and the actual received values?
79  Forum 2005-2010 (read only) / Interfacing / Re: Arduino to PC/Mac running ReaBasic 2010r3 Serial on: August 27, 2010, 01:02:35 pm
The only thing that indicates a "line" is the carriage return that is printed by Serial.println().

1.  Keep a String and continually add the incoming serial data to it.
2.  Read through the string from the beginning until you find a carriage return.
3.  Copy the substring until the carriage return to a new variable.
4.  Remove the substring from your input string.
5.  Process the individual line (parse using the semicolons)
6.  Loop #1-5

Kind of a pain, but most languages I've worked with don't have a method for reading in a line at a time from the Serial connection.  The idea of a line isn't well defined for serial data.  All it knows is that ASCII 13 means a carriage retun character.  It's all just a big stream of data which happens to have carriage return characters in it.

I suppose if you had access to a tokenizer like Java does, you could parse the incoming serial data a bit more easily.
80  Forum 2005-2010 (read only) / Interfacing / Re: Serial Receive data rate much lower than expected on: August 24, 2010, 03:12:25 pm
I modified the RX_BUFFER_SIZE in HardwareSerial.cpp.  This allowed me to buffer enough sound samples to allow smooth audio playback without needing an extra circular buffer.

Unfortunately, there is no way to read (or set) the RX_BUFFER_SIZE at run time, which is really sad.  Perhaps the Arduino core could be updated to include  Serial.GetRXBufferSize() and  Serial.SetRXBufferSize methods.

There would be some restrictions on that though, as I've already run into while playing around with the RX_BUFFER_SIZE in HardwareSerial.cpp.  For example, the Serial.available() method returns a unsigned 8-bit integer, which will not work if the buffer size is increased above 255 bytes.  It would have to be upgraded to a unsigned 16-bit integer, but that takes up more ram.  Several variables would need this sort of upgrade, in turn increasing the overall RAM requirement.

So I totally understand why the limitations are in place... the variables are chosen very wisely to save system resources.  It's just not very flexible to accomodate larger bandwidth needs.
81  Forum 2005-2010 (read only) / Interfacing / Re: Serial Receive data rate much lower than expected on: August 24, 2010, 11:20:16 am
I finally got my project working.  It's for Streaming Audio over Serial.  I've posted the code for the project here:

http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1282666614/0#0

I'll still be trying to modify the USART to see if I can improve performance and buffer size.  Maybe I could eliminate the need for a second circular buffer by doing so.
82  Forum 2005-2010 (read only) / Interfacing / Re: Serial Receive data rate much lower than expected on: August 24, 2010, 10:49:37 am
Would you be willing to post your adapted USART code so I can compare it to the original and see what sort of modification might be required for my purpose.
83  Forum 2005-2010 (read only) / Interfacing / Re: Serial Receive data rate much lower than expected on: August 23, 2010, 08:04:05 pm
I looked at the ATMEGA328p datasheet... I actually can't find anything in there about a 128 byte buffer.  Maybe it can be changed.
84  Forum 2005-2010 (read only) / Interfacing / Re: Serial Receive data rate much lower than expected on: August 23, 2010, 07:49:58 pm
I looked into that.  I don't think it works that way.  I think the 128 byte serial buffer is a hardware limiation.  All the documentation I can find about it says that the buffer size can be reduced below 128, but that's the maximum.

You might be able to get a larger buffer on NewSoftSerial, but that only supports bauds up to 57,600 (7,200 bytes / sec) and I need slightly faster than that.
85  Forum 2005-2010 (read only) / Interfacing / Re: Serial Receive data rate much lower than expected on: August 23, 2010, 07:06:55 pm
I'm using a circular buffer to eliminate the 2k ram issue.  I just need more data buffered at a time than just 128 bytes.  1024 bytes would work much better.  So, if I could copy the 128 byte buffer into a location of my 1024 byte circular buffer, this would increase performance for me.  

There is minimal processing of the data going on, it's just critical that my circular buffer does not run out of data.

I'll check out modifying the core Serial ISR's to see if I can have them return me a pointer to the buffer and a buffer length or something like that.  I just hate modifying the core files because it makes it so that the code can't be used easily by others.
86  Forum 2005-2010 (read only) / Interfacing / Re: Serial Receive data rate much lower than expected on: August 23, 2010, 06:31:14 pm
I have revisited the original speed calculations.  There was no flow control, so the PC was just spitting data at the Arduino as fast as it possibly could.  This meant that the 128 byte buffer on the Arduino was being over-run constantly.  However, this kept the buffer full all the time, which increased the bytes / sec.

So, if you only care about the most current data, and don't care if old data is overwritten, then you can sustanably reach 20,000 bytes / second.

However, this was not the desired outcome for my application.  I implemented some flow control, but that drastically limits the data rate.  There's a bit of lag time between telling the PC to send more data and when it actually arrives.  In most cases the receive buffer completely empties before more data arrives.

Changing the latency on the FTDI COM connection seems to help a little, since the packets must be < 128 bytes in order not to overflow the buffer.

At lower baud rates, you get better performance by sending packets that are half of the buffer size (ie: 64 bytes).  At higher baud rates (above 57600) it does not really matter if the receive buffer empties or not, because the data comes in fast enough that you can refill an entire buffer at once rather than requesting half-buffer packets.

The real limitation is how fast you can empty the receive buffer.  Is there a way that I can copy the entire buffer as a byte array instead of having to call Serial.read() 128 times?
87  Forum 2005-2010 (read only) / Interfacing / Re: Serial Receive data rate much lower than expected on: August 22, 2010, 09:44:43 pm
With a bit of further testing, I was able to boost the data rate to about 20,300 bytes / sec.  (162,400 bits / sec).  That was sending 2500 bytes at a time from the PC.  I'm not sure what the loss rate is yet, if any.  I'll post back when I have that data.  That's a little more than 115,200, but not a whole lot.
88  Forum 2005-2010 (read only) / Interfacing / Re: Serial Receive data rate much lower than expected on: August 22, 2010, 07:26:40 pm
It appears that increasing the Baud rate beyond 115,200 also increases the transfer rate, but this requires also increasing the amount of data sent at a time to 2048 bytes or more at a time to see any performance increase.
89  Forum 2005-2010 (read only) / Interfacing / Re: Serial Receive data rate much lower than expected on: August 22, 2010, 07:20:22 pm
Thank you westfw.  You were exactly right.  There appears to be quite a bit of overhead for sending one byte at a time.

I increased the amount of data the PC was sending each time.  Instead of sending just 1 byte, I increased it to send 256 bytes at a time.  This apparently works much better, as now I am getting aprox 10,000 bytes / sec.  That's much more like what I was expecting.

Now I will increase by baud rates and see if it increases beyond that.

However, I am still wondering if there is a better way to receive data on the Arduino.  Can I copy the entire receive buffer to another location somehow?
90  Forum 2005-2010 (read only) / Interfacing / Serial Receive data rate much lower than expected on: August 22, 2010, 06:50:41 pm
I tested data transfer rates between a PC and Arduino using a very simple sketch.

I am using a baud rate ot 115,200 bps.  At 8 bits / byte, this should ideally be 14,400 bytes / sec.  Assuming we have a start and stop bit, and it actually takes 10 bits to send 1 byte of useable data, this drops to 11,520 bytes / sec.

However, when I ran my test with actual data and timing the results, I found a large discrepancy.  Arduino doesn't seem to have a problem sending the data at the correct data rate.  When the Arduino is the receiver, the actual data rate is only 30% of what it should be!

Arduino  --> PC    =   8,400 bytes / sec.  Ideally this would be 11,520 bytes / sec, but it's somewhat close.
PC --> Arduino     =   3,400 bytes / sec.  This is nowhere near 11,520 that it should be.

Increasing the baud rate beyond 115200 does not seem to make any difference on the send or receive speed.

I realize this may be due to the 128-byte receive buffer limitation.  (I tested with a larger buffer in HardwareSerial.h, with no improvement.)  Is there a faster way to receive all the data in the receive buffer without calling Serial.read() 128 times?  I would really like to move all the data in the receive buffer out at once, since I think that the Serial.read() function might be really slowing things down.

Any thoughts?  Anyone test their actual send / receive data rates and could share?

I'm really hoping to achieve a data rate of 8,000 bytes / sec or higher if I can for the Arduino's receive.

Here's my test code.  I have a program running on my PC which sends data to the Arduino as fast as it can and does the timing.  Every 256 bytes received, the Arduino sends the number of BytesRead back to the PC.  The PC can then calculate the data rate as: (BytesRead / (current time - start time)).

/*
SerialSpeed2
21 August 2010

Test the sending speed for a serial connection.
  9,600 baud =    960 Bytes/sec
115,200 baud = 11,520 Bytes/sec
*/

long BytesRead=0;

void setup()  
{
Serial.begin(115200);  
establishContact();
}

void establishContact() {
  while (Serial.available() <= 0) {
    digitalWrite(13, HIGH);   // set the LED on
    Serial.println("Waiting For Connection...");   // send an initial string
    delay(300);
    digitalWrite(13, LOW);    // set the LED off
    delay(300);
  }  //End While
}  //End Establish Contact

void loop()                    
{

while (Serial.available() > 0)
{
  Serial.read();
  BytesRead++;
  if (BytesRead % 256 == 0)
  {
digitalWrite(13,!digitalRead(13));
Serial.println(BytesRead);
  }//End if
}//End While
}// End Loop
Pages: 1 ... 4 5 [6] 7