For a moddable Arm platform with all batteries included, there isn't really an alternative to this, especially at $699.
It's much stronger than an RPi and could fill the gap between RPi and Arm-based server platforms.
Jetson AGX Xavier
31–40 of 95 posts
Re: Jetson AGX Xavier
#32Earlier quoted context omitted.
Well, first some clarification - "edge" means "on robot" versus something in the cloud. And the reason you do this is latency and connectivity. I am designing a four wheel drive robot using the NVIDIA AGX Xavier [1] that will follow trails on its own or follow the operator on trails. You don't want your robot to lose cellular coverage and become useless. Even if you had coverage, there would be significant data usage…
Edge means on-premise (on robot) as you said. But 'edge,' as used in context of AI, is also a wink-and-a-nod that the device is inference-only (no learning, no training). The term "inference only" doesn't sound very marketing-friendly.
AGX Xavier can do training on device just fine - and run every CUDA workload. It's just not the fastest device at that, you'd prefer a desktop GPU if you can for such a purpose.
Re: Jetson AGX Xavier
#33Earlier quoted context omitted.
Does it have "fake" tensor cores? Aren't those for training?
You still need tensor cores for inference. But they don't do weight updates. Learning/training is all about updating the weights (through backpropagation or whatever). So another way to put it: its tensor cores do feed-forward calculations, but no backpropagation, and no weight updates.
The hardware and platform is capable of training just fine. It's just rarely done because it is slower than training on pretty much any discrete GPU.
Re: Jetson AGX Xavier
#34Honest question, can something like this kill the market for embedded DSP processors made by Texas Instruments or Analog Devices?
No, those face more threat from ARM M4/7 cores or RISC-V units with vector/SIMD coprocessors. DSP cores are being lifted out of discrete chips and placed as IP blocks into more integrated solutions, with the really complex algo stuff placed in general purpose hardware like FPGAs.
The economics don't really make sense for TI/ADI DSPs imo. If you had an application where you needed a chip just to do DSP you'd probably use an ARM core instead - but the applications engineers at TI/ADI will gladly help you find a product in their catalog that has more features integrated into it (like ADC/DAC, even analog front ends for audio/RF, USB/Bluetooth stacks) for your product.
Basically there's no market to kill, from what I've seen.
Re: Jetson AGX Xavier
#35Honest question, can something like this kill the market for embedded DSP processors made by Texas Instruments or Analog Devices?
I mean, this is absurdly more powerful than those dedicated DSPs.
It's also easily 10x the price. It really matters what the application is and how much processing power you need.
Re: Jetson AGX Xavier
#36Earlier quoted context omitted.
Well, first some clarification - "edge" means "on robot" versus something in the cloud. And the reason you do this is latency and connectivity. I am designing a four wheel drive robot using the NVIDIA AGX Xavier [1] that will follow trails on its own or follow the operator on trails. You don't want your robot to lose cellular coverage and become useless. Even if you had coverage, there would be significant data usage…
This is a bit off topic, but I'm constantly looking at ways to efficiently stream 4K cameras live to local displays as well as remote displays at the highest framerate and resolution possible. How feasible would it be on the xavier to stream 2 4k cameras and display them on at least 2 4k screens? Extra points if you could do that and simultaneously upload to a streaming service, such as twitch.
I've wondered about this too.
I think the magic camera interconnect is CSI/CSI2 and it's not really flexible enough. You either have really short copper interconnects, or unavailable fiber interconnects.
What would be cool is if csi to ethernet were a thing. either low latency put-it-on-the-wire or compressed. I don't know, maybe it is. But make it a standard like rca jacks.
Re: Jetson AGX Xavier
#37Inference only. (So this is competing with Google TPUv1; a few years late and way more expensive, but with more memory)
1. This isn't inference only, it has the full capabilities of a normal GPU, just small and low power (and therefore much slower than normal GPUs).
2. TPUv1 is a matrix multiply ASIC that requires a host CPU to do anything. This thing is a SoC that includes both a CPU and a GPU. The CPU is pretty fast for what it is - much faster than e.g. raspberry pi, see https://www.phoronix.com/scan.php?page=article&item=nvidia-j....
3. not sure how you know whether this is more expensive than a TPUv1, since the TPUv1 was never sold or available outside of google.
A much better comparison would be between this and the Edge TPU development board.
Re: Jetson AGX Xavier
#38My biggest complaint with the Jetson line is it's all ARM. Look, I get it. But the developer experience is horrible. Building Docker containers for ARM devices is a pain. Hell, building anything for a Jetson can be a pain unless it's a pre-packaged NVIDIA thing - really not a fan of building things from source. Add on top of that NVIDIA's very low level documentation for pretty much any tooling they ship, coupled with the difficulty in getting near-time engineering support (unless you want to post to one of their message boards, and hope you get an answer back in less than a week)... basically, it's really rough to do anything seriously useful with Jetson hardware.
Second biggest complaint is deploying Jetsons in production environments. Dev kits aren't production stable, so you either need to build your own carrier board or find one pre-built, and frankly that's just a giant pain to do.
Third biggest complaint is having to flash Jetsons manually. Misery.
A production-ready x64 Jetson that you could order directly from NVIDIA would be my dream. Add up all of the shortcomings and overhead of ARM Jetsons and IMO you do not have a viable device for shipping AI solutions at scale.
Re: Jetson AGX Xavier
#39Earlier quoted context omitted.
Well, first some clarification - "edge" means "on robot" versus something in the cloud. And the reason you do this is latency and connectivity. I am designing a four wheel drive robot using the NVIDIA AGX Xavier [1] that will follow trails on its own or follow the operator on trails. You don't want your robot to lose cellular coverage and become useless. Even if you had coverage, there would be significant data usage…
This is a bit off topic, but I'm constantly looking at ways to efficiently stream 4K cameras live to local displays as well as remote displays at the highest framerate and resolution possible. How feasible would it be on the xavier to stream 2 4k cameras and display them on at least 2 4k screens? Extra points if you could do that and simultaneously upload to a streaming service, such as twitch.
You can certainly do this using machine vision cameras. Either USB3, Gig Ethernet, or CSI interface (16cm max run length I believe). I forget how best to attach two displays to the Xavier but that’s seems doable.
I got my cameras from e-consystems and they’ve got some USB3 cameras that could do it. At least I’m pretty sure. My USB3 cameras just showed up and I haven’t tried them yet.
Re: Jetson AGX Xavier
#40My biggest complaint with the Jetson line is it's all ARM. Look, I get it. But the developer experience is horrible. Building Docker containers for ARM devices is a pain. Hell, building anything for a Jetson can be a pain unless it's a pre-packaged NVIDIA thing - really not a fan of building things from source. Add on top of that NVIDIA's very low level documentation for pretty much any tooling they ship, coupled wit…
> Building Docker containers for ARM devices is a pain in the ass.
It's not so bad, you just need a beefy ARM machine to build the containers in CI. It would be silly to build a Docker container on the Jetson itself. You would never use an embedded device for compiles and builds, why would you build Docker containers on one?