CMUcam4

void search()
{
  //rotate the camera until it finds the color, then begins tracking it
  boolean colorLost = true;
  int pos;
  while (colorLost) {
    for(pos = 1500; pos < 2250; pos+=9) {
      cam.setServoPosition(0, 1, pos);
      delay(10);
      cam.getTypeTDataPacket(&data);
      if (data.pixels != 0)
        colorLost = false;
    }
    for(pos = 2250; pos > 750; pos-=9) {
      cam.setServoPosition(0, 1, pos);
      delay(10);
      cam.getTypeTDataPacket(&data);
      if (data.pixels != 0)
        colorLost = false;
    }
    for(pos = 750; pos < 1500; pos += 9) {
      cam.setServoPosition(0, 1, pos);
      delay(10);
      cam.getTypeTDataPacket(&data);
      if (data.pixels != 0)
        colorLost = false;
    }
  }
}

// This is in the loop()
void loop()
{
  cam.getTypeTDataPacket(&data);
  if (true) { //if tracking colors is lost
    search();
  }
}

To clarify, we want the pan servo to sweep back and forth until it finds the tracked color. For some reason, when we comment out the line with "cam.getTypeTDataPacket(&data);" the servo sweeps fine. But when that line is in the code, it goes extremely slowly--going about a degree every few seconds. Do you know what could be the problem here?

So, the getTypeTDataPacket function just looks for and returns a type T packet from the data stream. It does not start the data stream. So.. the problem you have it that you have not started the data stream yet.

You have the call the trackCOlor(), trackColor(redMin, redMax, greenMin, greenMax, blueMin, blueMax), or trackWindow(redThreshold, greenThreshold, blueThreshold) function first to start the data stream. Once you do that you can then call the getTypeTDataPacket function to get a type T data packet.

Similarly, the getMean() function starts a data stream with type S data packets and the getHistogram(..., ...) function starts a type H data stream.

I have a few pieces of example code that show this with the Arduino Library.

Remember, you need to set the color you wish to track first. You do not do that in the above code. So... either set the color once by calling setTrackingColor(redMin, redMax, greenMin, greenMax, blueMin, blueMax) and the call trackCOlor() in the loops to start the data stream... or just call trackCOlor(redMin, redMax, greenMin, greenMax, blueMin, blueMax) to start the data stream with your choice of color bounds each time.

The trackColor function is overloaded. So, calling it with 6 color values causes it to set a color to track. While calling it with no arguments causes it to track using whatever the previous color set to track was. Afterwards the trackColor function always starts streaming type T data packets.

Thanks,

Okay, so we have the data stream running. But when we use the getTypeTDataPacket function in our loop, the system goes much slower (very noticeable that it takes a second to retrieve each packet). Is that supposed to happen?

The library returns error statuses for all commands - you can use them for debugging purposes. If it takes a second its most likely that the command is failing due to a timeout error.

Please try using the starter code the library has in the example folder and then build from there. The example code works. There is one example file that shows how to get tracking data packets.

Also, there are timeouts built into the system. If you are using the 8 FPS firmware then the behavior you are seeing may be normal. This is because the CMUcam4 will drop 3 frames every time you call trackColor. Then when you call getTypeTDataPacket it will take another frame. Then setting the servo will drop more frames because you exited streaming mode. At 8 FPS this is a hefty amount.

So... it may be that you are dropping too many frames because you are switching the camera in and out of different modes.

If you just run the example code that gets type T data packets it should return them at the rate of whatever the frame rate is for the firmware you are using. v1.01 is the 8 FPS firmware. v1.02 is 30 FPS.

Update to the 30 FPS firmware if you have not done so already. This problem will then become less severe. In general you want to avoid switching the CMUcam4 in and out of streaming mode if you want to have high performance.

The reason for dropping frames in the CMUcam4 code is to ensure that any settings you tell the CMUcam4 to take on are reflected in the output from the CMUcam4. So, a few frames have to be dropped every time you change a setting or enter streaming mode. Streaming mode is where the CMUcam4 starts sending you packets.

The benefit of dropping frames on the CMUcam4 is that I can guarantee you that if you change a setting on the CMUcam4, then any data you request from the CMUCam4 after changing the setting will reflect the new setting.

You may wish to connect the servos to the Arduino. Then you don't have to tell the CMUcam4 to move them. You can then just use the CMUcam4's vision features only and keep it in streaming mode which will allow you to hit the maximum frame rate.

Thanks,

Hi Kwabena, we are very thankful for all of your help while doing this project. Take a look at the bottom of our acknowledgments from our poster presentation!

Hi J M,

If you have material about you project and wouldn't mind having it featured on the website I'd be happy to post it.

Thanks,

Hello,

Did my partner email you information about our project?

Here's some more:
Here's a website link for the research we did: http://education.gsfc.nasa.gov/nycri/research/RU.html
Here's a video of our robot working: https://www.youtube.com/watch?v=jlW5nVnmIpU

Thank you for all your help. Couldn't have done it without you.

No he never did, if you give me all the information you would like posted to this website I will make a project page for you guys.

Please email the info to cmucam@cs.cmu.edu.

Thanks,

Hi,J M.
I want to know if there's a code to let cmucam4 do the same thing like the demo mode.