|
Re: A few questions about the control system...
In LabVIEW on a cRIO (running VxWorks), you can use timed loops to get excellent timing accuracy. Self-measured jitter (reported by the OS) is usually tens of microseconds. I can't speak for other languages, but real-time constructs definitely exist in VxWorks and they seem to work very well. You can't use an oscilloscope to test this because I/O goes through the FPGA, and is inherently quite slow.
The new RoboRIO runs Linux with PREEMPT-RT. I can't speak for it's timing jitter, but I would expect it to be worse than VxWorks and better than normal Linux. It's good enough, if you use the timed loop constructs in Labview (not sure of the equivalent in C++, or if Java has any real-time constructs at all)
The challenge with a large OS like Linux is the addition of a ton of overhead in context switching, memory management, and normal computer interrupts and functions. Microcontrollers have none of this, and can dedicate their entire existance to handling low-level IO and running algorithm code without being bothered with handling context switches, paging memory, hot-plug USB devices, etc..
The fastest I have ever attempted to run algorithm code was for a powertrain control module (responsible for an engine and transmission in a car), on a 180mhz PowerPC with single float. It was able to run algorithm code as fast as 1khz (and I/O events and kernel internals much faster), with the bulk of the core engine code running at 100hz or more. The CPU utilization was usually under 50%. The big enablers for this was the complete lack of heap memory, filesystem, compile-time definition of all tasks and task tables, and co-operative scheduling of most tasks to avoid memory locking and context switching. 'Nice' features like dynamic allocation of of memory (aside from locals on the stack), per-thread or per-task stacks and contexts, process isolation, file IO, and separate driver modules (all with their own separate tasks), all take up a lot of CPU resources on a small processor. For the same CPU, a fully-featured OS will have far worse timing characteristics than a basic real-time OS or microcontroller.
Overall 100hz timing should be enough for FRC. 50hz is probably too slow for control loops, but good enough for driver/HMI interactions.
__________________
Kettering University - Computer Engineering
Kettering Motorsports
Williams International - Commercial Engines - Controls and Accessories
FRC 33 - The Killer Bees - 2009-2012 Student, 2013-2014 Advisor
VEX IQ 3333 - The Bumble Bees - 2014+ Mentor
"Sometimes, the elegant implementation is a function. Not a method. Not a class. Not a framework. Just a function." ~ John Carmack
|