DPRG
DPRG List  



[DPRG] The ideal robot controller

Subject: [DPRG] The ideal robot controller
From: David Anderson davida at smu.edu
Date: Mon Nov 28 23:12:27 CST 2011

It seems to me, (and I've opined this before to more or less unanimous 
indifference) that we spend a lot of time as robot builders flitting 
from one shiny piece of hardware to another in search of the perfect 
robot controller.   Perhaps in the belief that the hardware is what is 
limiting our imaginations.

This seems to me somewhat like looking for the "ideal" musical 
instrument.  Presumably to play the "ideal music."  Violin and pipe 
organ are very different in their capabilities, but both can make 
wonderful music.

The analogy is this:  we always seem to be moving from one "instrument" 
to another without ever getting any good at playing the one we have.   
And that, it seems to me, is really the key.    Moving to another 
instrument won't make you a better musician.

So I'm not really sure that there is anything like an ideal robot 
controller, any more than there is an ideal musical instrument.  And I'm 
not sure that it makes much difference, in either case.  Just pick one.  
And start practicing. 

You will get better and better as you do it:

<http://www.youtube.com/watch?v=F2ZShmt19uQ>

cheers!
dpa




Randy M. Dumse wrote:
> Paul Bouchier said: Monday, November 21, 2011 3:35 PM
>   
>> I understand your statements about DSP's (some
>> aspects of motion control can be compared to 
>> signal processing),
>>     
>
> {Warning, somewhat long commercial post follows}
>
> While it is a true statement, DSP's are often the best solution
> for motion control issues, and the math of the DSP screams, the
> DSP I'm using is dual purpose as a general purpose controller as
> well, and the real difference here, in my opinion is the motion
> control peripheral hardware that's built in. This chip was
> specifically designed with motion control in mind. Since the PWM
> and Timers are so configurable, it is difficult to talk of a
> specific configuration, because there are so many ways the
> hardware can be configured. 
>
>   
>> all the features I want EXCEPT perhaps(asking 
>> you here) for debugging on the DSP, if users 
>> are expected to do any debugging on the DSP. 
>>     
>
> Development and debugging is interactive, which is quite a
> different approach than you are expecting, but every bit as
> effective, or more so. 
>
> The language is our IsoMax(TM) which is a statemachine based
> paradigm on top of a Forth procedural language. You talk to the
> micro in its foreground. You make definitions describing the
> functions you want done. When you're happy with your program,
> you install it into the background. It runs. You can still
> interactively develop more code in the foreground, or monitor
> the processes going in the background. It's like a multitasking
> OS that way. In fact you can use the foreground as a means of
> allowing a host to issue commands, get reports, or query
> variables, change settings. 
>
>   
>> 6 channels of PID is a function of A/D speed and
>> floating-point performance,
>>     
>
> We are "mixing" several "metaphors" here, If you want to talk
> A/D, 16 channels of PID should run at greater than 1 kHz update
> rate on the SuperPod(TM). 
>
> The PID here, is scaled integer, and is in firmware. While I
> have done dual PID's with floating point calculations in high
> level language on the 'Pod's (examples on the website), we tried
> for optimized performance on our firmware, so we did integer
> scaling, which is even faster than the very fast floating point.
> (But still, to keep perspective, the floating point is firmware,
> and not a FP coprocessor.) 
>
> When I suggested 6 PID's I was talking about 32-bit position
> from quadrature and 2 complementary PWM outputs per loop. The
> number chosen, 6, was a hardware I/O limitation, not a software
> capability one. There are two hardware quadrature decoders
> built-in, and the timer pins can be used in pairs to configure a
> total of 7, but usually I think in terms of 6 axes of motion,
> since a couple timers will probably be needed for other
> functions. There are 12 hardware PWM outputs, so the quadratures
> match the PWM's well. We have found that "read encoder, update
> trajectory, compute PID, output to PWM" takes about 25 usec.  So
> in theory you could run six of these devices at a 4 kHz update
> rate and still get a tolerable foreground response. 
>
> Now what's really special about these PID routines is they are
> modular and set up in high level language. So you can use any
> error input you like, position, velocity, sourced from A/D or
> quadrature, or even something as wild as serial input.
> Personally, I've never seen anything like the flexibility
> possible with our firmware.
>
> Now when you realise the very successful dpa SR04, based on a 2
> MHz 68HC11, ran much slower at 50 or 60 Hz updates, you get a
> sense of what I mean about the 'Pod's being the very best you
> can get today.
>
> There are a few micros just now coming out with more than one
> quadrature decoder. Most (like AVR) have none. Some have one. A
> very rare case has two. Then there are just coming into the
> market some CPU+FPGA combinations (like PSoC5) that allow
> potentially more than two quadrater channel readers. Again the
> bigger 'Pod's allow up to 7 in hardware. 
>
>   
>> and relates in part to the minimum frame time 
>> at which the system would perform that - I 
>> think you need to state that.
>>     
>
> The above estimates were for the ServoPod(TM). The new
> SuperPod(TM) runs 50% faster. Plus the whole language has been
> speed up considerable, perhaps 5x in performance.
>
>   
>> 12 servo channels seems like a lot to me (unless
>> I'm building a hexapod), but I may be thinking
>> too small.
>>     
>
> The various hexapods I've made had 3 joints per leg, so a total
> of 3x6 or 18 servos. Then I still had outputs for the pan and
> tilt head, and still 6 timers left over, some used for sonar,
> etc.
>
>   
>> I might be missing your point on set/forget PWM
>> channels
>>     
>
> Yes, perhaps. Many of the smaller micros use timers to do the
> job of creating PWM with software. An interrupt happens at each
> edge of the time of the PWM changing where the output pin is
> toggled, and the time to the next interrupt computed, and either
> loaded as an interval into the timer, perhaps put in a compare
> register allowing the interrput to happen automatically when
> that amount of time passes. 
>
> Some have hardware that can generate PWM. With those, you have
> two registers you can put the cycles to be counted, and the
> counter/timer will alternatively load itself from one value or
> the other. Each timeout changes the output pin. So beyond
> loading the two registers, there's no software involved. Once
> the timer is set, it continues to output repeatedly the
> alternative count values. 
>
> As I recall the Arduino is based on the ATmega328, which has 14
> I/O pins of which 6 can be hardware PWM. 
>
> http://www.arcfn.com/2009/07/secrets-of-arduino-pwm.html
>
> There are only three timers to the chip, so you at most can
> probably do 2 of the 8-bit counters for PWM, and use the other
> 16-bit timer for system timing. 
>
>   
>> (not sure what you mean by setting quadrature
>> channels - maybe stepper driver?).
>>     
>
> Ah, no, nothing to do with steppers. In fact, steppers are often
> used open loop, so they only occassionally are used with
> quadrature decoders.
>
> Quadrature decoders take the outputs of optical encoders
> (incremental  - just two lines A and B) and track rotation to a
> count the position. 
>
> Quadrature decoders can be done in hardware or software. In
> hardware, any time you want to know the position of a robot
> based on wheel rotation, you just read a register. In software,
> you have to make a statemachine which tracks which line changes
> (only one is allowed to change at a time by the nature of
> quadrature) and even if the wheels turn forward or backward,
> your total count stays with the wheel.
>
> This is a hard task for software. Usually the top end of the
> rate the counts come in is limited if you go software. People
> often make wrong assumptions about reading quadrature, and get
> it wrong. For example, link below shows an EDN article, a
> wonderful analysis about statemachine design, followed by a
> faulty software implementation. I commented on this article in
> the feedback section.
> http://www.edn.com/article/512304-Decode_a_quadrature_encoder_in
> _software.php
> To do quadrature right you can completely consume an AVR just
> tending to two channels. 
>
>   
>> Arduino lets you set PWM. 
>>     
>
> Yes the ATMega328 has three timers. These can control 2-each PWM
> lines. But the timers are a very scarce resource on this chip.
>
>   
>> Or are you talkingabout programming a ramp?
>>     
>
> No, I wasn't. But I can if you like. Again, profiling is built
> into the SuperPod(TM) firmware. So you can do controlled
> trapezoidal moves. Already programmed in for you.
> 	
>   
>> Android + 'pods is going to end up a 2-debugger, 
>> 2-IDE solution isn't it?
>>     
>
> Yes, except there is no need for a special IDE or debugger for
> the 'Pod. You are interactive to it, and use high level
> constructs with an inherently multitasking operating system. 
>
>   
>> What really impressed me about the VexPro is that
>> it does do all the things I asked for in one
>> package (but I may have rose-colored glasses on,
>>  so welcome bashing it to give me a balanced viewpoint.) 
>>     
>
> I can't say if you have rose-colored glasses on, because I don't
> know the VexPro. But I doubt you can do as much with a VexPro as
> you can with an Android phone.
>
>   
>> Built-in webcam support and audio support comes with Linux.
>>     
>
> Yes, but, Android is Linux "plus". Linux is the undercore of
> Android. And the cameras on a phone are built in. Mine has two;
> an 8M on the back and a 1.3M on the front. It also has a USB
> port, but it is more of a peripheral port iirc.
>
>   
>> USB wifi dongle is natively supported by Linux.
>>     
>
> Built-in WiFi on the Android phone. Some of them can even be
> 3G/4G hotspots, allowing internet services to other devices on
> your robot.
>
>   
>> ... price & perf are reasonable (200MHz Arm,
>> 32/64MB Flash/RAM, $350). 
>>     
>
> Android phone or tablet, 400 to 1GHz dual core, $200 to $600.
> 32G Flash.
>
>   
>> I suspect you're going to tell me the performance
>> I want isn't really there, 
>>     
>
> No, it's a fair bit better than 99% of the robots we're used to.
> But 200 MHz isn't very effective when you're dealing with video.
>
>
>   
>> I'm interested in what you think is wrong with it:
>>     
>
> Well, having the FPGA available is very interesting.
> Potentially, a FPGA could be used to create "hardware" like I've
> described in the SuperPod(TM), something like the PSoC5 I've
> already mentioned. Can the setup in it be changed? Or is it
> fixed in function? Something they created? What functions is it
> dedicated to in the controller? 
>
> Randy
>
>
> _______________________________________________
> DPRGlist mailing list
> DPRGlist at dprg.org
> http://list.dprg.org/mailman/listinfo/dprglist
>
>   

More information about the DPRG mailing list