If you were Registered and logged in, you could reply and use other advanced thread options
|
Posted by BobH on October 19, 2009, 8:10 pm
Frnak McKenney wrote:
>> Also, nobody uses stepping motors for mobile robots much any more.
>> They use full power under no load, and consume power when stopped. So
>> they're awful for battery life.
>
> Sorry to jump in like this, but your comment piqued my curiosity.
>
> A few years... okay, decades... back, it seemed like every robot
> article I read talked about using stepper robots in homebrew
> machines; "standard" DC motors were mentioned, but not nearly as
> often.
>
> Is my memory playing tricks on me? Or were there reasons why stepper
> motors were more popular for hobbyist use a while back? I know that
> they seemed more readily available from discard bins (floppy drives,
> hard drives, printers), and a pulse-to-distance-moved calculation
> might have seemed more "precise" for ded. reckoning purposes.
Another factor is that there are a number of microcontrollers available
now with quadrature counters and PWM generators onboard. These make it
easy to do closed loop DC motor drive. In the old days, quadrature
counting had to be done in software or external hardware. Also,
quadrature encoders with good resolution are available pretty cheaply now.
BobH
|
|
Posted by waynegramlich on October 19, 2009, 2:03 pm
John Nagle wrote:
> Bob Smith wrote:
>> Hi
>> I would appreciate the opinions of the Linux robot builders
>> in this group. The question is whether you would prefer a real
>> device driver for robot peripherals or a unix socket interface
>> to it. Some background on my question can be found at:
>> http://www.linuxtoys.org/usd/UserSpaceDrivers.html
>
> Take a look at two open source projects already used for robot
> control: The Willow Garage robot operating system
> ("http://www.willowgarage.com/pages/software" )
> and "Player/Stage".
> ("http://playerstage.sourceforge.net/" )
Has anybody sucessfully downloaded ROS yet? I tried and their
configuration script was littered with bugs.
> Sending text over sockets, organized as if you were writing
> to device registers, is not the way to go. You need a messaging
> protocol.
Agreed.
> Also, nobody uses stepping motors for mobile robots much any more.
> They use full power under no load, and consume power when stopped. So
> they're awful for battery life.
Most hobbyist robots use DC gear motors these days for the
reasons that John enumerates. In addition, stepper motors
lose torque at higher speed. On a flat surface, you can turn
off power to stepping motor and it will hold position, but
the power off retention torque is quite small and easily
overcome. While I occasionally see a hobby robot with a stepper
motor on the inside, it is definitely the exception, not the
rule.
-Wayne
|
|
Posted by bsmith on October 19, 2009, 10:50 pm
John Nagle wrote:
> Take a look at two open source projects already used for robot
> control: The Willow Garage robot operating system
> ("http://www.willowgarage.com/pages/software" )
> and "Player/Stage". ("http://playerstage.sourceforge.net/" )
Thanks. Looks like Willow uses Player. Doing Player drivers may
make sense when we have more time. For now, we are trying to get
the low level stuff working and visible to a Linux program.
> Sending text over sockets, organized as if you were writing
> to device registers, is not the way to go. You need a messaging
> protocol.
OK. Shoot, text over unix sockets is the front-runner right now.
Why is text to a socket wrong?
Why is a messaging protocol better?
In the FPGA are a set of nine different, user selected peripherals.
Each peripheral has a set of registers that control its operation.
For example, the H-bridge controller has a register to control the
frequency of the PWM signal as well as the pulse width. The actual
protocol to the FPGA is a SLIP encapsulated steam of command and
response packets. Is this the kind of messaging protocol that you
would like to see? We are planning on documenting the register
sets and protocol, so maybe that's all that's needed?
thanks
Bob Smith
|
|
Posted by dhylands@gmail.com on October 20, 2009, 12:36 pm
Hi Bob,
> > Sending text over sockets, organized as if you were writing
> > to device registers, is not the way to go. You need a messaging
> > protocol.
> OK. Shoot, text over unix sockets is the front-runner right now.
> Why is text to a socket wrong?
> Why is a messaging protocol better?
Messages usually have things like CRCs. That way you have some
assurance that the data wasn't corrupted along the way.
> In the FPGA are a set of nine different, user selected peripherals.
> Each peripheral has a set of registers that control its operation.
> For example, the H-bridge controller has a register to control the
> frequency of the PWM signal as well as the pulse width. The actual
> protocol to the FPGA is a SLIP encapsulated steam of command and
> response packets. Is this the kind of messaging protocol that you
> would like to see? We are planning on documenting the register
> sets and protocol, so maybe that's all that's needed?
Yeah. I would definitely prefer that level of interface. That way I
can do something more fancy if I like, but I can also be low-level if
I like. Then if you want to get fancy, provide a library which
translates a function API into packets, and a way of integrating the
delivery of said packets. Lots of programmers (especially beginners)
aren't as comfortable dealing with packet based protocols. But all
programmers work with a C API (aka the C runtime library).
By splitting (factoring) the code this way, you can move the "function-
API to packets" to any processor/micro quite easily.
Dave Hylands
|
|
Posted by Joe Pfeiffer on October 20, 2009, 10:44 pm
>> > Sending text over sockets, organized as if you were writing
>> > to device registers, is not the way to go. You need a messaging
>> > protocol.
>> OK. Shoot, text over unix sockets is the front-runner right now.
>> Why is text to a socket wrong?
>> Why is a messaging protocol better?
> Messages usually have things like CRCs. That way you have some
> assurance that the data wasn't corrupted along the way.
I came in late in this discussion -- most of the time, people who say
they're communicating using text over sockets are talking about TCP.
That's a reliable protocol; your bits do all get delivered, and you
don't need to implement the CRCs yourself. I noticed below he says he's
using SLIP, which to me also implies TCP (if it's a text stream!).
>> In the FPGA are a set of nine different, user selected peripherals.
>> Each peripheral has a set of registers that control its operation.
>> For example, the H-bridge controller has a register to control the
>> frequency of the PWM signal as well as the pulse width. The actual
>> protocol to the FPGA is a SLIP encapsulated steam of command and
>> response packets. Is this the kind of messaging protocol that you
>> would like to see? We are planning on documenting the register
>> sets and protocol, so maybe that's all that's needed?
> Yeah. I would definitely prefer that level of interface. That way I
> can do something more fancy if I like, but I can also be low-level if
> I like. Then if you want to get fancy, provide a library which
> translates a function API into packets, and a way of integrating the
> delivery of said packets. Lots of programmers (especially beginners)
> aren't as comfortable dealing with packet based protocols. But all
> programmers work with a C API (aka the C runtime library).
This makes a lot of sense. Really, even if you aren't a beginner, what
you want for device control is an API that provides the functions you
want. For a really good example, look at FUSE filesystems -- it's
really communicating between a daemon and the kernel over a socket, but
completely hides the details of the protocol from the programmer.
If you've got it available, you might think about using SCTP rather than
TCP or UDP -- it provides reliable, sequenced delivery of packets, so
for a lot of applications it's really the best of both of those worlds.
> By splitting (factoring) the code this way, you can move the "function-
> API to packets" to any processor/micro quite easily.
Yes.
--
As we enjoy great advantages from the inventions of others, we should
be glad of an opportunity to serve others by any invention of ours;
and this we should do freely and generously. (Benjamin Franklin)
|
Page 2 of 3 < 1 2 3 > last >>
Related Posts
Latest Posts
|
|
Yahoo! 
Google 
Windows Live 
del.icio.us 
digg 
Netscape 
XML site map
>> They use full power under no load, and consume power when stopped. So
>> they're awful for battery life.