Shop OBEX P1 Docs P2 Docs Learn Events
Multiple ColorPals on single Arduino board — Parallax Forums

Multiple ColorPals on single Arduino board

EriolEriol Posts: 4
edited 2014-12-05 06:02 in Accessories
Hello,

I'm relatively new to electronics and using this more as a learning experience, but now I'm testing an array of 3 ColorPals with Arduino boards (namely the Uno and Mega) as a learning experience. I've been able to successfully run the demo over at the learn page with a single sensor with both boards. http://learn.parallax.com/colorpal-arduino-demo
Now, I have a Mega that has 3 UARTs and I've also found this post in the forums, but I'm unsure of how it would work with Arduino. http://forums.parallax.com/showthread.php/120828-help-colorpal-sensor?p=890040#post890040
I also saw the documentation stating you can put an "address" to each device but I'm also unsure of how that would work.
I know you can "bit-bang" with the SoftwareSerial library but kind of unsure of the procedure of resetting into Direct Mode, etc, for all three of the sensors.

Can I do it with SoftwareSerial and a single pin? How?
How would I be able to run all three ColorPals to give me the same information from the single sensor sketch, but for every sensor, on an Arduino?

Comments

  • kwinnkwinn Posts: 8,697
    edited 2014-11-28 06:50
    If you are placing each of the ColorPals on separate uarts there is no need to change the ColorPal addresses. If you want to run all 3 ColorPals on a single uart you will need to change the address on 2 of them so each one has a unique address. Changing the address should be explained in the documentation.
  • GordonMcCombGordonMcComb Posts: 3,366
    edited 2014-11-28 10:19
    With SoftwareSerial you can only listen to one port at a time. You can have separate ColorPALs on separate pins, but you can only fetch data from one of them at a time. Look at the SoftwareSerial documentation for the listen method.

    On the Mega take note that not all of its pins support pin change interrupts, which is needed for SoftwareSerial. Thoroughly go over the docs for this library before using it, especially if you're not using an Uno. You'll just be wasting your time otherwise.

    The diagram you pointed to is only necessary if you want to send and receive duplex data over two Arduino pins. The method shown in the Learn tutorial uses simplex communications only. Once the ColorPAL is set up, the Arduino then simply listens for the continuous stream from the ColorPAL.

    As you noted, the Mega has additional hardware UARTs, which you can use instead. Leave the one open to get data back to the Serial Monitor window, and connect your three ColorPALs to the remaining UARTs. Set them all to 4800 baud.

    Bear in mind that the Arduino Serial and SoftwareSerial libraries do not support the "ideal" 7200 baud rate used by the ColorPAL. Trying to use a non-standard bitrate may result in either a compiler error, or considerable data error loss. You can try it, but it might not work. The Arduino.cc forums may have pointers to alternative serial libraries that better support for non-standard bit rates. The chip on the Arduino board can handle other speeds, but its hardware must be set up to support it. That means the serial library you use needs to be set up for arbitrary baud rates.

    The 4800 baud rate works, but there are reports that the ColorPAL eventually stops communicating after a few minutes. You can correct this by resetting the ColorPAL, and re-establishing its data stream.
  • EriolEriol Posts: 4
    edited 2014-11-29 05:13
    As you noted, the Mega has additional hardware UARTs, which you can use instead. Leave the one open to get data back to the Serial Monitor window, and connect your three ColorPALs to the remaining UARTs. Set them all to 4800 baud.
    This seems like the simplest way to be able to grab data from all three, but I'm still a bit confused about how to handle the single Signal wire from the ColorPal to both the Tx and Rx pins on the Arduino. After initialization, since I only want to listen to information, should I simply have it plugged in to Rx? How can I start working on it?
  • kwinnkwinn Posts: 8,697
    edited 2014-11-29 07:40
    You put a resistor between the arduino TX and the RX pins. The common data line from the colorpal then goes to the RX pin. Typically it is somewhere around a 1K resistor.
  • GordonMcCombGordonMcComb Posts: 3,366
    edited 2014-11-29 12:08
    Eriol wrote: »
    This seems like the simplest way to be able to grab data from all three, but I'm still a bit confused about how to handle the single Signal wire from the ColorPal to both the Tx and Rx pins on the Arduino.

    You're mixing two techniques here. For SoftwareSerial, the Learn page shows exactly one wire from the ColorPAL to exactly one I/O pin on the Arduino. Just duplicate this setup. The SoftwareSerial libraries require you to define two pins, but only one is actually used. (The other is defined as 255, which does not exist on any Arduino.)

    The hardware serial UARTs will need the logic steering components shown in Phil post. During runtime, the Learn sketch flips the serial input and output so that you only need one actual line This is allowable with SoftwareSerial, as it uses arbitrary pins for the I/O. The Rx and Tx pins of the UARTs are set in hardware, so you can't use this method alone. You need some hardware in the mix.

    As Phil notes, with the steering logic you need to accommodate for ignoring the data you send to the ColorPAL on setup, as it'll be spontaneously received back into the Arduino as well. After setting up a ColorPAL, just wait a few milliseconds, then delete whatever's in the receive buffer. Anything that follows is color data from the ColorPAL.
  • EriolEriol Posts: 4
    edited 2014-12-02 11:42
    Thank you for your prompt replies. Sorry if I'm being a bit airheaded here, I'm still learning a lot.
    You're mixing two techniques here. For SoftwareSerial, the Learn page shows exactly one wire from the ColorPAL to exactly one I/O pin on the Arduino. Just duplicate this setup. The SoftwareSerial libraries require you to define two pins, but only one is actually used. (The other is defined as 255, which does not exist on any Arduino.)

    The problem I've seen with this is that SoftwareSerial doesn't support simultaneous dataflow, so I'd probably have to implement strict timers for getting input pseudo-simultaneously and would cost some processing power on the Arduino for more code. I looked at the AltSoftSerial library and this is what they have to say:
    AltSoftSerial - Can simultaneously transmit and receive. Minimal interference with simultaneous use of HardwareSerial and other libraries. Consumes a 16 bit timer (and will not work with any libraries which need that timer) and disables some PWM pins. Can be sensitive to interrupt usage by other libraries.
    NewSoftSerial (SoftwareSerial in Arduino 1.0 & later) - Can have multiple instances on almost any pins, but only 1 can be active at a time. Can not simultaneously transmit and receive. Can interfere with other libraries or HardwareSerial if used at slower baud rates. Can be sensitive to interrupt usage by other libraries.

    Which is why I concluded that using the native UARTs on the Mega would be simpler since they've got their dedicated hardware (I'm assuming) and wouldn't mess up any other code I'm running. Also, it seems that I can use the "ColorPAL baud sweetspot" better than with SoftwareSerial. I don't mind getting some extra hardware to make the logic steering circuits if it allows me to communicate simultaneously with the sensors, or at least really quickly for it to be negligible, but I was wondering if I needed extra circuitry/ICs/etc and how to wire it up because I've probably only got basic high school background in electricity/electronics knowledge besides whatever I've absorbed learning through projects. kwinn's reply is helpful for that then since it seems a simple resistor will do, and checking Phil's diagram probably a diode as well unless that's only for that other chip.
    As Phil notes, with the steering logic you need to accommodate for ignoring the data you send to the ColorPAL on setup, as it'll be spontaneously received back into the Arduino as well. After setting up a ColorPAL, just wait a few milliseconds, then delete whatever's in the receive buffer. Anything that follows is color data from the ColorPAL.

    So this is what I'll probably end up trying out x3 with the three UARTs during setup in the Arduino, and grab the data using HardwareSerial (Serial) which will disable debugging using the PC's Serial Monitor, but I guess I can flash LEDs or something instead for debugging purposes.

    Thank you all for the detailed replies, they have been very helpful.
  • GordonMcCombGordonMcComb Posts: 3,366
    edited 2014-12-02 13:50
    The Arduino is single thread anyway, so that limits how you process your data. You have to do one thing at a time as it is.

    You can set the listener port, and within milliseconds, get a reading from that ColorPAL. Since the three ColorPALs cannot all see the exact same scene at the same time, is this a problem? I'm not sure serially acquiring its data will be harmful. If it doesn't matter anyway, SoftwareSerial might be useful, as you won't need hardware, and you might be able to find a version that supports arbitrary bit rates.

    Of course, the hardware UARTs can receive at the same time, but remember if you are pointing them at the same place, what they see will still be slightly different. And, since each ColorPAL includes its own light source, I'm not sure that'll work anyway -- they might interfere with one another. Better ask Phil, who designed the ColorPAL and knows how it works.

    If you use the UARTs you need the extra circuitry from the post in your original message, and it's not complicated. Just wire as shown (1K resistor plus a standard signal diode). The parts are available at Radio Shack.

    In conclusion (and noting I don't work for Parallax), realize how insanely simple all this would be on a Propeller. Although you won't need to, you could set up each ColorPAL in its own cog, and very easily collect data from all three simultaneously. And by simultaneous, it's exactly that, as the cogs are separate cores than run independently of one another.
  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 23,514
    edited 2014-12-02 14:02
    You definitely don't want three ColorPALs simultaneously examining the same spot. Ideally, that's not possible anyway, since the snorkel will be in contact with the subject, shielding it from ambient light interference. But if one ColorPAL is examning the red component of an area, while another is examining the green component of the same area, you will get crosstalk and bad readings from both sensors.

    -Phil
  • EriolEriol Posts: 4
    edited 2014-12-05 06:02
    Of course, the hardware UARTs can receive at the same time, but remember if you are pointing them at the same place, what they see will still be slightly different.
    You definitely don't want three ColorPALs simultaneously examining the same spot. Ideally, that's not possible anyway, since the snorkel will be in contact with the subject, shielding it from ambient light interference. But if one ColorPAL is examning the red component of an area, while another is examining the green component of the same area, you will get crosstalk and bad readings from both sensors.
    No, I'm really looking at three different, separate locations but I simply want the data from those three locations to run an algorithm in my microcontroller. So that won't be a problem.
    As you're familiar with the ColorPal, Phil, do you think it's best to do them individually in the three UARTs or is there something intrinsic in how the ColorPal works that I'm ignoring?
    In conclusion (and noting I don't work for Parallax), realize how insanely simple all this would be on a Propeller. Although you won't need to, you could set up each ColorPAL in its own cog, and very easily collect data from all three simultaneously. And by simultaneous, it's exactly that, as the cogs are separate cores than run independently of one another.
    I will take the Propeller into consideration although I've never worked with it. I can start with this model for the Arduino, right? I guess I can start from scratch too with the Activity Board since it wouldn't be out of my reach to code in C/C++ and simply send booleans back to my main control schemes after all the data is processed.
Sign In or Register to comment.