The BeagleBone AI is Available
beagleboard.org
beagleboard.org
Perhaps the Vision Engine is better for computer vision tasks, but having to use TIDL suite when compared to Jetson Nano's JetPack with tools which we use regularly on bigger GPUs is going be a hard compromise to make.
Jetpack includes CUDA 10, TensorRT, OpenCV 3.3.1 etc. by default and PyTorch is available separately for Jetson Nano. Besides the community is very active.
https://www.nvidia.com/en-us/autonomous-machines/embedded-sy...
Please note that there is also Nano Module, which is a SOM (System on Module) with 16GB EMMC storage sold for $150. I think this is intended for clusters.
The production Nano module (which you can also now buy) won't work in the dev kit carrier! Similarly, the dev kit Nano module won't work in a carrier compatible with the production Nano module.
Apparently they'll refresh the development kit to match the production Nano module later in the year, but for now it's a big gotcha if you're designing hardware using the dev kit.
Also when you use other companies' trademarks, you should have a notice of who the trademark owner is, which this press release does for Sitara but not for the other trademarks used in the piece.
Do you have a cite for this? Thanks.
http://www.bpmlegal.com/tmdodont.html
Search the page for "disclaimer", or just read the whole article - it has a lot of good trademark advice. It also somewhat disagrees with what I said about only using the trademark symbol once - it says to use it the first time and "occasionally thereafter".
So here is an interview with an IP attorney who suggests just using it once:
https://www.forbes.com/sites/work-in-progress/2014/03/12/whe...
(Disclaimer: I'm not a trademark expert! Just passing along what I've read from those who claim to be...)
This is confusing because that isn't how the USPTO seems to use the term "disclaimer" as regards trademarks:
https://www.uspto.gov/trademark/laws-regulations/how-satisfy...
> What Is a Disclaimer?
> A disclaimer is a statement that you include in your application to indicate that you do not claim exclusive rights to an unregistrable portion of your mark. For example, if you sell shirts and your mark includes the generic word "SHIRTS," you could not object to someone else also using the word “SHIRTS” as part of his/her mark. The word is still part of both marks, but no one is claiming exclusive rights in that word, because it is an 'unregistrable' component of an overall mark. (See below for typical examples of unregistrable matter that must be disclaimed.)
> A disclaimer does not physically remove the unregistrable portion from your mark or affect the appearance of your mark or the way you use it. It is merely a statement that the disclaimed words or designs need to be freely available for other businesses to use in marketing comparable goods or services.
Teflon is a registered trademark of DuPont.
They're just saying you should add a statement like that, not saying this is a "disclaimer" in the specific meaning USPTO uses above.
With absolutely no evidence that it's required.
No, you shouldn't. There's no evidence it's required.
I'm not expecting anything crazy like 8gb or anything like that, but given how many boards sell at ~50$ with 4GB of ram this just seems kinda limited.
If these are meant to be nodes in a larger system I guess that makes a little more sense, but if they're meant to be more autonomous that 1GB is going to be a real limitation for certain applications.
The BeagleBone AI is aimed at prototyping in industrial automation applications. I've never worked in that area, but I wouldn't be at all surprised to see that large amounts of RAM isn't a priority for industrial controllers. Probably the software tends to be frugal with memory, because a bigger heap means more cache misses, and more cache misses mean worse latency.
A Raspberry Pi, by contrast, is mostly targeted at running a GUI and memory-hungry user applications up to and including Minecraft. It's meant for teaching kids to program and hobby stuff. It doesn't have built-in DSPs and programmable real-time units, because those are for supporting applications that fall far outside its intended purpose of having fun with Python.
The size of that model will be determined by the number of weights used. Being that industrial automation will likely use CV, that will mean the potential for a lot of weights.
Same goes for any other non trivial use case.
So yeah, 1GB is paltry.
And if you can get away with running an SVM on a 1-megapixel black and white image, then your weights will fit in 1GB with an order of magnitude to spare.
There's no reason to use an SVM over a (C)NN nowadays though.
I'd absolutely focus on ANNs if I were an academic researcher, because that's the hot flavor of the month that's going to get your career the attention it needs to bring in funding, jobs, etc. I'd also pick it for Kaggle-type stuff, where there's effectively no real penalty for generalizing poorly. Bonus points if you consume more energy to train your model than Calgary does to stay warm in the winter.
In a business setting, though, I would only default to ANNs if it were holistically the best option for the problem domain. By "holistically" I mean, "there's more to it than chasing F1 scores at all costs." The business considerations that caused Netflix to never try productionizing the prize-winning recommendation engine, for example, are always worth thinking about. Personally, I'm disinclined to look past linear models - not even as far as kernel methods - without strong reason to believe that I'm dealing with a curve that can't be straightened with a simple feature transformation. Complexity is expensive, and needless complexity is a form of technical debt.
Huh? SVMs don't perform better than NNs on less training data.
I'm sorry, but the rest of what you said is out of date and wrong. CNNs work better than SVMs for CV tasks. There's no reason to use SVMs anymore for CV, and no one in their right mind does.
I expect $100 board to have 2 or 4 GB.
Yet once upon a time I thought a 48 K Apple II was a lot.
AM57xx SoC have 2 different DDR3 memory controllers called the EMIFs. Each one has a 32 bit data width and can support up to 2GB of memory attached. A single x16 (16 bit wide data path) DDR3 chip in 512MB (4Gb) size is reasonably cheap to buy today but doubling that size to 1GB (8Gb) makes the price go up like 4x since there's just not much volume in that size sold. In order to fit onto the BeagleBone board size, only 2 DDR3 chips could fit, so only 1 EMIF is used, and to keep costs reasonable they used 512MB (4Gb) sized chips leading to 1GB of total DDR3.
Related, the C66 DSPs and M4 cores inside of AM57xx are only able to access the EMIF interfaces over the L3_MAIN core interconnect within the SoC. L3_MAIN is a 32 bit address bus interconnect, so at most can address only 4GB of memory address space. TI's memory maps for the DSPs and M4 cores both start the EMIF addressing at 0x8000_0000 so at most the DSPs and M4 cores can only access up to 2GB of DDR3. Addresses below 0x8000_0000 are mostly memory mapped peripherals, like the GPIOs and PCIe interfaces and such. The Cortex-A15 cores are able to use an extended addressing mode and can access the EMIFs through a different interface, they don't have to use L3_MAIN (but can, but there's errata), so if you connect more than 2GB of DDR3 to AM57xx then the big Cortex-A15s can access it but no one else can, which makes it less useful/valuable for a lot of designs.
If you want a dev board with more DDR3 and AM57xx, the BeagleBoard-x15 is an option although it appears to be hard to buy just the x15 from most distributors right now as they're out of stock. TI still sells the AM572x dev kit with the LCD screen directly (https://www.ti.com/store/ti/en/p/product/?p=TMDSEVM572X), albeit for a bit more than just the x15 used to cost and quite a lot more than the new AI costs.
That is never going to be a fair comparison.
I used BB in previous projects, one thing definitely stands out for BB is that, it could be used as a product directly with a case and some certification(EMC,etc). Nvidia's Nano is more of a development platform.
Beagleboard predates RPi actually, though after Arduino, BB is arguably the very first board running a 32-bit ARM that is also open source, cheap, small, however it's overshadowed by RPi in recently years.
It's impressive but, being pretty much domain specific chip, can anyone make use of its capabilities at hobbyist levels where Beaglebone is targeting?
> Focused on everyday automation in industrial, commercial and home applications.
So looks like they're trying to expand utility beyond hobbyist market.
RPi is very aimed at taking some sort of existing project and modifying it, which sounds mean to say but actually lets you do some very powerful things. The average RPi user will never be compiling device tree overlays, screwing around with the bootloader, busting out the datasheet for the processor, etc. You find some project that is kind of like the one you want to do, use their hardware and low-level settings (involving device tree overlays, but so abstracted that you will never encounter that term), and then go to town on the software, probably written in something like Python.
The Beaglebone is more like a dev board for TI's SoC. You will configure every pin exactly as you want it with a device tree overlay. You will be reading the datasheet to figure out exactly how many CPU cycles a certain instruction takes on the PRU. The amount of power you have over IO and hooking them into Linux is infinite. As an example, you can control the clock signal for the entire board through an IO pin. If you are doing realtime processing and want to make something happen in the Beaglebone PRU at the exact same time as some external hardware, you have the power to make that happen. Most people do not need this.
The TLDR is that I would use the RPi for pretty much any "maker" project because it's so easy to get things working, but would use this new Beaglebone for something like a CNC machine. If you're making a CNC machine, you need a microcontroller to stop the motor instantly when it drives into the endstop (even if Linux is currently processing your mouse movement or a network packet), you need a realtime microcontroller to properly move the axes in unison (so you can cut a circle at your exact feedrate), and you need Linux to drive a monitor with the controls on it. This new board puts all the processing power you need on the same board, and has all the kernel hooks you need to communicate between your non-realtime Linux software and the microcontrollers. (It's been a couple years since I've used the PRUs, but they show up as a "remote CPU" under Linux and have APIs for bidirectional message passing, which is potentially more powerful than a serial port interface to an Arduino that does the realtime stuff.)
You can of course just plug an Arduino into a USB port to get the same effect... this is how pretty much every 3D printer ever works. I literally have this exact setup on my 3D printer; an RPi that controls my 3D printer over USB -- the RPi hosts a web interface, the microcontroller handles the realtime motor moves. If you are manufacturing something like this, having everything on one board will probably lower your costs. That is why the Beaglebone exists.
(What this has to do with AI? I don't know. Maybe it's for pick-and-place machines that need realtime motor moves and some computer vision.)
There's nothing particularly difficult about wiring a microcontroller up to a single board computer to do these jobs, I've done exactly that for reading my weather station and heating oil tank level. But it's messy and I think the cohesion of being able to do it directly on one board is a worthwhile advantage.
This press release is a disaster as far as grammar is concerned. I am legitimately unable to tell if it has any special properties regarding AI.
And NO, it came out yesterday, it's not driving any revolutions.
And what about TIDL adoption? I've been working on the Intel/NVIDIA-grade part of the ML scale and have a few ESP32 boards to fiddle with OV2640 cameras, but very little in between except what Broadcom has been doing.
As for tooling, could not say, but as a previous comment stated - the NVIDIA offering for the same money, makes this hard to stick out for many. Though i'm sure it, as most boards do, have a niche - what that niche is beyond already invested in the beagleboard environment and comfort level, that would be the only uptick for some that i'm seeing from initial glance.
In my experience, software from hardware companies has been so reliably abysmal that it makes the "enterprise software" us SWEs like to complain about look decent by comparison.
Hopefully it's different this time :)
Or do we have to write custom C/C++ code to make best use of available hardware?
And if they'd document their ISA, it's pretty amenable to being used for neural networks, wayore than the other mobile GPUs at least. It'd be a cold day in hell before they did that though unfortunately.
But their driver/software complexity is super high to even get a triangle in a buffer or run a compute job. They have a RTOS looking microkernel running on the shader cores, and there's a ton of caching and MMU setup you have to do from the GPU side (not the main app processor). And there's a lot of caching hints and hacks that are hard to work around if you don't know the context (a lot of tables for bug reference numbers and special cased code depending on those)
If anyone from Imagination is listening, the open source community would still love your help in supporting these chips. : ) They're really pretty inside, and the world should know about the good work y'all did!
Where can I find info about how these edge computing boards are speeding up training time? Or how they compare to a 1080i?