The interesting part of this one, to me, is the Octavo packaging of the AM335X processor with on-die RAM. That makes the board much simpler. Though, I thought it would make a bigger difference in price. The BeagleBone wireless that uses the same chip is ~$68, which is $7 higher than the Black that has separate RAM.
If you haven't used a BB product, check out the thing that I think is the biggest upside of these...the built in pair of PRUs. It's like having the best of a normal linux board plus a microcontroller on the same board. Since the PRU shares memory with the main CPU, you can offload things that need to be realtime. That allows for things like a near professional-level LED matrix controller (https://trmm.net/LEDscape) or even a DIY video controller (https://trmm.net/Mac-SE_video).
Thanks! This looks a really good starting point for a project I am working on. Using PRU for I2S is genius :) Can you please point me to the detailed specifications somewhere on http://bela.io?
"Bela uses both the McASP and the PRU. The McASP actually streams the data to the codec, but the PRU handles passing data to and from it, as a sort of sophisticated DMA controller. We use the PRU here because it can also do SPI transactions with the other ADC and DAC and it can sample the GPIOs, all aligned on a sample-by-sample basis with the audio clock. The PRU then puts the results in a memory buffer for the CPU to work with.
To take any advantage of that, you need a Xenomai kernel, because this lets you write audio code that can interrupt the entire rest of the OS. If you don't have this, then you're stuck with the timing uncertainty that regular Linux provides, meaning you need larger buffer sizes (= longer latency). It also means that audio performance may depend on system load, which is not true of Xenomai (rather the reverse: rest-of-system performance depends on audio load)."
> If you haven't used a BB product, check out the thing that I think is the biggest upside of these...the built in pair of PRUs.
Allwinner SoCs have an OpenRISC microcontroller used for managing deep sleep modes. [0]
I don't think anyone has figured out how to use it for other tasks yet, but it would be really great if there were more SoCs that included these kind of companion cores.
Oh, wow...companion core in a cheap board would be popular if someone figures out how to leverage it. The OrangePI Allwinner boards are amazingly inexpensive...$10 shipped, including WiFi (https://www.aliexpress.com/store/product/New-Orange-Pi-Zero-...)
The iMX7 is a low power single or dual A7 core with an extra Cortex-M4 core on the die for real-time applications. Looks like they also took out some of the multimedia blocks to try and get the price down compared to the iMX6.
NXP also nuked a lot of their free support from orbit when they bought Freescale. Doing stuff like deleting a bunch of the SD card images for their sabre boards. We were told by NXP that some Indian support firm still had them for like... a $20k support contract.
They really pissed us off with that crap, and our shop at least probably won't be buying NXP parts for a while.
> If you haven't used a BB product, check out the thing that I think is the biggest upside of these...the built in pair of PRUs.
This is something I plan to do once I get one of these beasts, although they're probably beyond my level of comprehension. Anyway, if they can be used to synthesize signals at very high speed, what about using them to build a DVB-T transmitter?
When TV went digital we lost the ability to send a signal to a TV using an extremely cheap modulator, and last time I checked the only units around are priced several hundred quids, so if doable an application like that one could be truly interesting.
> Anyway, if they can be used to synthesize signals at very high speed, what about using them to build a DVB-T transmitter?
Not possible, unfortunately.
IIRC The PRUs run at 200MHz. I'm not an expert at signal magic, but unless somebody has a really smart trick up their sleeve, it means you can synthesize at most a 100MHz signal (assuming changing the state of an output takes only one cycle, which I believe it does).
Ah sorry, I didn't mean producing the radio frequency signal but the modulating one which would be paired with a carrier generated by a separate module. Admittedly I know next to nothing about digital modes so I have no idea if the PRU could stand the necessary bandwidth to do such a thing.
> If you haven't used a BB product, check out the thing that I think is the biggest upside of these...the built in pair of PRUs.
I've been looking at boards for days now trying to find the perfect one to suit my needs and this is exactly what I've been looking for. I've seen the beagleboard before but I never noticed this feature before. I'm glad I saw this post this morning!
Yeah, definitely. I assumed they'd been talking about some feature on the new board, although looking back in the thread, I can see how that might've been an unsound assumption.
I've actually got a Beaglebone Black sitting on the desk next to me. I haven't gotten around to playing with the PRUs, but I know of their existence and general capabilities.
Oh my. This looks perfect to replace the plethora of daughter boards I usually have in my robotics projects: encoders, power boards for DC and servo motors, I/O boards. This also looks clearly oriented towards drones, and seems to have a lot of potential in that regard.
To be fair, I was also recently considering switching to other, more integrated boards recently; but this one seems particularly well tailored to my use case, at a decent price, and (perhaps more important in some regard) open source.
I didn't read the full specification, the only thing I am worried about is the maximum power draw (especially for DC motors). I also usually use 24V PSU/batteries, but that's only a minimal inconvenience.
The title is a bit misleading, this Beaglebone iteration is oriented towards robotics mainly. It can do autopilot but not without external hardware (e.g GPS). It does have hardware useful in robotics though that common autopilot boards miss.
It is very interesting and the price point is good (about €80). A thing that troubles me is that, with a very quick look, I couldn't find a nice programming guide.
Recently I switched to Raspberry Pi 3 with a Navio2 HAT for an autopilot project. Whilst the Navio2 hardware may be expensive and closed, their software and documentation are top notch. They provide their own rasp pi distro, with code examples for accessing all sensors and even expose some of the hardware in sys-fs.
Literally the first repository in that list is their kernel: a 3.14.26 tree. The 3.14 tree was tagged fully THREE YEARS ago. 3.14 is not a LTS release, and its last patch version (.26) was released in December of 2014. It's likely missing a bunch of important fixes that went into the 3.16 LTS tree since. I don't see anywhere on that site where they're maintaining a more recent "development" or "upstreaming" kernel either. They just have this one tree.
So given that, tell me what you think the likelihood is of these Sitara changes ever reaching the mainline kernel tree? Zero? I'll put my money on zero.
"Much better" than Rockchip or Allwinner maybe. Not "good".
If you look into it they (beagle probably? Rather than TI) actually employed a guy (rcn-ee) who spent a lot of time getting various beaglebone code including the support for capes (basically dynamic hardware loading - something previously relatively not done in ARM - there are no busses like PCIE) - that took some 3 years because of the mess of support in Linux and getting it done in a "Linux"/upstream happy way.
So it might be better than you think but in general this is still a problem in the entire space. But as best I can tell the beagle guys are way ahead of most on this.
google rcn-ee for more info and forgive any inaccuracies in my recollection above.
it's supported by mainline kernel. it's probably the best supported cheap open hardware of its sort out there. every datasheet for each chip on the beaglebone black is freely available and it can run with no proprietary blobs, unlike the raspberry pi.
it's even supported by the *bsds.
Really? Genuine question. Is there a link where I can find someone's .config for a current mainline kernel I can boot? I swear I'll buy one of these right now if so.
Note that "no blobs" can't be completely right. I'm like 99% confident these use PVR SGX graphics, for which there are no open drivers.
Ah, a board with R/C PWM servo ports. That's a 1970s interface which should have been replaced by now. There are servos with a bidirectional serial interface, so you can ask what the actuator is doing, but they're overpriced.[1] They're about 5x-10x as expensive as standard R/C servos.
There was an open source project, OpenServo, to do something about this, but it was done by 2008 and seems to be dormant. [2] There's no multi-manufacturer standard for servos above the dumb level.
Annoying things in low-end robotics: 1) motor controllers with significant power handling cost too much, although this is improving, 2) encoders cost too much, although they're simple and every mouse wheel has one, and 3) encoders are usually fragile plastic add-ons to motors with strong metal cases, instead of being integrated inside the motor case.
The core problem with the dynamixels is cost. I'm hesitant to use them in any situation they could get trashed because they are so expensive. Add on that they are harder to control and it's a recipe for a niche product.
Having used them I loved them, but they aren't a tool I reach for at first. But now that you've brought them up I kind of want to use them for something.
But why this board has RC PWM Servo ports? Because it's a cheap easy way of interfacing with things. More importantly, it let's you hook Brushed/Brushless ESCs up fairly easily to get things moving with motors that draw more than 1 amp.
1) DC Brushed - Spark ESC https://www.amazon.com/SPARK-Motor-Controller-REV-Robotics/d... (Disclaimer - I know the owner of Rev, he's a friend)
2) This is really a function of scale more than anything. But yes, they are expensive.
3) With the advent of 3d printing it's at least manageable to put something around them
But I agree with you that most of these are incredibly annoying.
Speaking of big motors and big torques its interesting to consider CNC machine tool conversion technology ... Admittedly continuous use, industrial level indestructibility and temperature levels means expense, but if you want 400+ oz=in of torque for a wheel perhaps, you could do worse than CNC controller hardware perhaps driven by something other than CNC software. At some point you have a 5 volt TTL interface thats as simple as direction and step. You'll be spending maybe $200 per axle but you look at the price of 400+ oz-in servos or gear motors plus drive circuitry and suddenly its not that bad. 1000+ oz-in is not out of line for the larger machine tool conversions. Standard NEMA motor mounts etc. You take 200 steps/rev stepper and add 10-step microstepping driver like a geckodrive and theres 2000 steps/rev at 400+ oz/in with a simple TTL interface for maybe $200 (plus power, and steppers are hungry beasts)
Something like a geckodrive G251 single axis stepper driver for $89 good to 3.5 amps combined with a NEMA 23 stepper one of the lower current 1.8 amp "long" types $48 on amazon for 340 oz/in torque. That's about $140. That's 68% of budget for 85% of specified torque.
Its easy to find a NEMA 34 with over 600 Oz/in for $60 on amazon but it'll probably draw 6 amps at 600 oz/in and you'll need a more expensive controller. Something like a geckodrive G201X is rated to 7 amps at $127 which just barely makes spec.
The worlds cheapest stepper paired with the worlds fanciest most indestructible controller is probably unrealistic.
The dynamixels are fairly priced when compared to equivalent servos. Compared to the weakest slowest servos with lots of dead band slop the dynamixels are quite expensive. However those servos are quite useless of course, and compared to servos of similar built quality the added cost of a dynamixel is minimal.
Look at something like an AX12W dynamixel which costs $25 more than an equivalent Futuba S3003, roughly same torque and speed. Given the control capabilities of the AX12 I don't see the point of buying the Futuba product.
Or a Futaba S9452 is about $90 for 130 oz-in of torque or Dynamixel AX-18A for $95 for 255 oz-in torque. Eh an extra $5 for twice the torque, not that ridiculous.
There obvious scaling problems where putting a vary fancy controller on piece of junk mechanicals doesn't make economic sense so you'll probably never see something with the control features of a dynamixel on sale for $5 each.
Dynamixel servos are expensive for sure, but there are a couple of low-end models which are pretty reasonably priced given their (excellent, as you note) capabilities. The XL-320[1] is only $22. They're puny, but I've had fun with them.
> motor controllers with significant power handling cost too much, although this is improving
There are more than a few h-bridge ICs out there that can easily control many amps of current; Infineon's BTN89xxx line is fairly popular, but there are others. Many can be found as "breakout boards" on Ebay and other places. They'll usually control 12-24vdc @ 40A and more; they are MOSFET devices (n-channel, integrated high-side pumps, etc). These boards are fairly cheap.
Now, an h-bridge of course doesn't make a motor controller, but it is the most difficult piece of the puzzle, and perhaps the most expensive part (in terms of electronics hardware and developing one - because frying MOSFETs or IGBTs in the process of development can add up quickly). The rest is monitoring and code (basically using a microcontroller to interpret control signals and feedback signals from current, encoders, etc - implement PID as needed for speed or other control, overcurrent monitoring, etc).
Of course, none of this will match the capabilities of a Roboteq or Vantec motor controller - but you won't be spending several hundred dollars, either. These lower end devices and designs (and there are other companies that make lower-end controllers, like Dimension Engineering and others) are more than enough though to control electric wheelchair motors (but if you want proven "bulletproof" controllers, spend the money).
And if you are really cheap or want to experiment? Pick up some cheap logic-level high-amperage N-channel mosfets off ebay (or other places), parallel them together for more current handling (of course, there may be issues with capacitance load), then build a simple "h-bridge" from 40A Bosch relays scavenged from a pick-ur-part (most of those places give 'em away), and put the mosfet pack on the low-side connected to ground. A couple more mosfets to control the relay switching, and you have a (somewhat) cheap (though large) 40A PWM-capable hybrid h-bridge (just don't switch the relays while PWM'ing!).
I guess all of this is to say that there are plenty of inexpensive options out there that aren't "old-school" L293 or L298 solutions (though honestly, for their application, such h-bridge controllers still work well, provided you pair them properly - that is, larger motors running at 12 volts or a tad more off of gel-cell or similar batteries, when efficiency isn't as great a deal).
Arrow is running a special—the BeagleBone Blue for ~$77 with free shipping and a free raspberry pi 3. Just in case you were on the fence about picking on up...
Argh, they won't accept my password with special characters, number, uppercase letter and lower case letter, with error that "password must contain at least one number, upper case letter and lower case letter". How stupid is that.
But good for me because I paused shopping to vent here and I realized I may actually not need it that badly having enough MCUs at home already.
I can't edit anymore but just wanted to add that the free shipping is international (I'm in EU, positively surprised), and while they do have some bug in displaying placed orders list, they also have an excellent live support. So maybe I can forgive them the sh*tty password regexp.
How's the BeagleBone quality these days? I bailed a couple of years ago in the Black era after fighting with the buggy serial hardware which required a full power-cycle to recover from faults, and getting tired of the process needed to upgrade the boot flash without bricking the system.
I have fried one or two, but it was my own fault each time. (Do not connect the +5v from the barrel connector to the GPIO pins!)
I use a BB Black in an outdoor location and it runs 24/7 with no hitches, and has been for months. It's in San Francisco and it's inside a control box, so not the most extreme conditions, but it has survived all the recent wet weather and hot days last summer with aplomb.
edit: I have flashed the firmware numerous times on several boards and have never had an issue.
What's really great about this board is the practical approach: integrate things that people will need to build real-life robotics devices. A good example: 2S LiPo charger, not obvious to do yourself, and required if your project is supposed to move beyond your benchtop.
The main CPU is a Cortex-A8. In additions, there is a PRU-ICSS (Programmable Real-Time Unit Industrial Communication Subsystem), which has two 32-bit RISC cores. The latter can handle hard real-time intricacies without any latency from the A8. It is what sets this board apart from the simple-minded Raspberry Pi and other boards.
In practice, you can use the A8 as if the PRU is not there for 99% of what you want to do. You can also get into programming the PRU itself, but this is very much for the advanced user.
BTW, I don't see the PRU referred to anywhere else as "Cortex-M3".
There are two lines in the spec summary. The PRU is one, a Cortex M3 is another. It's not unliklely that the SoC indeed has both, intending the ARM for use as a very low power, always-on sensor listener (e.g. the DSPs that handle audio and sensor input on phones so they can wake up the main CPUs for gesture or voice recognition).
Except the datasheet [0] does not list anywhere "Cortex-M3", nor reference any ARM cores other than the Cortex-A8. So if it is there, they are keeping it a deep secret.
What a surprising find! I would imagine Cortex-M3 (with 24 KiB RAM in total) a huge overkill for just power management. And it totally escapes me why the realtime co-processors are using a custom ISA solution rather than just using Cortex-M0/3/4. Would have been great to leverage the mature toolchain for Cortex-M!
Power management on modern SoCs is actually really complicated. There are dozens of power rails and clocks for different subsystems that all must be brought up and down with controlled order and timing if the device is going to work reliably. This kind of controller is routine on most "big" SoCs these days.
Presumably so they can share the workload with other tasks, like boot verification or low power sensor listening. The M3/M4 are still very small cores.
The M3 is not well documented. The big thing to discover is the memory map to get at the IO. At least the firmware is open source to help provide a starting point and it includes some base addresses for peripherals in the system.
Here's an idea: create a subscription service that signs me up for 20 USD per month and gets me the latest hip boards in a reasonable time frame (I realize that this specific board is outside of this price range).
Your gonna end up with a bunch of Amlogic, Allwinner & Rockchip boards with little to no software support unless you get a bunch of H3 based Allwinner boards. Most of what is out there is nothing to write home about, the decent stuff (eg. OrangePi PC) is either pure luck, or browbeating by the community (OrangePi+ 2e) with the occasional vendor like FriendlyARM coming in using SOCs that the community mainlined support for.
Then you have incompetent vendors like Olimex, Pine64, Next Thing Co (of C.H.I.P., the "$9" SBC) that fuck up the hardware, software, or both, and forget critical stuff like heat spreading copper layers in the SBC (Olimex), misroute ethernet so it can't actually do a gigabit a sec (Pine64), or lie about SOC software support and scramble to port the closed blobs that make their board work forward (Next Thing Co).
You are bit hard on Olimex -- to be fair, they release hardware specs, schematics and so on well in advance, and in true 'open hardware' form -- so nothing stops you actually reviewing and/or fixing it if you get a chance!
I've used quite a few Olimex boards for pretty serious work project, often as a prototype before we settle on a 'real' hardware to develop, and I've always been very pleased with what I've got. Altho, I haven't bough any of their 'really fancy' boards lately.
Disclaimer: I was the one who rewrote and upstreamed the original Mini2440 'friendlyarm' board.
I'm a big fan of Olimex and have been impressed overall by the reliability of their boards, and I really appreciate the openness of their hardware and development process (e.g., you can check out eagle files for boards that haven't event been released yet and provide feedback)
Which Olimex board? As part of evaluation of a next gen product we had thermal imaging done on an A20 with very positive results. They usually use industrial rated parts.
They refused to remove a label from their SoC in production so we could install a thermal sink plate in our final assembly. Even for 2,000 SOMs/year they wouldn't do it. Went to Boundary Devices and they happily helped us out.
$60/quarter was what you asked for, interestingly.
third one ships this week or so.
I'm not sure if its an upside or a downside that all the boards are adafruit products. Its adafruit so its excellently documented but its essentially the "feather ecosystem quarterly subscription" in practice. I realize they have customer service type costs but it would be interesting to see something other than feather ecosystem products. I'm not saying its not fun, its a lot of fun, I'm just saying it would be more fun to get something truly weird in the box.
I enjoyed building the robot in the second box and generally hacking around on it.
Now if only ¨they¨ would re-release R2D2 I´d have the perfect project board for the perfect project bot. But at $500 plus I´m not to inclined to get the sawzall and soldering iron out.
They're a little weird about joining before access is granted to see the goodies and get involved in the group buys and so forth. I've been meaning to get started on a styrene laser cut but... life, infinite number of things to do, its warming up outside so I'm more motivated to daydream about my electric bicycle conversion plans so maybe next winter, etc.
I don't see the point in spending $600 for anything but a 1:1 scale model, and conveniently you're looking at "high three figures" for styrene unlike the $2K or so for all aluminum. Also a lot of cost depends on insistence on perfection delivered today vs "ah I'll put that detail on next winter" attitude. There's a big cost difference between "I'm building a droid that looks like its in the R2 family from 50 ft away" vs "I am making a droid that is so good that it could be used in a hollywood movie as a prop if not main character"
Right here is the biggest benefit to these boards over say a raspberry pi. The IO rate on an SD card is so pitiful. It's extremely slow to do anything other than writing out logs.
Having 4GB of flash will help speed these little devices up a lot!
This is awesome. Although for any modern robotics project you definitely need a powerful gpu. What's the support on the board to hook up an external gpu?
Looking at the kinds of projects they have show on the page, it seems that a GPU is not useful for most of those.
For the projects where you would benefit from a GPU, you could perhaps commicate with a bigger computer that does the calculations? Too much latency for some applications of course but not for others.
If your project really needs a GPU and it needs it on the device that is controlling the robotics components, I think probably something other than the BB Blue would be more appropriate.
http://www.cnx-software.com/2014/06/18/bluesteel-basic-beagl...
The interesting part of this one, to me, is the Octavo packaging of the AM335X processor with on-die RAM. That makes the board much simpler. Though, I thought it would make a bigger difference in price. The BeagleBone wireless that uses the same chip is ~$68, which is $7 higher than the Black that has separate RAM.
If you haven't used a BB product, check out the thing that I think is the biggest upside of these...the built in pair of PRUs. It's like having the best of a normal linux board plus a microcontroller on the same board. Since the PRU shares memory with the main CPU, you can offload things that need to be realtime. That allows for things like a near professional-level LED matrix controller (https://trmm.net/LEDscape) or even a DIY video controller (https://trmm.net/Mac-SE_video).