Vision Tracking Question

[Jayd009]

Hello everyone,

This summer, my team is going to add a high goal shooter and vision tracking system to our robot. The vision system will consist of a Raspberry Pi 2, an Axis camera, and one ring light. The Raspberry Pi 2 will run GRIP and report the values back to the RoboRIO. However, my question is how can I configure the robot so that GRIP will start as soon as the robot turns on? I understand that this may be impossible, but it would be very helpful so if we make it to eliminations at GRITS (Georgia Robotics Invitational Tournament and Showcase), we don't have to spend time manually turning on GRIP after we switch out the batteries.

Thanks,

Jonathan

[FlamingSpork]

If you're running GRIP on the RasPi, you can set GRIP as a scheduled task.

You would connect to the Pi, and run "crontab -e", then edit it so that it has a line like this:
@reboot java -jar /home/pi/grip.jar <or whatever your GRIP command is>
That command will be run whenever the Pi turns on.

[BrianAtlanta]

We used a similar setup, but a USB camera. We helped out a team that had problems with using the IP camera. Turned out the the PI would boot faster than the camera. This caused problems. We helped them trouble shoot the issue, and a ping was setup to detect if the camera was responding before starting vision processing. I think they used openCV directly and not GRIP.

This might not be a problem for you, but after you get things working, I would suggest that you unplug the camera and boot up the pi. Then after GRIP starts, plug in the camera. If it works, GREAT. If not, add some method of detecting if the camera is booted up before starting GRIP.

[GreyingJay]

We did something similar with some OpenCV code our team wrote and published called Trackerbox2.

https://github.com/FRC2706/TrackerBox2

The Pi 2 is set up via scripts to start trackerbox2 when it powers on. It waits for the IP camera to be available by pinging it first.

[prensing]

You can also put start up code in /etc/rc.local. That will run at the end of boot. But as others have said, you might need to wait on the camera to be up.

However you start it, I suggest you put that code into a bash script (or similar) so that all the logic is in one place. So something like:
/usr/local/sbin/startGRIP
If you put it in /etc/rc.local, end the line with "&" so that it spawns a separate process and does not keep the boot waiting.

[David Lame]

We used vision tracking this season, but we want to port it to a Raspberry Pi and OpenCV.

I'm curious why people seem to want to use an IP camera or a USB camera with the PI. What's wrong with the Pi camera module?

I know that it has a bit of a "fish eye" issue, but that's correctable with camera calibration. From what I've read, USB cameras with the PI are significantly slower, but I haven't verified that myself, and I just read it on the internet, so take that for what it's worth

[GreyingJay]

I'm curious why people seem to want to use an IP camera or a USB camera with the PI. What's wrong with the Pi camera module?

I know that it has a bit of a "fish eye" issue, but that's correctable with camera calibration. From what I've read, USB cameras with the PI are significantly slower, but I haven't verified that myself, and I just read it on the internet, so take that for what it's worth

In retrospect, yes, we should maybe have explored this option further. The choice of hardware was dictated more by what was available to us at the time.

We mounted our IP camera on a servo-controlled pan/tilt module. The intent was that camera image would be picked up by the Pi, it would perform its image processing, and send targeting data to the RoboRio via a TCP connection. The RoboRio could then command the servos to move the camera if needed. We thought we would move the camera to stay with the target it was tracking, and/or have an override by the operator to look around.

In the end we more or less fixed the camera position and didn't end up using all the features we built into it.