3 ms·

you really don't need a fancy RTOS for this stuff maybe you don't, but genuinely curious how do you validate/guarantee scenarios then?

BugsJustFindMe 8y ago
I suppose my best questions back to you might be: 1) What concrete guarantees do you think you get from a special RTOS? 2) Which of those guarantees are meaningful to the scenario? 3) How (by what mechanisms) do you think the special RTOS guarantees the things that it guarantees? 4) Which of those behaviors are something that only an RTOS can provide?
- Keyframe 8y ago
  Among other things, determinism, since timing can be guaranteed (within a margin). RTOS will run with consistent timing, which is guaranteed and facilitated by control over tasks priority and checks whether timings are met. You could probably do that without a hard RTOS, but without any sort of formal guarantee. So, it might work all fine and dandy, until it doesn't. Doesn't should not exist in a hard RTOS by definition and proofing of it.
  - BugsJustFindMe 8y ago
    You don't need an RTOS to know that a system without extraneous background processes isn't doing extraneous background processing. Where precisely do you think think your timings are going? You're not also running a Minecraft server on the nav computer. Using Linux doesn't mean you also need to enable stupid PC things like search indexing or seti@home. Navigation isn't resource constrained. The only resource constrained component in the whole system is the computer vision module and it's going to be on its own processors, and the rate at which it can hand off new output is on far faaaarrrr longer timescales than your interprocess communication latency.
  - balp 8y ago
    Yes, thata one of the RTOS thing, but almost always, when trying to build this down into what these timing limits are, they are kinda arbitrary, gut feeling put into a number. There are exceptions, yes, usally these exceptions as well are only for a limity subpart of the system. So for this using RTOS for everything is as stupid as not using RTOS, (or possibly even puting these parts into hardware, ASIC of FPGA) for these small subsystems. These timing used, also is mostly up to scheduler and Linux is possible to run with a scheduler that gives it similar capabilities ans most RTOS systems. It's a blury grey area at best.
    - planteen 8y ago
      Yes, this is so true. When someone has a true jitter-sensitive task that needs to run on say microsecond or sub-microsecond accuracy, that is not for the realm of a high-performance CPU with caches even if it is on a RTOS. My first question is if that tight of a bound is truly necessary or just an over-specified requirement. If it is necessary, I say do that in hardware or on a simple microcontroller (e.g., Cortex-R) if that is truly your requirement.

BugsJustFindMe 8y ago

I suppose my best questions back to you might be: 1) What concrete guarantees do you think you get from a special RTOS? 2) Which of those guarantees are meaningful to the scenario? 3) How (by what mechanisms) do you think the special RTOS guarantees the things that it guarantees? 4) Which of those behaviors are something that only an RTOS can provide?

Keyframe 8y ago
Among other things, determinism, since timing can be guaranteed (within a margin). RTOS will run with consistent timing, which is guaranteed and facilitated by control over tasks priority and checks whether timings are met. You could probably do that without a hard RTOS, but without any sort of formal guarantee. So, it might work all fine and dandy, until it doesn't. Doesn't should not exist in a hard RTOS by definition and proofing of it.
- BugsJustFindMe 8y ago
  You don't need an RTOS to know that a system without extraneous background processes isn't doing extraneous background processing. Where precisely do you think think your timings are going? You're not also running a Minecraft server on the nav computer. Using Linux doesn't mean you also need to enable stupid PC things like search indexing or seti@home. Navigation isn't resource constrained. The only resource constrained component in the whole system is the computer vision module and it's going to be on its own processors, and the rate at which it can hand off new output is on far faaaarrrr longer timescales than your interprocess communication latency.
- balp 8y ago
  Yes, thata one of the RTOS thing, but almost always, when trying to build this down into what these timing limits are, they are kinda arbitrary, gut feeling put into a number. There are exceptions, yes, usally these exceptions as well are only for a limity subpart of the system. So for this using RTOS for everything is as stupid as not using RTOS, (or possibly even puting these parts into hardware, ASIC of FPGA) for these small subsystems. These timing used, also is mostly up to scheduler and Linux is possible to run with a scheduler that gives it similar capabilities ans most RTOS systems. It's a blury grey area at best.
  - planteen 8y ago
    Yes, this is so true. When someone has a true jitter-sensitive task that needs to run on say microsecond or sub-microsecond accuracy, that is not for the realm of a high-performance CPU with caches even if it is on a RTOS. My first question is if that tight of a bound is truly necessary or just an over-specified requirement. If it is necessary, I say do that in hardware or on a simple microcontroller (e.g., Cortex-R) if that is truly your requirement.