There has been number of conversations going on over the past
month about the higher end robots in the club that are using
some sort of 32-bit processor running a fairly stock OS such
as Linux for robotic control. Off the top of my head, I can
identify the following:
- Neato XV11 ARM/Linux
- IOmega iConnect ARM/Linux
- Beagleboard ARM/Linux
- Chumby ARM/Linux
- Pandaboard ARM/Linux
- Intel Atom based board Intel/Linux
- Android cell phones ARM/Android
There are probably a few that I have missed.
The question is "do we really need this much diversity,
or could there be some synergy by having HBRC members
converge on a smaller number (maybe even one) board(s)?"
I am going to propose that people who attend the next
HBRC meeting have a huddle about this topic *after*
the main talk during "random access". From past experience
I know that getting amateur roboticists to agree on
something is harder than herding cats, but there is
no reason not to try.
I'm going to attach a summary message authored by Dave
Curtis of discussion that took place at the Wednesday
night SIG about this topic. (I as not present.)
-Wayne
Dave Curtis' message is below:
---------------------------
Wayne,
You mentioned collecting the ARM suspects together at the next HBRC to
see if we could generate momentum in the same direction.
I don't think ARM is the question. At the last SIG, James, Ralph and I
talked about ARM's/Beagles/Pandas/<whatevers> for a while. I think the
list of questions is more like:
We are really looking for something that:
* has an MMU and runs full libc (not uclibc) Linux
* has software support so that we don't have to compile the world from
scratch
* reasonable performance
* reasonable RAM capacity
* low enough power to not hog a robot's batteries
* practical to use (unbrickable, all nasty packages already soldered
down...)
* reasonably compact
So... while most (all?) of the current candidate systems are ARM, I
think asking "which ARM" is a distraction from the real issues.
I think goals here are:
* focus on non-realtime Linux functionality for the top of the robot
stack, assume the rest comes from microcontrollers.
* find a ready-to-go board with an existing, reasonably stable Linux distro
* find a board with enough power that it satisfies most of us and that
most of us can agree on it -- otherwise the effort is diluted too quickly
* find a Linux distro for that board that most of us can all agree on,
again just to avoid diluting effort
* Add "robotiness" -- OpenCV, ROS packages and such. Hopefully just a
list of packages we can grab and say 'install this".
* Pull together documentation that creates an "HBRC reference system".
a) get this board. b) d/l this image to your SDCard. c) use X brand of Y
(where Y is WiFi dongle, Bluetooth dongle, or other widget), d) adjust
these conf files this way -- now you should have a Linux system tuned
for robotics, and some HBRC members that can answer your questions.
I think non-goals are:
* optimizing the last ounce or mAHr out
* saving the last dollar. This one is likely controversial. But I
assert that getting one of these beasties working reliably consumes
enough effort that we should be looking for the path of least
resistance, and looking for how to maximally leverage individual
experts. For instance, it is much easier for one guy to be able to
say: "This brand of Bluetooth dongle, with this driver, on this release,
of this distro works. And I can help you with your conf file settings."
versus expecting that person to help you because "My bluetooth dongle
costs $4 less."
Success criteria:
We should be able to tell somebody like [redacted]:
1) Write a checks in these amounts for X,Y, and Z.
2) dd this image onto and SDCard and boot.
3) have at it with Python (or what ever).
-dave
> Dave Curtis' message is below:
> * focus on non-realtime Linux functionality
> * find a ready-to-go board with an existing, reasonably stable Linux distro
> * find a board with enough power that it satisfies most of us
> * find a Linux distro for that board that most of us can all agree on
> * Add "robotiness" -- OpenCV, ROS packages and such.
Wayne
It might make sense to talk about this a little on the
mailing list before the meeting as this would give us all a
chance to do our homework on the choices.
To Dave's list I would add "availability". The Neato CPU card
is not available and the Chumby is now out of production.
Price, while not a primary concern, should be considered. A
BeagleBoard needs a good 5 volt regulator and powered USB hub.
This brings the total cost to over $200. The iConnect, on the
other hand seems to work from 7.2 to 18 volts, has a built-in
USB hub, and costs about $90.
I expect one of the big points of contention will be whether
or not floating point is required and how fast the CPU has to
be. That is, ROS might run well enough on a Hawkboard but
might not run well on the iConnect.
Here are some candidates and vendor web sites.
ARM (TI-OMAP w/floating point)
http://pandaboard.org/
http://www.hawkboard.org/
http://beagleboard.org/
ARM
http://www.quickembed.com/Tools/Shop/ARM/Index.html
http://www.glomationinc.com/products.html
http://www.globalscaletechnologies.com/p-22-sheevaplug-dev-kit-us.aspx
iConnect http://gramlich.net/projects/iconnect/notes.txt
Chumby http://www.demandperipherals.com/docs.html#howto, and
http://ozbots.org/
X86
http://www.compulab.co.il/all-products/html/products.htm
http://www.ewayco.com/
http://www.pcengines.ch/order1.php?c=4
http://www.emacinc.com/sbc_pc.htm
Bob
That is why I sent the message out. First, I wanted people
to know that such a discussion is taking place. Second, I
would like people to come with suggestions. Consider the
message above as expanding the discussion from a limited
number of people to all interested parties.
> To Dave's list I would add "availability". The Neato CPU card
> is not available and the Chumby is now out of production.
Agreed. The Neato folks will say you can by as many Neato
CPU boards as long as you buy an XV-11 with them. There are
several versions of Chumby.. I think the latest one is about
to get released. However, I digress. Availability will be
extremely important.
> Price, while not a primary concern, should be considered. A
> BeagleBoard needs a good 5 volt regulator and powered USB hub.
> This brings the total cost to over $200. The iConnect, on the
> other hand seems to work from 7.2 to 18 volts, has a built-in
> USB hub, and costs about $90.
Totally agree. The BeagleBoard also does not have wi-fi built in.
Also, the iConnect has come down in price to about $60. The down
side of the iConnect is that there is essentially no community
and it is very unclear if there is a Linux distribution that
is precompiled for it.
> I expect one of the big points of contention will be whether
> or not floating point is required and how fast the CPU has to
> be. That is, ROS might run well enough on a Hawkboard but
> might not run well on the iConnect.
I'm not aware of the status of ROS running on ARM. Floating
point is darn useful. I'm able to do my image processing on
the iConnect using FP emulation, but my frames per second really
suffers.
> Here are some candidates and vendor web sites.
>
> ARM (TI-OMAP w/floating point)
> http://pandaboard.org/
> http://www.hawkboard.org/
> http://beagleboard.org/
>
> ARM
> http://www.quickembed.com/Tools/Shop/ARM/Index.html
> http://www.glomationinc.com/products.html
> http://www.globalscaletechnologies.com/p-22-sheevaplug-dev-kit-us.aspx
> iConnect http://gramlich.net/projects/iconnect/notes.txt
> Chumby http://www.demandperipherals.com/docs.html#howto, and
> http://ozbots.org/
>
> X86
> http://www.compulab.co.il/all-products/html/products.htm
> http://www.ewayco.com/
> http://www.pcengines.ch/order1.php?c=4
> http://www.emacinc.com/sbc_pc.htm
That list is extremely useful, I'll will spend some time
cycling through it.
-Wayne
You might also look at Freescales 32 bit micros, they offer Arm, PPC and Coldfire boards of different sizes and prices. Most if not all 32 bit boards come with an OS, mainly linux. The boards with OS's come with Uboot. Everything comes in a box, the board, power supplies, and most important CDs with source and the development and debug tools. Freescale: http://www.freescale.com/webapp/sps/site/homepage.jsp?code=PCMCR01&tid=FSH also Axiom offer the same boards as well: http://www.axman.com/ But I think that the real deciding factor is really, $$$, based on; "more bang for the buck". Cesar --- On Tue, 3/29/11, Wayne C. Gramlich <wayne.gra...@gmail.com> wrote: |
|
>
> You might also look at Freescales 32 bit micros, they offer Arm, PPC and Coldfire boards of different sizes and prices. Most if not all 32 bit boards come with an OS, mainly linux. The boards with OS's come with Uboot. Everything comes in a box, the board, power supplies, and most important CDs with source and the development and debug tools.
>
> Freescale:
>
> http://www.freescale.com/webapp/sps/site/homepage.jsp?code=PCMCR01&tid=FSH
>
> also Axiom offer the same boards as well:
>
> http://www.axman.com/
>
> But I think that the real deciding factor is really, $$$, based on; "more bang for the buck".
Well, I think you are hitting at the heart of most important question. My primary motivation is "more bang per expended minute". I just want to get on with building robots, and chasing down every last driver patch gets old in a huge hurry. Saving money at the expense of time is, well, something I don't have time for.
It's possible (and great fun) to build cheap robots.
It's probably possible to build cheap Linux-based robots.
I don't think its possible to build cheap Linux-based robots quickly.
-dave
> To unsubscribe from this group, send email to hbrobotics+...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/hbrobotics?hl=en.
>
>
>
> --
> You received this message because you are subscribed to the Google Groups "HomeBrew Robotics Club" group.
> To post to this group, send email to hbrob...@googlegroups.com.
> To unsubscribe from this group, send email to hbrobotics+...@googlegroups.com.
For Linux on arm I believe this will improve substantially in the not too distant future. Not just because of android work or chromeos on arm, but due to efforts by arm and it's soc partners on linaro.org. That group, which consists of arm, samsung,canonical, freescale, ti and others is working to standardize how things are done in Linux on arm...from kernel to device tree, multimedia, power management etc. If they succeed you'll be able to get one distribution that runs on most arm socs.
By the way, from what I hear from others freescale, although somewhat behind in CPU technology, has one of the more polished Linux distributions.
David
Sent from my iPad
Wayne
What did you have in mind for follow-up actions if we
did/could agree on a board?
The reason I ask is that it seems like one size might not
fit all even if there are three broad use cases.
There will be the cost sensitive cases where the iConnect,
Chumby or whatever hacked-appliance-of-the-day is popular.
In the second case the robot requires floating point and
has to be a single board computer. X86 and ARM Cortex A8
boards like the PandaBoard fit in this case. The third
case covers cost sensitive robots that need floating point.
Seems like a laptop covers the third case best even if it's
not small and low power.
So my question is what would be the deliverables for us if
we can "converge on a smaller number of boards"?
Bob
I was thinking in terms of group buys, install-a-thons,
wiki documentation, maybe even a Google group. Whatever
makes sense given the amount of agreement reached.
> The reason I ask is that it seems like one size might not
> fit all even if there are three broad use cases.
You may be right. Reducing from N to 2 or 3 would still
be a positive step.
> There will be the cost sensitive cases where the iConnect,
> Chumby or whatever hacked-appliance-of-the-day is popular.
I'm a huge proponent of the iConnect, but unless you are planning
on building many copies of the same robot, I'm not sure anybody
is really that cost sensitive. You will probably spend fairly
substantial amounts of money on the other parts of the robot.
What is the incremental cost of going from an iConnect to a
PandaBoard? (~$100)
> In the second case the robot requires floating point and
> has to be a single board computer. X86 and ARM Cortex A8
> boards like the PandaBoard fit in this case.
Agreed. The A8 and A9 stuff looks mighty tempting, subject
to availability (as per your previous post on availability.)
> The third
> case covers cost sensitive robots that need floating point.
> Seems like a laptop covers the third case best even if it's
> not small and low power.
This one is a head scratcher to me. I guess the concept is
that the lap-top comes out of a different budget, so it is
"free". Again, I'm not sure that anybody is really that
cost sensitive, if you only intend to build one robot.
If you intend to buy a laptop specifically for the robot,
I'm not sure you are winning on price. You may win on
convenience though.
> So my question is what would be the deliverables for us if
> we can "converge on a smaller number of boards"?
For each board (if there is more than one), I'd look for
the following:
- Group buy.
- Group build-a-thon.
- E-mails going back and forth about issues.
- Lessons learned and stuffed into a wiki
- git repository of shared code chunks
That kind of thing.
-Wayne
This one is a head scratcher to me. I guess the concept is
> The third
case covers cost sensitive robots that need floating point.
Seems like a laptop covers the third case best even if it's
not small and low power.
that the lap-top comes out of a different budget, so it is
"free". Again, I'm not sure that anybody is really that
cost sensitive, if you only intend to build one robot.
If you intend to buy a laptop specifically for the robot,
I'm not sure you are winning on price. You may win on
convenience though.For each board (if there is more than one), I'd look for
So my question is what would be the deliverables for us if
we can "converge on a smaller number of boards"?
the following:
- Group buy.
- Group build-a-thon.
- E-mails going back and forth about issues.
- Lessons learned and stuffed into a wiki
- git repository of shared code chunks
That kind of thing.
> Bob's excellent question:
>
>> So my question is what would be the deliverables for us if
>> we can "converge on a smaller number of boards"?
>
> For each board (if there is more than one), I'd look for
> the following:
>
> - Group buy.
> - Group build-a-thon.
> - E-mails going back and forth about issues.
> - Lessons learned and stuffed into a wiki
> - git repository of shared code chunks
>
> That kind of thing.
>
> -Wayne
>
My take on priorities is:
1. Define a reference platform.
2. Well curated documentation.
3. Validation
4. Repository of tweaks needed to 'robotify' a reference platform.
I'll argue that a cost-reduced platform should be an off-shoot project.
Just like in the PC world where gamers and scientists pay for high-end
workstations and go through the pain of stabilizing the platform,
then as the technology matures and costs come down it migrates
to mainstream workstations and finally to value-priced systems. We
should expect/create/exploit the same road map.
For anyone still reading, my justification for the above priorities:
1. A reference platform sets a single focus and enables 2,3, and 4.
2. Software/hardware you can't figure out how to use is a waste of
time and money. This is the most important deliverable. One frustration
with the Beagle is poor curation -- the Wiki has 10 pages on any
topic, 8 of which are stale, and 2 of which are terse and or buggy,
and no way to tell which is the best to follow. Certainly none
are robot-specific.
3. Most users of this just want to get on with building robots, not
spend time debugging Linux drivers.
4. It seems to me most of the pieces exist. There are no doubt some
tweaks of the 'use this not that driver' nature. And certainly we
will want to have how-to's for robot-specific chunks like ROS, etc.
But if we spend our time trying to be another Linux distro, that
is time not spent building robots. We should be looking at what
is the *minimal* set of tweaks and software that we actually have
to maintain ourselves.
One thing I want to point out is that most of the work is *not*
Linux guru work -- it calls for people to test images, write
how-to's, and test other people's how-to's. And most of all,
to capture the results in a single, navigable, well-edited form.
After a well-documented reference platform exists, then a
second project can take on squeezing the cost out of it. The
harsh reality is that moving the leading edge forward and
dollar-cost reduction are distractions from one another.
The point of a reference platform is to move the leading
edge forward more quickly by creating a radical
time-cost reduction.
-dave
The Plug computer is fairly nice for a robot. It
has two USB ports, Ethernet, a battery backed RTC,
and the WiFi on it can be an access point (meaning
you don't need to haul around a Linksys WiFi router
any more). The Plug circuit board is self contained,
has four convenient mounting holes and has a 5 volt
connector. (I'll bring one this evening.)
The Plug comes with Debian preloaded so you can do
'apt-get install' just like you can on your Ubuntu
desktop system.
It is not just the Plug of course. The iConnect and
all Plug computers use the ARM CPU from Marvell. So
a bootable USB stick for the Plug would work for the
iConnect or any of the other similar appliances based
on the Marvell ARM processor. I recently wrote a
script to build a bootable USB stick for the Plug and
I'd be happy to write it up as a HOWTO if we select a
Marvell CPU card as one of the HBRC reference boards.
To the stick image we would want to add opencv, maybe
ROS, and any other programs we think useful.
Bob
So what was chosen?
thanks
Bob
Dave Curtis wrote:
> On Mar 30, 2011, at 12:20 AM, Wayne C. Gramlich wrote:
>> - Group buy.
>> - Group build-a-thon.
>> - E-mails going back and forth about issues.
>> - Lessons learned and stuffed into a wiki
>> - git repository of shared code chunks
> My take on priorities is:
We missed you. We had a great meeting.
People quickly zeroed in on the PandaBoard. There was no real
counter proposal (I did ask.)
Enough hands were raised in interest, that it was decided that
forming a separate Google group made sense. I will do that
tomorrow when I am a bit less groggy.
More tomorrow, I'm a bit bushed right now.
-Wayne
We missed your input.
> standard sounds like a good idea and all of the candidates
> looked pretty good.
>
> So what was chosen?
>
http://pandaboard.org I believe.
>
> thanks
> Bob
>
Rafael
> I'm really sorry I missed this evening's meeting. Having a
> standard sounds like a good idea and all of the candidates
> looked pretty good.
>
> So what was chosen?
The direction of the day is Pandaboard.
We'll be setting up an e-mail list for the topic.
FWIW -- I think the reality is that the platform (board + s/w stack) will
evolve over time, so this should be viewed as the
'leading edge' (bleeding edge?) development. The landscape
is changing rapidly, so I think keeping up will require
revisiting this decision periodically -- its more of a
road map than the selection of a specific unit. So I
guess I'm saying I view Pandaboard as the first hardware
point in the roadmap.
Also, I think there is room for a sister project that
does the 'frugal' platform. Hopefully taking the learnings
from the bleeding-edge platform and getting
creative about how to squeeze cost out of it.
-dave
>
>
> thanks
> Bob
>
> Dave Curtis wrote:
>> On Mar 30, 2011, at 12:20 AM, Wayne C. Gramlich wrote:
>>> - Group buy.
>>> - Group build-a-thon.
>>> - E-mails going back and forth about issues.
>>> - Lessons learned and stuffed into a wiki
>>> - git repository of shared code chunks
>
>> My take on priorities is:
>> 1. Define a reference platform.
>> 2. Well curated documentation.
>> 3. Validation
>> 4. Repository of tweaks needed to 'robotify' a reference platform.
>
Bought one a month ago, and decided to frisbee it.
Why?
#1 reason: Chumby Industries did a total "fire and forget" strategy with
this board. Yes, it is 'community supported', but Chumby can't even be
bothered to post the most *basic* information about the board. From the
outside looking in, I don't think they are evil, I think they simply have
such poor software configuration management that they can't tell
if they are afoot or horseback.
#2 reason: It's pretty wimpy. If it was easy to work with, I could deal
with that, but I'm not going to fight reason #1 just to end up with a
wimpy system. My time is worth more than that.
YMMV.
>
> The CHB doesn't have built-in WiFi or the touch screen that the Chumby
> One has. And you can buy a Chumby One on Amazon for less than $70
> now.
>
> I like the fact that both the Chumby One and the CHB have a 3-axis
> accelerometer included. That's a useful sensor for robots that
> require balancing.
Well, yes, but you also need a gyro, which it doesn't have. And you need
a tight realtime control loop, which the CHB linux would get you to.
I see the 'linux' board on any robot as *outside* and real-time work
that needs to happen. Hard realtime needs to be pushed down to
a microcontroller. The Linux board is for 'creature comforts' like
debug and control via WiFi at the basic level, and OpenCV or
OpenKinect or ROS if you have enough oomph.
-dave
>
> Jack
>
>
>
> On Mar 30, 2011, at 3:58 PM, Jack wrote:
>>
>> Chumby announced a "Chumby Hacker Board" (CHB), which is the guts of
>> the Chumby One, but modified to be more hacker-friendly.
>>
>> http://www.adafruit.com/index.php?main_page=product_info&products_id=278
>>
>> You can buy one for $89.95. What do you guys think of this?
>
> Bought one a month ago, and decided to frisbee it.
(more like two months ago, now that I think about it.)
>
> Why?
>
> #1 reason: Chumby Industries did a total "fire and forget" strategy with
> this board. Yes, it is 'community supported', but Chumby can't even be
> bothered to post the most *basic* information about the board. From the
> outside looking in, I don't think they are evil, I think they simply have
> such poor software configuration management that they can't tell
> if they are afoot or horseback.
Actually, just to add some clarification here...
Chumby does have people that patrol the support forums, but they are
USA based and only really know the regular Chumby products.
They can't really help much with the CHB.
The CHB was done in Singapore, and the Signapore devs are
totally MIA. The only time I have *ever* gotten information from
a Singapore CHB Dev is the following procedure:
1. Post several times in the Chumby forums. *cricket's chirping*
2. Post to Adafruit forums, get immediate response from them.
(Part of the response being: you should use the Chumby forums.)
3. Adafruit pokes Chumby using back-channels.
4. Wait one rotation of the Earth for Singapore to wake up.
5. Get information back immediately from Adafruit.
6. Post the information from Adafruit to the Chumby forums,
suggesting that they update the Chumby website.
7. Wait weeks for the 30% chance that Chumby actually *does*
update their web site.
>
> #2 reason: It's pretty wimpy. If it was easy to work with, I could deal
> with that, but I'm not going to fight reason #1 just to end up with a
> wimpy system. My time is worth more than that.
>
> YMMV.
>
>>
>> The CHB doesn't have built-in WiFi or the touch screen that the Chumby
>> One has. And you can buy a Chumby One on Amazon for less than $70
>> now.
>>
>> I like the fact that both the Chumby One and the CHB have a 3-axis
>> accelerometer included. That's a useful sensor for robots that
>> require balancing.
>
> Well, yes, but you also need a gyro, which it doesn't have. And you need
> a tight realtime control loop, which the CHB linux would get you to.
>
> I see the 'linux' board on any robot as *outside* and real-time work
> that needs to happen. Hard realtime needs to be pushed down to
> a microcontroller. The Linux board is for 'creature comforts' like
> debug and control via WiFi at the basic level, and OpenCV or
> OpenKinect or ROS if you have enough oomph.
>
> -dave
>
>>
>> Jack
>>
>>
>