If you are manufacturing something in larger volume, they will sell you production modules without the dev boards that you can mount on your own boards. But those are still aimed at more expensive products. So this isn't a solution for low-cost high volume consumer products, but there is definitely a market for it.
https://www.nvidia.com/en-us/autonomous-machines/embedded-sy...
And if you just do CUDA experiments with it, those transfer at least partially to other environments (e.g. desktop/server hardware with GPUs) too.
Where do you get the idea this isn't transferable?
+ https://www.aaeon.com/en/c/aaeon-nvidia-ai-solutions
+ https://www.avermedia.com/professional/category/nvidia_jetso...
and you have certain numbers of custom design using the Nano compute module https://developer.nvidia.com/embedded/jetson-nano
But, the software misses the mark by a lot. It's still based on Ubuntu 18.04.
Want python later than 3.6? Not in the box. A lot of python modules need compiling, and the cpu is what you'd expect. Good for what it is, bad for compiling large numbers or packages.
They run a fancy modern desktop based on the Ubuntu one. Sure, it's Nvidia, gotta be flashy. But that eats a quarter of the memory in the device and make the SOC run crazy hot all the time.
These aren't insurmountable issues, they just left a bad taste in my mouth. In theory I only have to do setup changes once, but it's still a poor experience
The more I use linux (and I'v been for almost 15 years), the more strongly believe that using what the Linux distros provide as a development toolchain is an antipattern. Use separate toolchains with SDKs separate from your /usr instead.
> Good for what it is, bad for compiling large numbers or packages.
at worst you can
docker run -it aarch64/ubuntu
Your assertion makes no sense. Let me explain why.
You've adopted a LTS release which was made public 2 years ago, was already a couple of years in the making, and is aimed at establishing a solid and reliable base system that can be targetted by the whole world with confidence.
And knowing that, your idea is to bolt on custom tooling that's not installed anywhere or by no one by default and make it your own infrastructure?
Unless you're planning on managing that part of the infrastructure for your customers to use, your race to catch up with the latest and greatest makes zero sense, and creates more problems than those you believe you're solving.
And no, it's not an infrastructure problem. It's a software engineering problem that's yours in the making. If you seek stability and reliability then you target stable and reliable platforms, such as the stuff distributed by default by LTS releases such as Ubuntu 18.04. because that's what they are used for.
But this is an SBC. It's likely to be configured to run its specific task forever. It should automatically log into the default user's account, and automatically start whatever software you want it to run. Software for it is likely to come from cross-compilers and to be sent over SSH.
It doesn't have hundreds of gigabytes of high-speed storage, the entire OS needs to be copied from a microSD card on every boot, so you don't want to have multiple toolchains on it.
I really like the DietPi [1] environment for these purposes (though it doesn't currently support have the Jetson Nano), the setup scripts make it easy to configure the OS for exactly the tools you want.
[1]: https://dietpi.com/
LTS makes sense as deployment platform. Push it to server and deploy own application. Make a demo like subject NVIDIA Jetson Nano SDK and forget about it.
There are better ways to help underpowered machines - use light desktop environment, block ads in browser, add RAM if possible. Kernel and base requirements has not changed much in a decade. About 120 MB with XOrg.
It still only has Python 3.6, but OpenCV and numpy are pre-installed correctly this time so you don't have to compile them which is an improvement.
I'm not doing anything with mine that involves OpenCV, I didn't realise one of its flagship examples was also messed up in the box.
Oh! And I just dug out my script to rebuild if I need to. I forgot a few more annoyances:
* tensorflow isn't installed by default, and it's not obvious how to do the install because you have to specify NV's repo: pip3 install --pre --extra-index-url https://developer.download.nvidia.com/compute/redist/jp/v44 tensorflow
* openai gym won't work unless you specify archaic version 0.15.3, there's a buggy interaction between it and NVidia's X11.
* lots of packages need installing that should really have come by default, or were broken by default [eg numpy]
If you don't need CUDA, you can outright use regular Fedora, which uses nouveau. (no reclocking issues or such on Tegra)
I doubt that it largely has to do with the lack of optimisations of the graphical packages in the Linux for ARM architecture, as a x86 Chromebook with 4GB memory and slightly better CPU clock boost rate can offer far superior desktop experience.
1) ubuntu lts - stable releases - I'm a server person I want nothing to change, ever.
2) arch linux - rolling releases - I'm a desktop person, I want the latest of everything, now.
anything between these two extremes kind of sucks, both as a developer and as a user.
advantages:
1: "Q: I want to disable snapd on ubuntu 18.04, how do I do it?"
"A: <20 detailed posts of how to do it>"
1: "user: something isn't working"
"developer: clearly your fault, I haven't changed anything in that project in 4 months"
2: "Q: I want to disable snapd on arch linux, how do I do it?"
"A: why did you install it? look on the wiki."
2: "user: something isn't working"
"developer: everything is up-to-date, please do pacman -Syu and read the wiki"
I just set up a new 20.04 for ML and the official NVIDIA repos for this version were still missing a few cuXYZ libraries. I had to also add the 18.04 repos and symlink them together to get some Frankenstein library mess that works (as far as I can tell).
Sure you can make those things run natively but people using them are used to Python, lot of code is written in Python for it and there is little to no performance penalty of running the code in Python (everything perf. critical is running natively anyway, Python is only used to "glue" those bits seamlessly together).
And once you have RAM in gigabytes even the extra memory overhead of Python becomes a moot point.
But I must admit I don't see the 2GB model as a better value than the $100 4GB one, especially with shared CPU/GPU.
apt-get install python3.7
or
apt-get install python3.8
Instead they should release drivers that work with any Linux distribution (for example Debian, which is now broken because of USB issues).
(there's also the NV prebuilts of an older version of the patchset at https://docs.nvidia.com/jetson/l4t/index.html#page/Tegra%252... )
I wish luck to everyone buying these things. You'll need it to run any modern distro in a few years.
Only to realise that lack of software support makes them almost all pretty much completely useless.
I wouldn't use any randomly bought ARM device now for hobby projects, except the Raspberry Pi.
2.) Boot is only possible from microSD card. USB is not supported.
3.) Build BareBox with https://www.barebox.org/doc/latest/boards/rockchip.html
Use `rk-splitboot` to split FlashData from the original boot loader, other option doesn't work. Build it, it will create barebox-radxa-rock.img. It's .img, not the .bin.
Write an SD card as in the instruction.
4.) Follow these instructions, but use the generic image.
https://archlinuxarm.org/platforms/armv7/amlogic/odroid-c1
http://os.archlinuxarm.org/os/ArchLinuxARM-armv7-latest.tar....
5.) Build kernel as in this tutorial, ignore the `dts` stuff. The `dts` comes with the kernel sources.
https://wiki.radxa.com/Rock/Linux_Mainline
https://github.com/torvalds/linux/blob/master/arch/arm/boot/...
6.) Copy the zImage, rk3188-radxarock.dts to the /boot and plug in the UART.
7.) sudo picocom /dev/ttyUSB1 -b 115200 -e w
8.) Boot in the bootloader and execute the following commands:
global.bootm.appendroot=true
global.bootm.image=/mnt/mshc1.0/boot/zImage
global.bootm.oftree=/mnt/mshc1.0/boot/dtbs/rk3188-radxarock.dtb
bootm
9.) If it boots, you can make it permanent by following the BareBox docs.
Edit: Seems like people voted up the Hackaday article and not the medium article. So you've in effect negated everyone's votes.
How do I know which comments are talking about which article?
I can't find it on the product site, nor the BCM2711 datasheet (more like a programmers manual)
Someone could use this SBC -- not as an SBC, but as a discrete video card...
That is, have a computer without a video card -- communicate with this SBC via USB or Ethernet -- and have it perform all of the functions of a video card to generate the display output...
After all, it's got quite a high power GPU in it...
Yes, it would be a bit slower than a PCIe based high-end graphics card... this idea is for experimentation only.
One idea, once this is done, is to decouple the GUI part of any Operating System you write -- and have that part, and that part alone, run on the SBC / GPU.
Yes, X-Windows/X11 already exists and can do something like this.
But if say, you (as an OS designer) felt that X-Windows was too complex and bloated, and you wanted to implement something similar to Windows' GUI -- but a lighter version, and decoupled from the base Operating System -- then what I've outlined above might be one way to set things up while the coding is occurring...
Again, doing something like this would be for people that wanted to experiment, only...
ORG.APACHE.SLING.API.SLINGEXCEPTION: CANNOT GET DEFAULTSLINGSCRIPT: JAVA.LANG.ILLEGALSTATEEXCEPTION: RESPONSE HAS ALREADY BEEN COMMITTED
Edit: it's live now! [1][2]
[1] https://www.seeedstudio.com/NVIDIA-Jetson-Nano-2GB-Developer...
Double amusing, there is now an ARM core called the X1, a heavyweight follow up to the A76 for bigger form factors.
It would be interesting to see the tests repeated with Raspberry Pi 4B + Intel Neural Compute Stick 2, but I doubt whether there will be any drastic difference as this setup will still be bottlenecked by USB bandwidth when compared to Jetson Nano.
Even if the performance matches some how, the price/value is overwhelmingly favourable to Jetson Nano more so with the new cheaper 2GB version.
[1] https://developer.nvidia.com/embedded/jetson-nano-dl-inferen...
Is this enough power to do voice recognition? I'm sorry if this is a stupid question, I haven't done anything with ML before.
They dropped Display Port, the second CSI Camera Connector, the M2 slot, the USB slot and replaced the barrel jack with the USBC.
Thats a decent downgrade of capability
I lost faith in using raspberry pi 4s because the foundation is very tight-lipped. Want to know why your board is behaving weirdly, or whether the behavior is expected or a result of a defect? TOUGH LUCK. You'll have to rely on outdated forum posts, SO answers, and (if you're really lucky) the good mood of the engineer monitoring these sites.
I'd rather stick to building for a well-understood but expensive platform like x86 than undocumented black boxes.
Note that embedded radios / modems / codec manipulation is incredibly common. Usually its handled by a DSP (VLIW architecture), but I'd imagine that the GPU architecture has more FLOPs. DSPs probably have less latency, but something like SDR is not very latency sensitive (or more like: the community models latency as a phase-shift and is therefore resilient to many forms of latency)
Note: I'm not actually in any of these communities. I'm just curious and someone else told me about this very same question.
It's pretty neat stuff to think about DSP on hundreds of MHz of bandwidth being something that you can do in software these days. I remember when that was firmly in the realm of "don't bother unless you want to design a custom ASIC" and now it's starting to become even hobbyist-accessible.
Compared to him testing on a Raspberry Pi 4: https://www.youtube.com/watch?v=l4TyYU9Xhcs
(note both those videos are a old so results could be different now)
The video is a year old, but I imagine there would be less bugs now. With this cheaper board coming out, there might be a bit more of development activity.
This Jetson really isn't a platform to run emulated games - for that there are much better boards, with more RAM. Which is a lot more important issue. You can't do miracles with 2GB of RAM.
Jetson is made for computer vision, neural networks and signal processing, where the GPU isn't used as a GPU but as a massively parallel co-processor to crunch through a lot of data at once.
No, not even close. It's embedded systems with GPU acceleration, mostly for machine learning.
(strictly speaking any screen with higher resolution and/or expectations of smooth non-trivial graphics requires some kind of GPU, but I take the question to mean why one would want a powerful one)
As someone who has tried to run a desktop environment on various Pi-like devices for years, with every generation being "the one that will replace your PC" I just laugh.
The modern web is nearly unusable with less than 4 GB of RAM and it's really easy to push beyond that. I personally would not recommend that anyone try to use anything with less than 8 GB of RAM as a general purpose desktop computer anymore.
You can do it, sure, but there will be significant compromises and limitations along the way. A secondhand x86 PC with 8+ GB of RAM is almost always a better choice for general purpose desktop use. Leave the "hacker boards" for roles that benefit more from their compact size, low power consumption, and/or specialty I/O capabilities.
I haven't tried the Pi 8GB, that should at least solve the RAM problem, but the lack of native high-speed storage still likely impacts usability. Here's hoping the major Pi-likes follow suit to offer variants with more memory soon.
---
And of course as noted by other comments, another major reason to think of these things more as appliances is the generally spotty support for updating kernels and the like that is unfortunately standard in the ARM world. That entire side of the industry is infected with NDA culture and has no interest in curing it.
More specific; What is the use case of a battery enabled robot “brain” with machine learning?
But more seriously: robotics.
Only the MAIX platform has a price advantage over this now, and the software is much less mature.
There are many more Pi's out there so the development community and support is stronger than Nano. The Nano has support, just not in the same area. I have had problems with the Nano where memory gets chewed up in some way and I just reboot it after a while. The Nano does have the advantage of an Nvidia GPU, but it appears that is of no benefit to you.
Although the Nano does not have built-in wifi I don't think that is a substantial issue, but it does mean you need to get a wifi dongle. Of more concern is the need for a fan on the Nano. I have found that it gets hot fairly easily when pushed.
Bottom line is that in my opinion the small amount of memory is a substantial to avoid the Nano 2GB, the 4GB Pi is good and for about $30 more the 8GB Pi is a definite step up.
Of course, if you just want to buy a jetson and just looking for some reason to, that's totally fine too :-D
[0] https://devforum.zoom.us/t/have-you-considered-building-zoom...
The total package ends up significantly more expensive than the "list price" of an RPi itself, and it ends up not making much more sense than buying a used x230 or something off of eBay for <$200.
Support for CUDA 11 is coming soon, with the bump to Ubuntu 20.04 at the same time too. However, patching those issues isn't very problematic.
Debian/Ubuntu's "alternatives" system can select what /usr/bin/python3 runs. In practice, changing that away from the distribution default can break other people's code, and the win of an LTS is not spending time on that stuff.
But you can get yourself a Python 3.8, then you can build venvs, run a Jupyter kernel in it, whatever you like. If you can download or rebuild all the modules you want in a 3.8 venv, you're pretty set. And everything wanting Python 3.6 on your LTS still works.
If you're not doing that, use an RPi.
> connectivity: Gigabit Ethernet, 802.11ac wireless[1]
> [1] Not initially available in all regions
whatever the footnote means
those who cower in LTS land, thinking they are saving themselves from troubles have very very very little experience, scant little too contribute to the community that cares & tries to remain mildly up to date. there is such a prevalent fear based mentality about running decent reasonable modern upstream software but it is such FUD, such a cannot do attitude. rarely can these camps justify their afraid behavior. LTS is nonsense. testing, unstable, they work well, & they expose real honest levels of support for systems, versus relying on antiquated but known support that LTS brings the tepid adopters.
* Fresh
* Upstream
* Rolling
I understand people don't want to switch distribution, channels out of fear, inconvenience. Can cross-platform package manager help? The one with dependency resolution — Nix, not the one that bundles it all together like Flatpak or Snap.
The modern day has brought incredible advancements to the modern hobbyist. Just 10 years ago, you probably still needed to play with OpAmps and Inductors to effectively read a hundreds-of-MHz signal in any real capacity (at the hobbyist scale at least: $1000 or less projects). A PC probably had the compute girth back then to interpret the data, but you still needed a high-speed, and high-quality, ADC to even read the data that quickly.
If you price a silent PC with a fanless NVidia card it's quite a lot more.
I'm hoping someday we can get something like mister on the pano logic boards. You can find 2nd gen ones on ebay for $15 or so and have usb, dvi, audio, and I believe a more powerful fpga. All in a solid metal case.
Is this a developing markets play? I've never heard of someone whose only computer is a Pi/Jetson. By the time you add all the necessary peripherals to use it as your only computer, it costs more than a cheap laptop.
So the point of a Jetson is .. you only have a cheap laptop with terrible integrated graphics, and for $60 you get a much better GPU with this Jetson, and you remote into it?
I think it'll do better in gaming.
You can't just "install new version" of those packages unless Nvidia supports it, unless Tensorflow supports it, unless OpenCV works with it. If you have ever tried to build Tensorflow from source, you would know what I am talking about.
I shouldn't be quite so negative; NV did put in a lot of effort building up the development kit. ARM Builds of CUDA, drivers, etc. Repos with packages for the job. Tutorials for common tasks, etc. They're really within a hair's breadth of an excellent OOB experience, but fell at the last hurdle.
Tldr; with pyenv and pipenv installing a Python project is just "pipenv install".
`sudo apt -y install python3.7`
Then:
`mkvirtualenv --python $(which python3.7)`
It really is that easy.
It provides any version of Python, regardless of what your base system has (or lacks). It also provides an isolated gcc and many other packages; and you can still "pip install" inside it if the package you need is not conda-native, and conda will track it just as well.
Conda is really underappreciated.
That being said, programming the Maix is a piece of cake. The Jetson Nano was very challenging to deal with; the software is unstable in many cases, and the levels of abstraction are all mixed up, and discovering which Nvidia tools to use is an absolute pain (Gstreamer vs DeepStream vs ARGUS vs whatever else Nvidia pumps out this year). Also, I had way better support from the Maix community than from Nvidia. Nvidia's support model seems to be "unless you're spending tens of thousands of dollars, go pound sand, maybe a volunteer on our forums will help you, if anyone knows what's actually going on here."
Nvidia just has too much software, too little documentation, and holds onto their secret sauce so tightly that doing anything is a true pain.
OTOH, the MAIX has things like the pin assignments wrong[1] and you need a magic (undocumented) flag to make the LCD display colors correctly. There's also different types of models supported with undocumented constraints on each one, and you need to find the correct set of random open source projects to make them work. But it is an exciting platform!
From my experience, 0.05% of the people who have an Ubuntu x.y chose it because of "stability promises" of the LTS release. They just want a quick linux install to run their shit on, or it was handed that way by the Uni department / company / whatever. Or just because it's the biggest name and you're sure to find help online. And then a lot of people don't upgrade - I work with my fair share of people running win 7 (even still have an XP person around), OS X < 10.10 and Ubuntu 14.04, just because they can't afford newer hardware required to make the experience of newer OSes not a laggy shitfest.
> And knowing that, your idea is to bolt on custom tooling that's not installed anywhere or by no one by default and make it your own infrastructure?
gcc is not part of infrastructure, just like Xcode.app or Visual Studio aren't part of Windows or macOS infrastructure.
Your experience and my experience differ greatly, then. I manage around a hundred virtual and bare-metal Ubuntu 18.04 LTS systems. Most of our docker containers (not included in the number above) are based on an Ubuntu 18.04 image because that's what we have standardized our infrastructure around.
The LTS choice was an easy one to make. We are too busy focusing on delivering value to the business to spend much time constantly playing around with the underlying technology. We are not early adopters for much of anything (except hobby projects at home) because we need our technology to be an asset to the business rather than a liability. Depending on new and bleeding-edge software for production systems just creates unnecessary risk.
We'll probably start thinking about upgrading to 20.04 in six months or so.
I'm really glad there are still companies with such values. For some strange reason, these days people equate innovation with using fancy/barely tested tools.
there are a lot more linux users out there than business users
You might be right, that %.05 of people choosing to use LTS distros are doing so for its service promises. But I'd counter that the majority of those who care are managing hundreds or thousands of machines / users. The end users might not know that they care, and that's because the admins are doing a good job.
Which kernel modules wouldn't come as precompiled packages in Ubuntu ? (real question - as an Arch user for instance I haven't had the need for DKMS for years)
Excellent, I have a solid base.
Now I want to install the latest version of Gimp. Cannot. Why is that tied to the base versioning?
Pipenv is honestly a nightmare.
Why do you say Pipenv is a nightmare? Have you had bad experiences with it?
I find it gets unstable with cheaper USB C chargers.
I specifically buy high quality chargers/cables/battery packs for my embedded work since they are so intolerant of bad power
[0] https://wiki.archlinux.org/index.php/DisplayLink#USB_3.0_DL-...
maybe, but there are a LOT more linux servers out there than linux users, if by "linux users" you meant "people running linux on their computers".
those servers (and the people that run them) generally require stability.
would you care explaining what you mean? is it not fair to say that there are many orders of magnitude more instances of linux running on servers than there are instances of linux running on people's home or work computers? that is indisputable, no?