Investigate alternative development paths for new members.

[AhmedSamara]

One of our biggest problems, especially this year, has always been orienting new people. Teaching them the existing codebase takes a lot of time, and in that time we often lose people.
A few people expressed frustration at this, and I think there's definitely some value in it. Building a project from scratch definitely has its merits, and I think it's worthwhile to start thinking of alternatives now and assign them to new people.
Start compiling any ideas for alternatives that you have here, even if they're not fully fleshed out, just so that newer people have a starting point.
The first thing we have to do is identify what resources we already have.

Currently in the locker we have:

• Pandaboard (Embedded Linux, maybe use to explore ROS? Investigate ROS for BeagleBone/RPI #419 )
• AVR Dragon
• Arexx (Came with the Dagu arm, repackaged Arduino Mega)

[SeanKetring]

Alternate localization strategy using IR range finders, or ultrasonics. Currently we have plenty of ultrasonics in the locker.

A possible starting point would be to reach a point of being able to follow the edge of the playing field.

[kvijay1995]

I've been looking into using the ultrasonic with the BeagleBone without using the PRUs and this doesn't seem like a feasible option. We might have to resort to some of the PRU code that @PaladinEng wrote in the past as seen in issue #69 to get the ultrasonics to work.

Any advice on this would be much appreciated @PaladinEng

[mynameis7]

If we want to move to any of the new BBB modules like @AhmedSamara proposed over the winter break meetings, we could put new members on reimplementing old modules in the new language. Make a whole new bot repository. Switching the existing backend for hardware communication will be a decent sized task that is easily split up because each of the components are modularized into their packages. If we want to continue working with webcams, we could attempt to work on moving the robot with opencv visual detection directly. I saw a cool video about a drone being piloted by OpenCV. If we make a system that can target certain things and drive to it with opencv that might be a useful generic movement tool.

[tabarrett]

Sean, VJ and I all messed around with alternate localization devices we tested Sonics using arduinos using code similar to this: http://www.theengineeringprojects.com/2015/02/interfacing-multiple-ultrasonic-sensor-arduino.html.
We also tried using a magnetometer(compass): http://www.funnyrobotics.com/2011/03/arduino-with-hmc6352-digital-compass.html. Both worked but the sonics had limited range and were off by a centimeter. The magnetometer recording were similar to the value from our smartphone compasses