Driving multiple servos from the RaspberryPi

[rgh]

Some people have requested that a servo output turns off automatically if no
new pulse width has been requested recently, and I've had two reports of
servos overheating when driven for long periods of time. To support this
request, ServoBlaster now implements an idle timeout which can be specified at
module load time. The value is specified in milliseconds, so if you want
to drive your servos for 2 seconds following each new width request you would
do this:

sudo insmod ./servoblaster.ko idle_timeout=2000

Typical small servos take a few 100 milliseconds to rotate from one extreme
to the other, so for small values of idle_timeout you might find the control
pulse is turned off before your servo has reached the required position.
idle_timeout defaults to 0, which disables the feature.

[rgh]

Kernel module on github has been updated to work with the current 3.6.11+ kernel.

[joan]

... and I've had two reports of
servos overheating when driven for long periods of time...

Shouldn't happen unless they are being continually repositioned or they are acting against a force. I've fried a couple of the cheap miniature hobby servos by driving them for hours at a time when testing.

[Forris]

Hi, I am trying to get ServoBlaster to work on my Pi but I am having a problem loading the module.

I have cloned the source from GitHub. I have the 'PiBits' directory with with 'servoblaster.ko' module in it. I have followed the instructions form this thread (at least 4 times). I have checked my spelling at each stage.

I have updated/upgraded Raspian.

When I try 'sudo insmod servoblaster.ko' (from the ServoBlaster directory) I keep getting

Error: could not insert module servoblaster.ko: Invalid module format

I am new to Linux & Github so I have been following the instructions carefully and have spent the morning googling round in circles. Any help would be appreciated - thanks.

[rgh]

Hi Forris, the tricky bit is that the kernel module has to be built for your kernel version. I'm assuming you are running Raspbian. If you type "dmesg" and hit return you'll see the most recent kernel log. At the end there will likely be a line or two relating to servoblaster, maybe something like this:

Code: Select all

[22187.848520] servoblaster: disagrees about version of symbol module_layout

You can see what kernel version you are running with the "uname -a" command:

Code: Select all

[email protected] ~ $ uname -a
Linux raspberrypi 3.6.11+ #358 PREEMPT Tue Jan 15 00:45:33 GMT 2013 armv6l GNU/Linux
[email protected] ~ $ 

If you have an uptodate system you'll likely have a 3.6.11+ kernel. If you have an older system you'll likely have 3.2.27+.

You can see what your servoblaster.ko module is built for with the modinfo command. This example is for a 3.2.27+ module (see the vermagic line):

Code: Select all

[email protected] ~ $ modinfo ServoBlaster/servoblaster.ko
filename:       /home/richard/ServoBlaster/servoblaster.ko
license:        GPL v2
author:         Richard Hirst <[email protected]>
description:    ServoBlaster, Multiple Servo Driver for the RaspberryPi
srcversion:     C6676B07E83BC0E1F515218
depends:        
vermagic:       3.2.27+ preempt mod_unload modversions ARMv6 
parm:           idle_timeout:Idle timeout, after which we turn off a servo output (ms) (int)
parm:           granularity:int
parm:           units:Units in which pulse widths are specified (1 or 10us) (int)
[email protected] ~ $ 

Anyway, if you have 3.2.27+, try this older module:

https://github.com/richardghirst/PiBits ... blaster.ko

For 3.6.11+ try the latest version from github (I just updated it a few hours ago):

https://github.com/richardghirst/PiBits ... blaster.ko

It is possible neither of these modules will work for you (sometimes the kernel version might be right, but changes in the kernel configuration can still trip you up). However, if you run rpi-update to get the latest kernel, I'd expect the latest module to work.

Let us know how you get on.

[Forris]

Excellent!!

Thanks for that. I did another upgrade but kernel still showed as earlier version, so I downloaded your older module. I wasn't quite sure what I was doing, but I moved the file across to the Pi using WinSCP (just overwriting the existing module), followed the rest of the instructions and it all seems to have worked. I can see the servoblaster module in the /dev directory and the 'ls -l' command reports the correct info.

Unfortunately, playtime is over for this weekend, but I will be hooking some servos up next weekend (and then adding some Lego!).

Thanks again for the quick reply.

[rgh]

I've been working on a version of servoblaster that runs as a user space process. The hope is that it will be much easier for people to get working than messing with kernel modules, and it will not need to be updated or rebuilt every time the kernel changes. It is pretty much the same from a user perspective (/dev/servoblaster is a FIFO rather than a device file, but you write commands to it just the same way). While this works for me, it has had very little testing, so feedback is welcome. Please see the README on github for more details: https://github.com/richardghirst/PiBits ... rvoBlaster.

[johnnyz77]

Hi Richard

First of all, nice work! Your work here saves all the extra components and programming, which makes your solution beautiful.
Haven't implemented anything as yet, but wanted to ask you some questions before I order parts and start experimenting.

I am an experienced software engineer but pretty much a complete beginner when it comes to hardware (so apologies in advance for any silly questions).

The overall problem I'm trying to solve:
controlling multiple servo motors via some software running on the Pi. So your project here seems super relevant

But I have some queries...

From what I understand, servo has 3 lines: signal, power, ground.

Signal line will go directly to the relevant GPIO pins on Pi, as covered here:
https://github.com/richardghirst/PiBits ... rvoBlaster

But how do I go about the actual wiring / connecting of the right wires to the right pins for power / ground.
How do I connect multiple power lines for the multiple servos into 1 single power pin on the Pi?
Same question for ground lines?
Is there some sort of adapter I should be using??


Also, type of servo...
Can I buy any type of servo?
I have learned that there are different servos that support different weights, than in turn may have different power requirements, when dealing with platforms such as Adruino.
But for Pi, do I need to keep this in mind?? What type of servos should I buy? Within what params should I look, so they are compatible with Pi??


Thanks for your help in advance! Much appreciated.

[joan]

Do not power your servos from the Pi. It might be suffiicient for a small hobby motor, not much else. Take the control signal from a gpio. Use a battery or other power supply for the servos power and ground. Make sure you common the Pi's ground and the power supply's ground. The control signal and servo power lines are separated, so you won't be feeding a bad voltage to the Pi's gpios.

Have a look at http://www.youtube.com/watch?v=Jse3cziVyeg

[mikerr]

If it helps for wiring I've just done this with a slice of pi



http://www.hobbytronics.co.uk/slice-of-pi
http://www.hobbytronics.co.uk/36way-header-254
http://www.hobbytronics.co.uk/jumper-wires-6

Note the power "rails" (easily expanded to 8 servos) and common earth (black from battery pack to 0v on pi)

[johnnyz77]

Do not power your servos from the Pi. It might be suffiicient for a small hobby motor, not much else. Take the control signal from a gpio. Use a battery or other power supply for the servos power and ground. Make sure you common the Pi's ground and the power supply's ground. The control signal and servo power lines are separated, so you won't be feeding a bad voltage to the Pi's gpios.

Have a look at http://www.youtube.com/watch?v=Jse3cziVyeg

Hey thanks for your expert guidance here!
I have continued researching and have come across Raspy Juice as an extension to the Pi.
I'm thinking that maybe I should use this as it seems that:
1. I can have just 1 power supply (instead of needing 2 with original approach) -power comes into Raspy Juice board to power it and then passed on to Pi to power it also
2. It has servo ports and controller to control servers in more stable fashion

What do you think?

[rgh]

Depends what you want. Sevoblaster gives you control for 8 servos for free, and a very simple interface to set the servo positions. That board is fairly expensive (relative to the Pi), and adds a microcontroller in to the picture. You now have to talk i2c to the microcontroller which is running some code which then drives the servos for you. I agree it does make things fairly tidy with respect to the power and servo connections though.

[mikerr]

I expanded my above bit of soldering to 7 servos, and here's a video:



http://www.youtube.com/watch?v=P85Hs004R7U

the video just uses this code to twist the servos back and forth:

Code: Select all

#!/bin/bash

while true
  do
     # step forwards

     for i in {80..230..2}
        do
                echo $i;
                echo 1=$i > /dev/servoblaster;
                echo 2=$i > /dev/servoblaster;
                echo 3=$i > /dev/servoblaster;
                echo 4=$i > /dev/servoblaster;
                echo 5=$i > /dev/servoblaster;
                echo 6=$i > /dev/servoblaster;
                echo 7=$i > /dev/servoblaster;
                sleep 0.1s;
        done

     # step backwards

     for i in {230..80..10}
        do
                echo $i;
                echo 1=$i > /dev/servoblaster;
                echo 2=$i > /dev/servoblaster;
                echo 3=$i > /dev/servoblaster;
                echo 4=$i > /dev/servoblaster;
                echo 5=$i > /dev/servoblaster;
                echo 6=$i > /dev/servoblaster;
                echo 7=$i > /dev/servoblaster;
                sleep 0.1s;
        done
  done

Cost was just the slice of pi and the pin headers (total under a fiver) - thanks for writing servoblaster!

[RomanG]

Anyone experiencing servoblaster interfering with ALSA?
More details here:
http://www.raspberrypi.org/phpBB3/viewt ... 19&start=0

Roman

[rgh]

Servoblaster will always interfere with 3.5mm jack audio because it uses the PCM hardware in order to generate the delays it needs. I'm pretty sure the README does mention that. It is probably possible to modify it to use some other module for its delays, but I've not looked in to it yet.

[RomanG]

Hi rgh,

Thanks for the explanation, that makes sense. I read the README file and you are right, it mentions that the driver uses DMA channel 0, and PWM channel 1, but I did not know that the servoblaster uses the same hardware PWM as audio.
There are two PWM channels on the chip, not sure what the other one is used for, but can servoblaster utilize the other hardware PWM to avoid conflict with audio?
But you probably already looked in to this and I guess it wasn't an option...

I can use a cheap USB sound card for audio to avoid this resource conflict if there isn't other way.

Thanks,
Roman

[joan]

I think a problem is there is only one pwm clock (for channels 1 and 2). That clock needs to be altered to get the DMA timing right.

I've looked at using the PCM peripheral instead of the PWM as its use is more specialised and less likely to conflict with servo users. My results are currently hit and miss.

[rgh]

Hi RomanG,
Please can you try the user space implementation of ServoBlaster, invoked as "sudo ./servod --pcm", and report back? It should use the PCM hardware rather than the PWM hardware. In that mode I am able to control servos at the same time as listening to audio via the 3.5mm jack. See the README for details (updated README aand servod.c a few minutes ago). Thanks.

Joan,
Feel free to review and/or copy the PCM mode code from servod.c - I based it on something I found on the web anyway.. Very lightly tested (it didn't exist 3 hours ago), but seems to work for me.

[joan]

Hi RomanG,
Please can you try the user space implementation of ServoBlaster, invoked as "sudo ./servod --pcm", and report back? It should use the PCM hardware rather than the PWM hardware. In that mode I am able to control servos at the same time as listening to audio via the 3.5mm jack. See the README for details (updated README aand servod.c a few minutes ago). Thanks.

Joan,
Feel free to review and/or copy the PCM mode code from servod.c - I based it on something I found on the web anyway.. Very lightly tested (it didn't exist 3 hours ago), but seems to work for me.

Thanks for the heads up. I shall have a look and hopefully it will solve my problems! (well, the ones I admit to, mainly programming related )

[joan]

I may have misread the code but it seems to be using a PLL rather than the 19.2MHz osc?

[rgh]

I may have misread the code but it seems to be using a PLL rather than the 19.2MHz osc?

That's correct; PLLD is 500MHz (regardless of whether or not you overclock). I guess you could equally use the 19.2MHz osc, but I find the math easier if I start with 500MHz and it is easier to select a wider variety of frequencies for other ideas I'm playing with.

[joan]

OK. In that case, damn, stamp foot, I have one more blunder in my code. But at least I now know where not to look!

[Gert van Loo]

There are two PWM channels on the chip, not sure what the other one is used for

Also audio, it is something called 'stereo'.

[johnnyz77]

Hi Richard or anyone else!

Can't get my servo to move.

I have got all the code/files and connect a single servo to GPIO 4.
Servo is being powered by 4xAA batteries via breadboard.

Problem is when I send it a command such as "echo 0=120 > /dev/servoblaster", the servo moves a fraction of a millimeter and then continuously makes a buzz sound. So the servo doesn't seem to be
properly or at all. No matter what command I send it, it doesnt move. When I send "echo 0=0 > /dev/servoblaster" it stops buzzing.

So I get buzzing, but I dont get movement!!

Any ideas what is going on and how I can fix it?
Maybe I haven't wired things correctly??

Below is output of command line session, FYI


[email protected] ~/tmp/servo/ServoBlaster $ sudo insmod servoblaster.ko
[email protected] ~/tmp/servo/ServoBlaster $ sudo sed -n 's/ servoblaster//p' /proc/devices
248
[email protected] ~/tmp/servo/ServoBlaster $ sudo mknod -m 0666 /dev/servoblaster c 248 0
mknod: `/dev/servoblaster': File exists
[email protected] ~/tmp/servo/ServoBlaster $ echo 0=120 > /dev/servoblaster
[email protected] ~/tmp/servo/ServoBlaster $ echo 0=0 > /dev/servoblaster
[email protected] ~/tmp/servo/ServoBlaster $ echo 0=120 > /dev/servoblaster
[email protected] ~/tmp/servo/ServoBlaster $ echo 0=200 > /dev/servoblaster
[email protected] ~/tmp/servo/ServoBlaster $ echo 0=0 > /dev/servoblaster
[email protected] ~/tmp/servo/ServoBlaster $ echo 0=10 > /dev/servoblaster
[email protected] ~/tmp/servo/ServoBlaster $ echo 0=0 > /dev/servoblaster
[email protected] ~/tmp/servo/ServoBlaster $ echo 0=10 > /dev/servoblaster
[email protected] ~/tmp/servo/ServoBlaster $ echo 0=20 > /dev/servoblaster
[email protected] ~/tmp/servo/ServoBlaster $ echo 0=0 > /dev/servoblaster
[email protected] ~/tmp/servo/ServoBlaster $ ls -l /dev/servoblaster
crw-rw-rw- 1 root root 248, 0 Feb 5 01:01 /dev/servoblaster

[RomanG]

Hi RomanG,
Please can you try the user space implementation of ServoBlaster, invoked as "sudo ./servod --pcm", and report back? It should use the PCM hardware rather than the PWM hardware. In that mode I am able to control servos at the same time as listening to audio via the 3.5mm jack. See the README for details (updated README aand servod.c a few minutes ago). Thanks.

Did a quick test and it seems to be working OK.
With servod daemon running, there is no static in my headphones and when using aplay or espeak, servo does not move and sound is clear.
Thanks a lot!

Roman