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.

[biojae]

Originally Posted by kamocat

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.

Is that only in labview?
I have seen the dashboard updating at ~50hz using C++ and Java.

And as far as the camera goes, once the graphs were taken off the dashboard, I have gotten near realtime images at ~15 fps.

Which dashboard are you using? a custom one, or the one that was set with the updater?

[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.

~

[Vikesrock]

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.

We definitely had a dashboard image that updated MUCH faster than this (Labview on both robot and Dashboard). Unfortunately our camera was slightly skewed relative to the robot and fixing it was not a priority compared to other issues that cropped up at competition.

When I talked with the 16 drivers at Midwest, they said they used the camera feed pretty heavily. Based on the success of that robot I would say it is certainly possible to use the dashboard camera to good effect.

[Radical Pi]

We got a near-live feed from the camera after I rebuilt the dashboard without any graphs. The harder part was convincing mechanical to let me put it on the bot

[biojae]

Originally Posted by Radical Pi

We got a near-live feed from the camera after I rebuilt the dashboard without any graphs. The harder part was convincing mechanical to let me put it on the bot

So, they wouldn't let you put the dashboard on the robot? They have that much say in the software?

The camera on the other hand makes much more sense.