Quote:
Originally Posted by ekapalka
I'll put up some graphs to show our results when I get the pictures off of the camera.
|
That will be interesting to see. I think the point that persons in this thread are making is that "how fast is a task" is a verrrrry relative question. For example, I could code a simple task that ran in a tight loop and set the priority as great as possible (0 using the VxWorks native API or 99 using the Posix API). The speed of your task would be limited (only) by the throughput of the CPU, the nature of your code (does it all fit in cache, is it optimized etc) and what is going on in interrupt context. Of course nothing else in task context would ever run.
The real question (I think) is if we run at a priority that does not interfere with the operating system (exception handling, log messages etc) or the NI and WPI infrastructure (loaded when we image the robots, saftey and DS comms etc), what sort of performance might one expect. But even this measurement is relative - you might have a complex multi-tasking application where you are concerned about meeting periodic deadlines.
The "professional" way to handle this general question is to analyse all the code running on the robot. Google "rate monotonic analysis" - it is a widely used algorithm. The beauty of VxWorks (as opposed to Windoze) is if the analysis says you can meet all your timing parameters, the operating system will guarantee the performance. Make sense?
Of course in FIRST such an analysis might be impractical. So we run as many PID classes as we can, optimize the vision processing and pray. FIRST 1296 moved the vision processing to a Rasberry Pi and find that the cRIO can do most anything you ask if properly coded. In real-time programming there are a few time killers that programmers forgot most often - formatted print statements, memory allocation and long spinlocks can kill you. For this reason do NOT output stuff to the console in your normal (non-debug) modes of operation, allocate your memory as the robot powers up in an initialization phase and use proper operating system primitives (like mutual exclusion semaphores) to protect shared code or hardware. Also beware of C++ and Java - try to use constructors and templates that allocate memory up front and do not free and allocate memory in critical regions of your code.
HTH