Quote:
Originally Posted by Robototes2412
*sigh*
What I meant is it is always a good idea to know how the device you are programming works. I don't have a college-level education in this stuff, I only know what I can reverse-engineer. I think that the best way to learn how these robotics platforms work is to try things, read manuals, and mess up. Failure is the best teacher.
I am currently teaching a couple freshmen how to hack at stuff. I had them start with a ps/2 mouse and an arduino, and they turned it into encoders for our robot.
"I don't believe in shortcuts! I believe in the almighty GPL!"
|
You do have a good point.
It's essential for the programmers to understand the underlying technology if you expect them to recover from failures. How can they fix a problem if they can't isolate or identify it?
Autonomous is certainly not how you start programming a robot. Start with learning how the system works. What is PWM? Why is it used as a data signal? How (and why) is it used to control the speed of the motor? What is the "braking" action of a brushed DC motor? Why can't the motor run at infinitely slow speeds? What are encoders and potentiometers? How does the health of the battery affect the performance of the motor? What is an FPGA? Why is it used instead of a processor?
I think the WPI library is fairly low-level, though if you wanted, you could periodically generate digital pulses with digital outputs. Having a standalone PWM-generator is also useful. We put a speaker on ours when we made it, so you can actually hear the square wave change as you adjust the duty cycle.
Anyways, understanding how the components of the system work is necessary to understand how the system can fail.