Demystifying autonomous...

[JBotAlan]

I just had a bit of a brain blast. It probably won't be so great grammatically or organizationally because I'm not feeling so hot right now, but wanted to write this down.

It is so difficult to explain to those uninitiated with programming why I can't "just make it go straight for 3 feet, then turn left"...what they don't seem to get is how the robot actually sees the world.

So...

How about having a session before the build season in which we explore what life is like for a robot? Take each of the kids, put a blindfold on, and have them navigate through an obstacle course. Ask them what they did to keep on course, and then draw the parallel to different sensors on the robot.

Then you could proceed to write up steps of how to get through said course, after outlining which sensors would be necessary.

Maybe even give a good heads-up display of sensor values (SANS CAMERA) from the robot sitting around the corner. Give the controls over to a student and watch them figure out the shape of the course based on a few microswitches, an ultrasonic, and a gyro.

It would require a bit of elbow grease on the programmer's part, but I think the effort would pay off.

Input? Anyone done something like this before?

[Andrew Schreiber]

Actually, sorta. Was working at an FLL camp, we were teaching concepts of programming. We blindfolded one student and had another give them instructions. It really made them realize how blind their robots are.

[Mark McLeod]

I use pin-the-tail-on-the-donkey as a practical example.
Blindfolded, spun around, don't touch anything - now find the target in one shot.

[gvarndell]

Originally Posted by JBotAlan

How about having a session before the build season in which we explore what life is like for a robot? Take each of the kids, put a blindfold on, and have them navigate through an obstacle course. Ask them what they did to keep on course, and then draw the parallel to different sensors on the robot.

It's analytical, I love it.

[Dkt01]

This would be hilarious to watch. But it would also be a pretty good way to show what autonomous really is. The closest thing we did was at the beginning, we set up a field and walked around as robots. To simulate autonomous, we were blindfolded. Needless to say, everyone struggled with the "autonomous period", but your idea sounds like one of the best ways to simulate what the robot is thinking.

[kamocat]

What I did to demonstrate the (un)usefulnes camera is to close one eye, and put your hands in a tube around the other eye, to give yourself that 30 degree view angle. (+-15 degrees)
What I didn't have them do is chop it to 10 frames per second. (blinking continuously might work)

Anyways, it was effective at eliminating the wish to get it sent back to the dashboard, where it would only be updated once a second.

[Ether]

Originally Posted by kamocat

Anyways, it was effective at eliminating the wish to get [the camera video] sent back to the dashboard, where it would only be updated once a second.

I know that the other dashboard data gets updated only once per second, but is this true for the camera image also? I thought the camera image was not part of that 50-element array.


~

[mcb]

My team did this activity in the fall with the FLL team that we mentored. Not only did it help to explain programming but it also served as a team-building exercise. One kid, the "robot," put the blindfold on and another would direct them where they needed to go, acting as the code. It worked really well!

[kamocat]

Originally Posted by Ether

I know that the other dashboard data gets updated only once per second, but is this true for the camera image also? I thought the camera image was not part of that 50-element array.


~

The dashboard uses "Get camera image on PC".
I can't find anywhere in the code that it *says* it takes 1000ms to happen, but I tested it, and I think that's how long it turned out to be. This may be on purpose, seeing as they were worried last year about the bandwidth it would incur.

[AdamHeard]

Originally Posted by kamocat

The dashboard uses "Get camera image on PC".
I can't find anywhere in the code that it *says* it takes 1000ms to happen, but I tested it, and I think that's how long it turned out to be. This may be on purpose, seeing as they were worried last year about the bandwidth it would incur.

I know teams were able to get the camera image to be nearly real time.

[Ether]

Originally Posted by kamocat

The dashboard uses "Get camera image on PC".
I can't find anywhere in the code that it *says* it takes 1000ms to happen, but I tested it, and I think that's how long it turned out to be. This may be on purpose, seeing as they were worried last year about the bandwidth it would incur.

I don't know for sure, but a few weeks back when a LabVIEW programmer was showing me the cRIO code that packages the Dashboard data it looked to me like the camera image was not being packed into the 50-element array but rather was being updated separately at a higher rate. Second hand info: I asked a team member who had seen the dashboard camera video and he said it looked to be updating a lot faster than once per second. This was with unmodified (default) 2010 FRC LabVIEW framework code.

~

[Joe Ross]

Originally Posted by Ether

I don't know for sure, but a few weeks back when a LabVIEW programmer was showing me the cRIO code that packages the Dashboard data it looked to me like the camera image was not being packed into the 50-element array but rather was being updated separately at a higher rate. Second hand info: I asked a team member who had seen the dashboard camera video and he said it looked to be updating a lot faster than once per second. This was with unmodified (default) 2010 FRC LabVIEW framework code.

~

You are correct that the camera images is handled completely separately from the dashboard data.

The default LabVIEW framework code updates the high priority dashboard data in Robot Main (50hz). The Low Priority dashboard data is updated at 2hz (IIRC). For an example of the high priority data updating fast, look at the camera tracking information in the lower right corner of the dashboard.

[ideasrule]

Team 610 is another team that, after a lot of effort, got a real-time (as far as our eyes could tell) feed at 320x240 resolution. The drivers depended on it heavily at the beginning, not so much after they got more experience in aligning the robot with the goal.

[apalrd]

We did some camera-driving on our practice bot. We found that, while the image gets a good framerate, it does is not close to realtime. It appeared to be around 10hz video, however it was around 1s behind reality. This fooled our driver into thinking it was actually updating at the speed it appeared, which it did not (btw, I noticed this same thing on the Dashboard I wrote - the data not the camera - no graphs). After the driver (and I, since I was the only other one there and was having fun), got used to the delay, we were able to drive the practice bot through a door (without bumpers), even with the camera mounted far to the side of the bot and partially obstructed by the claw. We also noticed some (lots of) lag with the controls when using vision processing (find ellipse), but with just the camera to the dashboard it was fine. We were able to keep the robot aligned with a line on the floor (edge of the road inside CTC) at full speed in high gear (around 12fps) using only the camera, then shift to low and navigate a narrower hallway into a room, from a different room. It works quite well.

As to the original intent of this thread, I once taught a programming class at an FLL camp, and we played this game where we had two students, sitting back-to-back with identical bags of legos, and we had one student build something and describe vocally to the other how to build it. This taught them how important good instruction is for good execution.

[Radical Pi]

Originally Posted by Joe Ross

You are correct that the camera is handled completely separately from the dashboard data.

The default LabVIEW framework code updates the high priority dashboard data in Robot Main (50hz). The Low Priority dashboard data is updated at 2hz (IIRC). For an example of the high priority data updating fast, look at the camera tracking information in the lower right corner of the dashboard.

Actually, that is only the tracking data for the camera. The actual images are sent independently in a (UDP I believe) stream that is started when the camera is first called in code. The dashboard packers have nothing to do with this stream