DPRG List  

[DPRG] The ideal robot controller

Subject: [DPRG] The ideal robot controller
From: Paul Bouchier bouchier at classicnet.net
Date: Tue Nov 22 14:34:14 CST 2011

What a great response, Dick! Thank you for your thoughts. I buy into all of
it, and you're right, I was aiming my requirements at groups (1) & (2) (i.e.
guys like myself). I asked <anonymous> who the Robot Mag article should be
targeted at, and he advised "guys like me". Your big point is that there is
a market of 100 tier (3) users for every advanced user, and I buy that. The
implication for the VexPro controller is that if it were simple enough, it
could sell a lot more. Vex has aimed the VexPro at the high-end - there's a
note on the product page here:
saying it's for advanced users. You've addressed the requirements from a
tier (3) user perspective, and I value that - it's another perspective worth
thinking about. 

I actually think the Vexpro does a decent job at all your requirements
except it's limited on 2 (C++ challenge), 3 (C++ challenge), 6 (no 3V pwr
out),  8 (no auto-poweroff) & 12 (windoze only). 2, 3, 8 & 12 can be fixed.
I think you'll be impressed when I show you the
installation/programming/debug experience, but I'll be interested in your
take on the C++ library and examples. The big learning for me here is that
with suitable SW, it could be scaled down to address high to low end users,
but it's likely not really there right now.

BTW, HW overview is here:

Thanks again for the great opinion Dick, there's good grist there I can add
to the article.



> -----Original Message-----
> From: dprglist-bounces at dprg.org 
> [mailto:dprglist-bounces at dprg.org] On Behalf Of Dick Swan
> Sent: Tuesday, November 22, 2011 12:03 PM
> To: dprglist at dprg.org
> Subject: Re: [DPRG] The ideal robot controller
> I’ve been down this road before. My bottom line is that 
> everyone will assign different weights to features that they 
> desire. You cannot make “absolute statements” that apply to 
> everyone in general.
> I’ve found that the end users represent a pyramid in terms of 
> size of user base. 1. At the top is the small group of highly 
> skilled end users. Typically their day job is as software or 
> hardware professionals. These are the people capable of 
> designing the hardware or crafting the software development 
> environment. 2. There’s an intermediate group who is capable 
> of contributing input to a software library. 3. The biggest 
> group sit at the bottom and use the results of (1) and (2). 
> I’ve now analyzed this with three major platforms – LEGO, VEX 
> and now Arduino – and they all fit this pattern. All three 
> have approximately the same ratio of sizes for the three 
> groups at 1:10:1000. For example on the Arduino, there’s less 
> than a dozen people worldwide who actively participate in the 
> software IDE and tool chain development, ~50 who contribute 
> software libraries and 10Ks of end users. I think the 
> requirements in Paul’s original email are focused on groups 
> (1) and (2).
> There’s several features that are missing or augment Paul’s 
> initial list: 1. Ease of use is one of the primary factors in 
> purchase decision. 2. Super easy to use software library. 
> Except I don’t want to call it a “software library” but a 
> “solution library” consisting of hardware+software that have 
> been integrated together. 3. Very simple to program. 
> Comparable to the ease of the Arduino programming 
> environment. Eclipse is far too complex. So is “micro .net”. 
> 4. A system level solution. I want something where everything 
> works together. Not something where you may to worry if there 
> are conflicts between different software libraries or 
> hardware peripherals; e.g. I don’t want to find out that 
> sonar sensor library is incompatible with PWM library because 
> of conflicts in use of timers. LEGO and VEX have achieved 
> this; Arduino has not. 5. Terrific short circuit protection 
> with resettable thermal fuses, etc capable of sourcing 
> multiple amps. For instance, the VEX Cortex has two x four 
> amp fuses integrated into the controller. 6. Good support for 
> 3.3V (or lower) and 5V external peripheral devices. 
> Specifically I/O pins support these logic voltages and 
> controller has on-board 5V and 3.3V power for sensors. 7. Two 
> (or four) integrated H-Bridge motor controllers capable of 
> driving one to four amp motors. 8. Auto power off after a 
> period of inactivity. Found in the LEGO Mindstorms and a few 
> other robots. And laptops. And PCs. 9. Support for 3-pin 
> servo control including good mechanism for powering servos at 
> 5V or 6V; i.e. through battery voltage and not via on board 
> logic power supply 10. ESD protection on I/O pins. And short 
> circuit protection. LEGO and VEX are great here. Arduino is 
> not. 11. Controller cost in the sub $100 range. $1K is way 
> too high for hobbyist! Needs to be low enough that you can 
> afford to have dedicated controller for each robot you own 
> and not something that own just one. 12. I only need Windows 
> environment. But many hobbyists want Apple/Mac or Linux. The 
> requirement is starting from scratch can someone learn to 
> create simple programs in 60 minutes? 13. Wireless 
> communications for programming and debugging. Wireless can be 
> an add-on device but price needs to be a $50 or less. 
> Ethernet is not a requirement! 14. The majority of end users 
> don’t care about or need multi-tasking.
> My ease of use requirement for a package is that usage of a 
> package/feature should be as simple as “mouse clicking a box” 
> to activate a feature. 
> • If you have to worry about configuring a router, then it’s 
> already too complex. • If end user needs to know what a 
> socket is then it’s too complex. • If “install vision 
> support” is more than clicking a button then it’s too 
> complex. • I don’t even want to know what “kill errant process” is.
> From: dprglist-bounces at dprg.org 
> [mailto:dprglist-bounces at dprg.org] On Behalf Of Paul Bouchier
> Sent: Monday, November 21, 2011 10:08 AM
> To: dprglist at dprg.org
> Subject: [DPRG] The ideal robot controller
> DPRG folks,
> I want to ask your opinion on the characteristics of an ideal 
> robot controller for personal mobile robots. The reason for 
> asking is I'm writing an article on the new VexPro 
> controller, and I want to check: 1. are there other devices 
> out there which also would meet my requirements? 2. are my 
> requirements off base or missing items? before I make 
> absolute statements.
> My proposed requirements:
> 1. Wide assortment of digital I/Os for driving motor drivers 
> & reading sensors, desirably some motor controllers built in, 
> typical serial I/Fs like I2C, SPI, analog I/Os, serial I/Os, 
> USB host with reasonable camera & USB serial support. 
> Rationale: direct interface to robot HW 2. A "real" 
> multi-threaded OS with filesystem and package manager, with a 
> range of available packages. An example of why I value this 
> is one can run e.g. picocom to manually talk to serial, kill 
> errant processes, install vision support, etc. Note this 
> doesn't require Linux; Windows, or .net with useful packages 
> or even VxWorks may meet the requirement, and perhaps other 
> approaches. 3. Strong development support (rich libraries, 
> debugger with single-step & breakpoints, compiler with good 
> error messages, C or C++ or java or equivalent support (C# is 
> fine, but maybe python/perl are too high-level) 4. Ubiquitous 
> high-performance wireless network support with built-in 
> easy-to-use UI for connecting it to the network. Decent 
> support for multi-channel communication (high-priority 
> requirement driven by video & robot sensing/control channels 
> - sockets support meets this requirement). Effectively I 
> think this means wifi or 3G/4G. Rationale: you should be able 
> to develop/debug/run from any of your PCs, not just the 
> laptop that has some special wireless dongle (medium priority 
> requirement). The built-in configuration requirement is also 
> medium priority, and is driven by ease of getting the robot 
> on the network when you move from home to RBNO to Roborama to 
> other field locations. Even if the robot is completely 
> self-contained, I think there's still a need for decent 
> networking to the developer location, for monitoring 
> operation, debugging during operation, stepping through parts 
> of the program, reviewing logs, etc. A wire tether is clumsy 
> and limits the environment where the robot can be debugged 
> too much IMHO. 5. Decent processor performance. A 
> 200MHz-class 32-bit processor seems to be able to handle 
> video & networking at sufficient rates. 6. Priced at the 
> hobbyist level (sub $1k)
> The closest I've found to the above nirvana is a Chumby with 
> an Arduino or other robot board, and it falls a long way 
> short. The .net boards I've seen
> (Fez) don't have wireless (but maybe one should add a router 
> to them, but then you have to deal with bridging, which 
> brings requirement 4 into play). The gumstix line may have 
> some devices but I don't know the product line well enough 
> and can't figure out if you can get wifi +  USB + GPIOs all 
> in one solution. The robot I/O boards I've seen typically 
> lack wireless/networking/OS. Android with Arduino lacks the 
> debugging support on the Arduino.
> What do you folks think about my proposed requirements? 
> Are there products out there that might meet them?
> Thanks
> Paul
> _______________________________________________
> DPRGlist mailing list
> DPRGlist at dprg.org http://list.dprg.org/mailman/listinfo/dprglist

More information about the DPRG mailing list