BeagleBone Blue – A complete, Linux-enabled robotics computer
beagleboard.org
beagleboard.org
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).
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.
Related, the lowRisc RISC-V project has a concept of minion cores: http://www.lowrisc.org/docs/memo-2014-001-tagged-memory-and-...
http://www.nxp.com/products/microcontrollers-and-processors/...
They really pissed us off with that crap, and our shop at least probably won't be buying NXP parts for a while.
Because the vendor should provide an SDK for development?
It's fine if the vendor's image is based on Yocto, but you should still be able to download something from them with instructions.
That's literally what Yocto builds for you.
you should still be able to download something from them with instructions.
As an example, here's Freescale/NXP's github with their Yocto recipes. It was not "nuked from orbit" on the purchase.
https://github.com/Freescale/fsl-community-bsp-platform
And a sample build guide:
http://www.nxp.com/assets/documents/data/en/release-notes/IM...
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!
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.
It's open source, here's the PRU code: https://github.com/BelaPlatform/Bela/blob/master/pru_rtaudio...
This paper describes the platform in more detail: http://www.eecs.qmul.ac.uk/~andrewm/mcpherson_aes2015.pdf
This paper compares latency achievements using this strategy compared to Raspberry Pi, Arduino, Max/MSP, etc: https://qmro.qmul.ac.uk/xmlui/bitstream/handle/123456789/124...
Here's an excerpt:
"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)."
Can any of this feed into the TSN(Time sensitive networking)/AVB(audio video bridging) standards?
I haven't found anything useful in that space.
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.
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).
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.
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.
I ended up going Navio2 and haven't looked back. Also the RPI3 is powerful enough to run list ROS tasks.
https://www.embeddedrelated.com/showarticle/586.php http://elinux.org/ECE497_BeagleBone_PRU http://processors.wiki.ti.com/index.php/PRU_Linux_Applicatio... http://hackaday.com/2014/06/22/an-introduction-to-the-beagle...
http://www.righto.com/2016/09/how-to-run-c-programs-on-beagl...
The story of why this world of "linux" machines is a disaster in seven words. I'm sure this new BeagleBone is just a tarball flinger too.
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".
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.
Here's another TI repo where they're at 4.4.32: https://git.ti.com/processor-sdk
Release notes (dated 12/2016): http://processors.wiki.ti.com/index.php/Processor_SDK_Linux_...
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.
Start here:
Their distro is a pre-configured raspbian, so you do have an upgrade path. Their board is supported by ArduPilot upstream.
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.
[1] http://www.trossenrobotics.com/c/robotis-dynamixel-robot-ser... [2] https://openservo.org/
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).
[1] http://www.trossenrobotics.com/dynamixel-xl-320-robot-actuat...
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.
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.
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.
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 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.
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".
https://www.element14.com/community/community/designcenter/s...
[0] http://octavosystems.com/octavosystems.com/wp-content/upload...
I stay away from BBB because it's _so_ hard to use, at least from me/my team's experience.
https://e2e.ti.com/support/arm/sitara_arm/f/791/t/284956
http://arago-project.org/git/projects/?p=am33x-cm3.git;a=sum...
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).
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.
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.
https://www.amazon.com/gp/offer-listing/B002KHN23S/ref=dp_ol...
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"
Setup a proper organisation, with proper ways to handle commercial interests, etc.
Looks like it works right out of the box with ardupilot's git head
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!
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.
Wat. I know this is hacker news, but not every project requires a DNN.