Setting expectations with TI's EVALBOT.
Robotics are a fantastic way to get students engaged with Electronics. I'm a particularly avid supporter of the tops down approach for students--but find myself a little conflicted in regards to Introduction to Electrical and Computer Engineering courses.
The conflict occurs when I see hardware at the Intro to Engineering courses-- that are either some version of a toy, or on a platform that a student will never encounter in Industry. It is my opinion that this is acceptable when education is compulsory (in high school or in clubs where vying for the student's attention is critical), but at the University level and Vocational College level-- exposure should be as relevant as possible. After all, most students the purpose of going to college is to be employed when they graduate. Shouldn't the expectation be set in the very beginning to learn on platforms students would run into as engineers in the workforce?
*Side Note: The inspirational teaching model for me is the Auto Industry and how many kids become Mechanical Engineers. E.g. When a teenager gets interested in cars... he usually begins to learn about the object of his interest the car and doesn't get a golf cart first to learn on.
Not to demean platforms designed to capture interest of non-electronics audiences.
Broad appeal platforms do exactly that-- grab people's attention! Once the attention is obtained-- then it's up to the skill of the instructor to make the associated concepts apparent to the student. Otherwise, the experience is no more effective than a structured play session... and we don't need to pay for structured education for that.
My primary concern in using toys or simplified versions of tools is this: there is the danger that the follow on courses will be so different from the safe, well structured environment that the student was exposed to-- that anything that is fairly industry standard will shock and feel like foreign world. This in turn will demotivate a student!
One of my favourite University visits was when a student who had been programming exclusively in the Arduino IDE opened up a competitor's IDE (also Eclipsed based framework) and let out, "Well, we aren't in Kansas any more." He proceeded to tell me all of the deficiencies in this framework using Arduino's simple editor as his reference point. Sadly, if he looked at TI's IDE, he would have had the same complaint or even IAR Systems (the top choice for most embedded designers).
It's expectation setting.
Teach a student that programming can happen in three clicks... and every environment after that one will feel "wrong".
However, teach a student incremental concepts that he or she can personalize/relate to-- and not only are you teaching students-- but you are also preparing them.
I am convinced that students who's first experience with hardware/software that doesn't go 100% perfect-- learn how to ask the questions to WHY certain conditions exist. Those who end up being some of the best engineers in inudstry ask, "How can we prevent this in the future?"
Taking away that real world experience? Insulates the student from common WHY? questions they would have begun to ask. Worst yet, it pushes it into after they graduate when their performance is in evaluation.
Some of my best teachers did not shield me from difficult concepts early on. In fact, many times they did not hide the difficulty of the concept, but instead used it as an opportunity to gauge my comprehension abilities. They were in essence outlining the requirements and letting me assess my own abilities against that measurement.
Let me give you an example of a course that is currently in testing phase.
At the Introduction to Electrical and Computer Engineering level- freshmen are required to take this course in conjunction with the Introduction to Engineering.
The first course consists of a video-- of this re-brained Roomba running a course.
The professor takes time to introduce the concepts that are taught in creating one of these.
Microcontroller, software, controls, programming , etc.
He ends the lecture on explaining that students by the end of their time will be able to create systems that are much more complex and fully featured.
He doesn't spend a great deal of time "dumbing" down the concepts. He uses the real terminologies and shows the actual use of the concepts.
The second time, they are introduced to EVAL-BOT.
Perhaps the students don't understand what a Quadature Encoder is and how it functions, but the term is introduced.
I asked what was the basis of introducing these terms even though most of the students won't know what it is. He replied, "The interested students can look it up, the students that aren't will run into it later and have heard it before."
This section is about unboxing the Eval-bot and using it as is-- the finished product.
The next session is now introducing the concept of changing the fixed function that the bot shipped with.
e.g. "That's nice that the bot does this little roomba routine, but say that I wanted to tell it where to go-- how would I do that?"
Discussing what would need to happen to change the robot's function-- adding interfaces, changing the program-- then allowing the students to try it out.
*Stellaris has a neat FlashProgrammer that allows students to re-flash any of their development kits to a different demo (that has already been loaded into the FlashProgrammer) without ever having to open an IDE. This is useful if you're not ready to introduce C Programming yet. *Refer to this blog post on how to do this Evalbot Chronos Change.
The next meeting discusses the differences between changing a function-- to being able to alter a fixed function.
This is where the concept of "configuration" is introduced. This is where students open up the IDE and get an explanation of what an IDE is, what parts make up code. They then open the code that changed the Eval-bot's function in the previous lab and see the different parts. It's here we have them configure the bot to a certain specification.
(e.g. Change the OLED display from Micrium OS EvalBot to - I <3 ECE-)
*StellarisWare helps with this step, that the individual graphics are just function calls and to activate the display is a function call.
Then, the next lab consists of customizing how the robot behaves.
The student will insert a new set of code.
Explaining what has to happen on the lowest level for the code to interact with the bot.
Guiding the student through introducing new elements.
Eg. Adding the #pause# function for the Chronos Watch- Evalbot demo-- where hitting a button on the watch lets the bot go into a waiting state. or Making the Evalbot sing the first twelve tones of the imperial march.
Walking them through this example.
Then ... have them switch examples and try it out on their own + ask questions.
Often times educators forget. These are not just high school students sitting in their intro courses. Often times these are the top 10-20% of their graduating classes with SAT scores that would put any of us to shame.
These students are highly capable and should not be underestimated. It is mastering the correct balance of introducing concepts in the right order, plus being able to explain it in a manner that makes sense to the student-- that is the responsibility of the educator.
The payback is immense-- I've seen time and time again. Just like with pre-tests, it shows students what concepts they need to learn... so they are able to discern a level of importance themselves of what they are being exposed to-- this in turn makes the experience personal.
Give the student a target.
Let the student measure themselves against that target for progress.
Don't treat the students as if they are unable to understand.
Don't overreach comprehension-- focus on the facts rather than the potential. This is a Analogue to Digital Converter. An Analogue to Digital Converter is useful in taking real world signals and making the microcontroller act upon those. Next, go into more detail at the Analogue to Digital Converter section.
Expose the Student, Demonstrate for the Student, Guide the Student then give the student space to practise on their own.
Have high expectations-- and students will most likely strive to achieve those.
I contend that students at the Freshman ECE Engineering level are fully capable of being introduced to serious microcontrollers early on--all they need is an educator that sets the tone for them.