[faust1706]

We are using the depth camera on the kinect to detect objects, and then be able to go in between two cones from the depth map data.

2013 was our 4th year using macanumm wheels. We used then in logomotion, and 2 other years I was not a part of the team. This year, we had a PID to lock on to the 3pt target based off of vision solutions, and continuously locked onto the target while strafing in and direction. To do obstacle avoidance, it'd basically be the direct opposite. After we find a target, simple (3D, depth is calculated) vector calculus (well, not so simple) can be applied to figure out the velocity (and acceleration) of the object, be it a wall or robot in relation to our robot (which is of course considered stationary at all times. -relativity FTW)

Using this information, one would be able to avoid objects. The question arises as to how fast such computations could be made and also how effective they would be in a dynamic environment. For instance, say your robot couldnt go under the pyramid, and this program tells the driver to drive under it, what then?

Our team as thought about having preprogrammed jukes for our higher speed drive trains. I couldn't count how many head on collisions there were between cycler bots this years, be it cycler to cycler or cycler to defensive bot. So, say left trigger is a "spin move" left, right trigger vise versa. I believe that would prove to be much more effective. Simplicity is best, as nathan_hui hinted at.

I love seeing teams at least thinking about things like this. I feel that I have learned so much more by developing these complex systems even if they aren't used. I feel that it is just icing on the top of everything FIRST provides.

yours truly,
someone who overthinks everything.