Rex – palm-sized, single-board computer for DIY robots(kickstarter.com)
kickstarter.com
Rex – palm-sized, single-board computer for DIY robots
http://www.kickstarter.com/projects/alphalem/rex-the-brain-for-robots
14 comments
Just asking to those with more knowledge than me. How is this any different to a RaspberryPi or a Beagle Bone Black?
The RaspberryPi is supposed to be a computer you can use like a regular one. Rex seems to have a dual role: It's designed to control a robot (lots of pins and extension boards) and to act as a general purpose computer. So it sits somewhere between an Arduino and a RasPi.
The BeagleBone Black also sits in that range in that it is both an ARM-based general purpose computer but also has 2 real-time programmable microcontrollers onboard. Which isn't to say that this Rex project has no value, if it is produced it would be a much easier out-of-the-box experience for someone to just plug in some garden variety I2C motors and get going than it would be on the Black, but this sort of combined computer/microcontroller design isn't unique to it.
IO expansion and power handling is one differentiator from the Raspberry Pi. The Raspberry Pi has a limited GPIO breakout (useful for many applications, but not tailored for robotics). And, besides not being designed to drive peripherals, the RPi's power system has some issues[1] that even make hosting USB devices a pain.
It does seem like they could target the Beagle Bone Black and focus on the software, but they probably wanted more control over the power and peripheral connect strategy than the BBB provides.
The processor they chose includes an integrated DSP, which could be useful for sensor data processing--or even motor control. The original BeagleBoard offered an OMAP with a DSP, but TI is discontinuing the OMAP line[2] and the newer BBB uses a Sitara A8 processor without the DSP. I didn't see the Rex's processor choice listed on the kickstarter page, but I'd guess it's something like TI's DM3730[3].
In summary, they seem to want to design a board specifically for robotics rather than building upon an existing general-purpose platform. This will give them more control over the power and peripheral strategy that will allow them to achieve a higher level of integration. This could also simplify software by limiting the number of busses and "tacked on" peripherals.
The founders come from Carnegie Mellon University, which has a first class robotics program. Also check out the CMUcam[4] project--an open source, computer vision module. The Pixy (CMUcam5) was funded[5] in September and looks really cool.
Edit: Check out the Rex page on the Alphalem site[6] too. It says that the "Rex can supply up to 20A directly from a 6-12V Ni-MH battery to connected devices. That's more than enough to power a couple servo drivers, Arduinos, rangefinders, and full servo load on an 18-servo hexapod robot!"
[1]: http://www.raspberrypi.org/phpBB3/viewtopic.php?f=63&t=23205
[2]: http://www.eetimes.com/document.asp?doc_id=1262580
[3]: http://www.ti.com/product/dm3730
[4]: http://www.cmucam.org
[5]: http://www.kickstarter.com/projects/254449872/pixy-cmucam5-a...
[6]: http://alphalem.com/pages/rex
It does seem like they could target the Beagle Bone Black and focus on the software, but they probably wanted more control over the power and peripheral connect strategy than the BBB provides.
The processor they chose includes an integrated DSP, which could be useful for sensor data processing--or even motor control. The original BeagleBoard offered an OMAP with a DSP, but TI is discontinuing the OMAP line[2] and the newer BBB uses a Sitara A8 processor without the DSP. I didn't see the Rex's processor choice listed on the kickstarter page, but I'd guess it's something like TI's DM3730[3].
In summary, they seem to want to design a board specifically for robotics rather than building upon an existing general-purpose platform. This will give them more control over the power and peripheral strategy that will allow them to achieve a higher level of integration. This could also simplify software by limiting the number of busses and "tacked on" peripherals.
The founders come from Carnegie Mellon University, which has a first class robotics program. Also check out the CMUcam[4] project--an open source, computer vision module. The Pixy (CMUcam5) was funded[5] in September and looks really cool.
Edit: Check out the Rex page on the Alphalem site[6] too. It says that the "Rex can supply up to 20A directly from a 6-12V Ni-MH battery to connected devices. That's more than enough to power a couple servo drivers, Arduinos, rangefinders, and full servo load on an 18-servo hexapod robot!"
[1]: http://www.raspberrypi.org/phpBB3/viewtopic.php?f=63&t=23205
[2]: http://www.eetimes.com/document.asp?doc_id=1262580
[3]: http://www.ti.com/product/dm3730
[4]: http://www.cmucam.org
[5]: http://www.kickstarter.com/projects/254449872/pixy-cmucam5-a...
[6]: http://alphalem.com/pages/rex
I'm kinda curious about the "20A" part - the PCB traces required to not melt the board while passing that much current would be pretty beefy...
As someone who makes a lot of robots, I will support this on principle. I really like that the board can accept a high current power source and has a cutoff switch.
I am always a little nervous about building a robot around a board when I am uncertain about how it will be supported. If you are really building robots that are going to be used out doors or in rugged environments you want to be able to replace every part. Controller boards aren't really the expensive part of robots.
For Decapitron, an autonomous combat robot (http://forums.parallax.com/showthread.php/140197-Decapitron!), I have had to replace the controller board twice. That may sound like a lot but shorts and power surges aren't that strange in combat. But now that board isn't made anymore. So it is a big problem if the board gets damaged in combat. That's the advantage of using something really standard, like Arduino or Raspberry Pi. I can get one of those next year.
Still, I will try this.
I am always a little nervous about building a robot around a board when I am uncertain about how it will be supported. If you are really building robots that are going to be used out doors or in rugged environments you want to be able to replace every part. Controller boards aren't really the expensive part of robots.
For Decapitron, an autonomous combat robot (http://forums.parallax.com/showthread.php/140197-Decapitron!), I have had to replace the controller board twice. That may sound like a lot but shorts and power surges aren't that strange in combat. But now that board isn't made anymore. So it is a big problem if the board gets damaged in combat. That's the advantage of using something really standard, like Arduino or Raspberry Pi. I can get one of those next year.
Still, I will try this.
As a hobbyist AI programmer with few hardware skills my dream is a for an out-of-the box robot with basic movement, sensors and maybe an arm that I can start programming for in a higher-level language. Rex looks like a huge step in that direction. If they could throw in a chassis for mounting standard motors and sensors, even my multi-thumbed self might be able to make it do something cool.
You might want to check out ROS from the willow garage people. It's probably the right tool that you're looking for.
You should take a look at the Micro Magician V2 http://goo.gl/YunKFR, about a third of the size and motor driver/accelerometer/IR receiver built in. Great for small robots or doing high level coding (their Micro M library makes coding for those features a breeze)
I wonder how much power it drains. The RaspPi uses "only" 3 Watt, but that is a way too much for many interesting applications. There are some hacks to reduce to the power usage (by replacing the voltage regulators for example) but i wonder how much this board will use.
Well, in most cases when 3 W is too much, the application is simple enough that you could do it with an Arduino - which draws far less power.
I always wonder with these boards why wifi isn't just built-in. It seems like a delightfully simpler interface than any wire, and means the base system can integrate with anything else over the network. Sure you can always add wifi, but the point of these boards is that they bundle all the basic stuff, and often include things like development environments that can't make use of wifi if they don't know if it is available. Power is a concern, but you can still turn it off.
It's probably omitted to keep the base cost down. WiFi modules that you can get for low-quantity applications are expensive[1]. Cheaper modules generally require higher-volume consumer electronics applications--not to mention volumes of NDAs simply to get module documentation. Adding WiFi (or wireless comms of any type) also makes you an intentional radiator[2], which potentially complicates your FCC testing, adding cost and delay. So, from an MVP perspective, it makes sense to leave WiFi off if it's not critical to the base application--at least for your first revision.
[1] TI's budgetary pricing for one such module--the CC3000--is about $10: http://www.ti.com/product/cc3000
[2] http://en.wikipedia.org/wiki/Title_47_CFR_Part_15#C_-_Intent...
[1] TI's budgetary pricing for one such module--the CC3000--is about $10: http://www.ti.com/product/cc3000
[2] http://en.wikipedia.org/wiki/Title_47_CFR_Part_15#C_-_Intent...
Thanks for those details, it makes more sense. People usually talk about the cost, which I don't buy – it's worth $10/unit, and these aren't super-low-cost units anyway. And in this case consumers of the Rex aren't going to develop something that will be the basis of thousands of units where that $10/unit cost becomes a big deal.
But I can definitely see how the regulatory overhead would be a big deal, and it seems like that regulation also makes other aspects of integration more bureaucratic. Like I bet a bunch of these chips could be used inappropriately (e.g., to emit stronger signals than are allowed) and they are using NDAs and such as an alternative to other security measures. In a sense USB wireless standards are the one interface/security layer that is well enough spec'd that it is easy to integrate.
But I can definitely see how the regulatory overhead would be a big deal, and it seems like that regulation also makes other aspects of integration more bureaucratic. Like I bet a bunch of these chips could be used inappropriately (e.g., to emit stronger signals than are allowed) and they are using NDAs and such as an alternative to other security measures. In a sense USB wireless standards are the one interface/security layer that is well enough spec'd that it is easy to integrate.
Yeah, I can see how the cost argument is borderline--it really depends upon what you value & connectivity is pretty important nowadays. But, unless the primary application is specifically "connected robots", I do think it makes sense to omit it for the first rev and get a cheaper product out faster. Don't forget that the $10 is the cost of the part itself.* You still need some support circuitry, hardware development time, software development time, testing time, etc. And then there's markup. Assuming absolute minimal costs for all of those--and direct sales with an aggressively minimal margin, I'd still expect a $10 part cost to translate to at least a $20 product cost.
* Admittedly, that $10 is budgetary pricing and would probably come down with negotiation (and there might be cheaper low-volume options--that's just one I knew of offhand). But that's likely still the order of magnitude for the quantities of the Rex.
* Admittedly, that $10 is budgetary pricing and would probably come down with negotiation (and there might be cheaper low-volume options--that's just one I knew of offhand). But that's likely still the order of magnitude for the quantities of the Rex.
The additional marginal cost/unit is pretty low, but the non-recurring engineering cost is pretty high, even without having to deal with suppliers and the FCC. Once you've chosen a wi-fi module, where do you put it on the board? How do you make sure the radio signals don't interfere with the rest of the circuit and vice-versa? It's much easier to just get a USB wi-fi adapter and install the Linux drivers for it.
Built-in WiFi was definitely on our feature-list, but you hit the nail on the head there - cost and FCC compliance were big issues. We decided to keep it simple and add it in via off-board solutions.
If you need WiFi, you could start with one of those low-cost DD-WRT/OpenWrt compatible routers ($15-20 or so: TP-Link TL-WR740N http://wiki.openwrt.org/toh/tp-link/tl-wr740n). They have little RAM, but plenty of I/O (serial, RJ45) and they're still almost "palm-size".
Couple of things I wonder:
- SdCard + full-blown OS = SdCard dies after a while? Or more serious problems like the rPi simply yielding it empty? Could another type of storage be used to boot and run from?
- more information on the OS? What's it based on? Open source so we can fiddle with it?
- what processor is that exactly? Likely the manufacturer provides an OS + libs for it as well (like Ti does for their OMAP), probably the board can be booted with that as well?
- will the schematics be open-sourced?
- debugging capabilities of running programs?
btw quite some comments starting with "I wonder" here. Authors should provide more information probably..
- SdCard + full-blown OS = SdCard dies after a while? Or more serious problems like the rPi simply yielding it empty? Could another type of storage be used to boot and run from?
- more information on the OS? What's it based on? Open source so we can fiddle with it?
- what processor is that exactly? Likely the manufacturer provides an OS + libs for it as well (like Ti does for their OMAP), probably the board can be booted with that as well?
- will the schematics be open-sourced?
- debugging capabilities of running programs?
btw quite some comments starting with "I wonder" here. Authors should provide more information probably..
Howdy, project creator here.
The OS is based on the Yocto Project, so it's a distro we're putting together ourselves. It's still under heavy development, but the goal is to have something minimal that we can throw all our support under without having to rely as much on other distros that already have tons of other boards/projects to worry about.
We haven't committed to open-sourcing the hardware yet, but all the software will be FOSS. The stuff we have so far is on github, and feedback would be great.
The OS is based on the Yocto Project, so it's a distro we're putting together ourselves. It's still under heavy development, but the goal is to have something minimal that we can throw all our support under without having to rely as much on other distros that already have tons of other boards/projects to worry about.
We haven't committed to open-sourcing the hardware yet, but all the software will be FOSS. The stuff we have so far is on github, and feedback would be great.
The OS looks like it's just a linux distro, should be fiddleable (though not sure how easy). The rest I have no idea on yet.
http://alphalem.com/pages/alphalem-os
http://alphalem.com/pages/alphalem-os
Am I the only one to see this and think "They're going back to PCMCIA?" (see http://en.wikipedia.org/wiki/REX_6000 for a "palm-sized single-board computer" complete with 240x120 monochrome touchscreen).
http://alphalem.com/pages/alphalem-os
I like the reference to [MCP](http://tron.wikia.com/wiki/MCP)!
I like the reference to [MCP](http://tron.wikia.com/wiki/MCP)!
[deleted]
Stuff like this is why I run BigBoardList.
Very cool!
Awesome!
Nice!