Most people use ROS in robots because it is easy to integrate the sensors, and has a lot of things already developed.
However I would like to know if there is any Real Time OS for Jetson. For some applications, this Real Time thing is extremely important.
See the list of distributions, these are Linux derivatives however. Using the Technical Reference Manual (TRM), you could code support for other OS for the CPU and peripherals. Also ROS is available, see JetsonHack’s article for TX2.
Are you referring specifically to this for “real time”, and not “robot operating system”?
[url]https://en.wikipedia.org/wiki/Real-time_operating_system[/url]
[url]https://en.wikipedia.org/wiki/Comparison_of_real-time_operating_systems[/url]
It sort of sounds like you are looking for an RTOS substitute to ROS. Currently the Jetsons are all just soft real-time, I don’t think anyone has ported a hard real-time o/s (not to be confused with Robot Operating System). Aarch64/arm64 is a bit too new.
I agree that it sounds like uwf looks for a hard-RTOS, and I also agree that I don’t think anyone has anything like that yet.
Or, as some of us prefer to think of it, the RTOS vendors are too slow :-)
64-bit ARM has been around for quite a while now, even some parts in embedded form.
I can’t deny that a hard-RTOS would be the ideal for me.
I believe it is a matter of time until they develop hard-RTOS for Aarch64/arm64, it is hard to find hardware small and powerful as the Nvidia Jetson. Also, I understand the purpose of this board is mainly for processing images, or sensor data to come up with path planning and decision making, in the case of autonomous vehicles. Tegra is playing a big part on autonomous vehicles with the PX2.
There are a lot developed for x86 for control systems, but in my opinion arm64 is the future.
You could also contact the folks at Concurrent RedHawk. They have arm64 support starting with version 7. I checked on the status with them and it’s ready for Jetson TX1 and available soon for TX2. It’s a realtime variant of RHEL.
Does Concurrent RedHawk supports cuDNN, CUDA drivers or Open-CV ? Also, in given below link, they mentioned about “The Vertical Partitioning Concept”. Could we dedicate Denver cores to have Real Time OS behavior for some applications as mentioned in the given below link?
Yes regarding CUDA drivers, cuDNN, OpenCV. You would have to ask them what they support regarding extra partioning of the CPU cores.
Check out Concurrent’s presentation at GTC 2017. I think it’s pretty impressive.
[url]http://on-demand.gputechconf.com/gtc/2017/video/s7234-jackson-performance-optimization.mp4[/url]
[url]http://on-demand.gputechconf.com/gtc/2017/presentation/s7234-ken-jackson-performance-optimization-real-time-linux-tools-for-jetson.pdf[/url]
So if I first choose a RTOS and develop in Jetson, I can easily replicate in any PX board like the PX Xavier???
Concurrent RedHawk Linux RTOS is now available for both TX1 and TX2:
RedHawk real-time kernels and NightStar real-time tools can be installed onto an existing Jetson and they fully support the version of CUDA installed via Jetpack.
Does anyone have experience working with RedHawk linux RTOS on TX1 or TX2?
Concurrent Real-Time isn’t authorized to speak on behalf of our customers, but you can click our icon on the following page’s Software and Services tab and fill out the How To Buy form to request an evaluation copy for yourself:
Hi,
My application required hard real time Operating system (less then 10 microseconds response time for interrupt).
Refer to “installation of RedHawk 7.3-r28.1 on the Jetson TX2 Development Board release
note” section 4.1 - Denver cores impact system performance:
“When enabled, these cores can occasionally add hundreds of microseconds of latency to real time operations”
My questions are:
- According to my real time requirements (less then 10 microseconds response time for interrupt), Is
that mean I can’t use denver cores? - If I still want to use denver cores, Is there any way that they won’t influence on the response time
of the code that executed on A57? - beside disabling the denver cores, Is there any others limitation? GPU frequency? A57 cpu frequency?
Thanks,
Yair Havoynik
Hi Yair,
Regarding question #1, Concurrent has spent considerable time testing the Jetson TX2 and we’ve seen that using the Denver cores can always negatively impact determinism, even on fully real-time shielded non-Denver cores.
In addition, Jetson hardware design factors prevent the worst-case interrupt response time from getting down to 10 microseconds; the best RedHawk can guarantee on the TX2 is a worst-case of less than 50 microseconds in the presence of a CUDA-intensive load, and a worst-case of less than 40 microseconds in the presence of a non-CUDA stress-intensive load. Note that the average interrupt response time on a real-time shielded core is consistently ~8 microseconds regardless of load.
Regarding question #2, all of Concurrent’s testing on the Jetson TX2 has indicated that any use of the Denver cores can negatively impact the entire system’s real-time performance.
Regarding question #3, Concurrent has tuned RedHawk on the TX2 to ensure optimum real-time performance. At boot time RedHawk increases the CPU, GPU and EMC frequencies to be the maximum allowed and the Denver cores are also disabled.
Take care,
Jason Baietto
Hi Jason,
Thanks for the quick response, average interrupt response of 8 microseconds and 50 microseconds when GPU intensive load are acceptable in our system.
Few questions:
What about execution time of the same code that run on GPU periodically? Should I expect for jitter
more then 50 microseconds under RedHawk linux?
Did you test that on TX2 board?
For example, Each 10 milliseconds I execute code which should take 3 milliseconds on the GPU.
Under ubuntu (download from Nvidia site) we get max jitter of 1 millisecond!!!
Thanks,
Yair
Hi Yair,
The RedHawk kernel’s real-time features allow you to better isolate the system-level impact of GPU activity from real-time CPU activity, but RedHawk does not provide any real-time optimizations for the GPU activity itself. Thus, code executing on the GPU should perform identically under both the Ubuntu kernel and the RedHawk kernel.
Take care,
Jason
Hi Jason,
Thanks for the quick response.
Let me clarify myself, when I asked you whether I should expect a jitter more then 50 microseconds under RedHawk linux I meant jitter of the End of GPU processing Event.
Under Ubuntu, I don’t know if the jitter I get (1 millisecond) related to response time of the OS for external event or if it’s related to CUDA driver issues.
Under RedHawk linux, what is the max response time for GPU event?
Thanks,
Yair
Is it possible to develop C++ or Python programs using soft real-time librairies of the TX2 ? Is there any documentation of the real time API ?
Thanks
What “real-time API” are you talking about?
SCHED_RT is the main real-time primitive available in Linux. Those threads are at the mercy of long mutual exclusion sections in the Linux kernel, though. The behavior and use of sched_rt in Linux is well documented and only an Alta Vista/Bing/Duck Duck Go search away.
What I believe RedHawk does is add patches to the kernel to break up those mutual exclusion sections, and perhaps route around them in code, to make sched_rt threads perform as consistently as possible.
Links:
https://www.kernel.org/doc/Documentation/scheduler/sched-rt-group.txt