Quote:
|
As we speak right now, the world of computing is zooming by us.
|
Wouldn't this be even more true if you weren't involved in FIRST? If FIRST provides an approachable and motivating task that exposes you to the real-world problems and some of the real-world tools, then you are better prepared to continue learning and tackle bigger and better things. If it is still your goal, you'll then be prepared to get into one of the fast-lanes of computing. Programming robots and real-time embedded systems is also quite different from databases or programming in general, and you are also being exposed to those differences.
Quote:
|
We are in the age of multicore/processor parallel processing ... the bottom line is that if we want to produce engineers of the future, expose them to the technologies of the new, not the old.
|
FIRST is trying to inspire the engineers of the future, but it is not fully responsible for producing them. If your resume only lists experiences such as robot programmer for FIRST team and auditing a few lectures from Stanford, and the woman next to you has a four year degree from a local state college, she is way ahead in the process. You will have to knock my socks off to get the job instead of her. She is better prepared, even if you are more inspired. FIRST is an awesome program, but I don't believe it is a replacement for higher level education and training.
If you can learn to apply the enthusiasm, team-skills, and GP you have seen in FIRST towards high school studies, college, and then work challenges, FIRST has accomplished its goals and you will accomplish yours too.
-------
Back to the technical stuff. Multi-tasking doesn't require multiple cores, and you have access to multi-tasking concepts in a variety of tools and approaches. C++ and Java have threads, tasks, processes, mutexes, semaphores, critical sections, and others. LV chooses not to directly expose threads, but uses dataflow specification to capture what can and cannot be run simultaneously, then uses threads and such to carry out the execution. This limits the need for synchronization of data access. For synchronizing access to other resources, it exposes semaphores, notifiers, events, rendezvous, RT FIFOs, and other synchronization primitives. All tools allow you to do multi-tasking and learn about the issues.
What I'm getting at is that the concepts and abstractions for multi-tasking are equally valid on a single core with a multi-tasking scheduler -- like the cRIO. More cores act as an accelerant, but aren't fundamentally different. If you learn these tools on the FIRST controller, they will be very similar on a PlayStation 3, on high-end workstations, and other MIMD architectures. SIMD requires additional tools, and while it is currently somewhat rare, that may change in the future provided GPUs and BIG FPGAs come down in cost. Again, the tools you are using are already being enhanced to support SIMD, and it is a continuation of what you are learning now.
A comment on the sudden issue with clock speeds -- it wasn't really that sudden. Supercomputers hit the wall twenty years ago, and tried many things including more CPUs. It is now impacting consumer devices, so more magazines write about it, more people talk about it, but it is the same problem, similar solutions, but different price constraints.
Finally, I suspect that your "need for speed" is related to vision processing. As I've mentioned in other threads, vision is a hungry hungry beast -- it will consume whatever CPU resources you have and demand more. Successful vision systems always benefit from and often require controlling the lighting, controlling the content in the scene, and skillful application of simple processing approaches. Oh, and lots of trial and error. Sometimes a bigger processor, or more processors is the right approach, but it also reaches diminishing returns, and rather quickly.
In terms of computing power, FIRST has enhanced the control system rather dramatically in the last few years. This will most likely continue, but it has to be balanced with cost. And on a robot, you don't only want fast processing, you want lots of sensors with precise timing, lots of outputs, tight control timing, and flexibility in how you combine those. Oh, and simplicity of setup is nice too. I'm not going to claim that the current control system is best in all these areas, but it scores well in many areas, and I'm sure that FIRST will continue to upgrade it to improve things. Meanwhile, it is not uncommon to find teams adding FRC-legal coprocessors to enhance areas such as vision. I knew of two last year that had a dedicated image processor capable of handling multiple cameras. If your team wants to lead the charge in atom-based or beagle-based image processing array, go for it. I'm not sure it will win the game, but it will satisfy many of the FIRST goals, and almost certainly win you some awards.
Greg McKaskle