Is anyone using the Camera?

[MrForbes]

We'll find out next week whether or not we use it...it's mounted, programmed, and was kind of working when the robot shipped.

Some recalibration required

[writchie]

Based on what we saw in week 1 matches, we changed our camera focus to the live streaming. It appears that using live video 160x120 @25fps scaled up in our python dashboard to 320x240 is going to more valuable to the driver to aid in picking up moon rocks than for tracking targets, although we hope to get near instant mode switching working by the FL regional.

[comphappy]

We have a lock mode that we could not shake in the shop, we will have to see how that turns out on the field, I am concerned about the lighting issues mentioned in another thread. We found effective lock code was nearly impossible without the use of separate tasks in C++ (I dont know about labview nor do I care).

Note that semaphores are very important in this, and I recommend that you do not use the WPI "restricted region" (which is not much of an abstraction anyway) and access the vxWorks semaphores directly there are different types and they are each for very different situations.

[byteit101]

Originally Posted by writchie

Based on what we saw in week 1 matches, we changed our camera focus to the live streaming. It appears that using live video 160x120 @25fps scaled up in our python dashboard to 320x240 is going to more valuable to the driver to aid in picking up moon rocks than for tracking targets, although we hope to get near instant mode switching working by the FL regional.

do you remember that our bandwidth is being limited to ~950 bytes every 0.02 seconds (50 hz)? i don't think that will work.

[Team 135]

We have some prelim code done and tested, the problem is that our bot will fall into osculation because of the low traction. We ended up not using it at our 1st regional because of that. We are working on that now and hope to have it up and going for Purdue.

[Taylor]

Originally Posted by Team 135

We have some prelim code done and tested, the problem is that our bot will fall into osculation because of the low traction. We ended up not using it at our 1st regional because of that. We are working on that now and hope to have it up and going for Purdue.

You almost won MWR with a not-fully-functioning robot, and you'll have it fixed at BMR? ::scary::

[writchie]

Originally Posted by byteit101

do you remember that our bandwidth is being limited to ~950 bytes every 0.02 seconds (50 hz)? i don't think that will work.

The user data is 984 bytes * 50 hz = 49,200 Bytes per second (393 kbps ).

An appropriately compressed 160x120 image is 1300 - 1800 bytes. We fit each image over two packets, along with a pretty decent amount of telemetry.

160x120 is a bit small, so we stretch it to 320x240 on our Dashboard. Because the eye integrates video very well, it's much more than usable for the driver.

[ZakuAce]

We're certainly using the camera to track the targets and automatically aim our turret, unless the programmers decide to stream video from it. Whichever one is easier is the one we're going for.

[Petra Hartman]

The camera we have programmed on our robot tracks opposing trailers, chases after the trailer, then when it gets about a foot away starts the belt holding the moon rocks and dumps it in. The program worked actually really well at the DC regional, except for 2 or 3 times were the camera lost patience or the target for whatever reason.

[EricLeifermann]

We had the camera sending video back to our laptop at the control station and it was pretty much seamless, i was expecting it to be really bad refresh rate but we had no trouble with it at Traverse city.

[SteveGPage]

We had a couple of software issues at start of the DC Regional, but as the tournament went on, I was assured it was working. Since we did not have a chance to fully test it out on the practice field, we choose not to use it and relied on manual control of the turret and shooter. We expect to have it up and running at Chesapeake, however. We will still have the turret under manual control until just before firing, when we will allow the camera to lock on the target and then fire.

[Akash Rastogi]

We used our camera at Trenton along with a few other sensors that we'll try to perfect at Philly. At the moment we've only risked trying to score 2 balls in autonomous while placing the other 5 in our conveyor ready to load the hopper in teleop. We were extremely proud of our programmers for making it track very well.

[gorrilla]

we're using it,

we have it working perfectly


All Zach has to do it aim the turret towards a trailer, and then the camera takes over and follows it.

[slavik262]

We're having some difficulties with the camera.

It's working, but response time is ridiculously slow (> 0.5 seconds). I'm not quite sure what's causing it. I'm just using the FindColor() function provided in the API, and I even tried to speed that up by allowing multiple calls to use the same image (so that you don't have to get a new image for each call). Still no luck.

The only thing thing that I can think of as the cause is that I'm using a multi-tasking system (the drive train, collector system, and shooter system all have their own tasks, using a buffering system of my design). I don't see how they would be slowing things down to that point, however, as all other tasks have very fast response times ( < 0.05 seconds).

Any ideas what may be the problem?

[gorrilla]

Originally Posted by slavik262

We're having some difficulties with the camera.

It's working, but response time is ridiculously slow (> 0.5 seconds). I'm not quite sure what's causing it. I'm just using the FindColor() function provided in the API, and I even tried to speed that up by allowing multiple calls to use the same image (so that you don't have to get a new image for each call). Still no luck.

The only thing thing that I can think of as the cause is that I'm using a multi-tasking system (the drive train, collector system, and shooter system all have their own tasks, using a buffering system of my design). I don't see how they would be slowing things down to that point, however, as all other tasks have very fast response times ( < 0.05 seconds).

Any ideas what may be the problem?

are you using any sensors?

we have a gyro and accelerometer and 7 motors all running and there's no delay....

is it on a rotating turret?

we had this problem, but solved it by decreasing the speed of the rotation and now it lock on in under .5 second from 6 feet....


although our camera is set to only track pink....