I bought a 16-servo controller a few months ago. It works fine with the demo application under windows, attached to my laptop (meaning that power, servo and serial cable are alright). When I try to use it under Linux (Suse 9.3), it does not work:
When I start up my Linux box, the controller turns his red LED on and the green LED starts blinking (meaning that the baud rate is wrong). Reconnecting the power to the controller brings it back to yellow LED (normal state) but communication does still not work.
I tried to set a correct baud rate with setserial, but had no luck. This works: setserial /dev/ttyS0 baud_base 115200
The above command sets the baud rate to the standard baud rate as I understood it, the one that is set at startup too. It does actually work to set it but the servo controller gives no reaction. It stays on yellow LED. This does not work: setserial /dev/ttyS0 baud_base 4700
(it returns: “Cannot set serial info: Invalid argument”) Isn’t 4700 the baud rate I should use?
This command: setserial /dev/ttyS0 returns:
/dev/ttyS0, UART: 16550A, Port: 0x03f8, IRQ: 4
When using this command: setserial /dev/ttyS0 auto_irq skip_test autoconfig, the LED red turns on and the first green LED starts blinking, same as when starting up the computer with the attached controller. I got this command from here: http://www.oreilly.de/german/freebooks/linag2/netz0405.htm. I can imagine that the system startup does the same thing as this.
By the way: The tutorial (sourcecode) from http://gpsbots.com/tutorials/tut_pololu.php compiles with no errors. I can execute the application with SetServo(0, 45); in main routine but the controller and attached servos show no reaction (also no LED flashing). I also tried other servo numbers but no luck
Hello,
I don’t think that setserial is a program you should be using. I’ve never used it before, and according to the man page, it’s designed to configure the way linux communicates with your serial port hardware - it does not set the parameters of the actual serial communication, like baud rate and stop bits, and it does not send data to the serial port. In particular, baud_base is not the same thing as baud rate. Also, I’m not sure where you got the idea that you should be using 4700 baud - as far as I know, that is not a baud rate that most computers can generate. Did you want 4800?
The program that is used to set all of the parameters of serial communication is called “stty”.
The GPSBots example looks like it might work, but it is misleading in some ways. For example, the lines
have no effect, since the serial port and baud rate are selected in io.cpp. Also, there seems to be an extra byte being sent (out[5]) that will probably cause an error. Any idea what that is for?
If you are not seeing the top green LED flicker briefly when you run the program, then you are not successfully sending serial data to the serial port that the servo controller is connected to. You could try simply doing “echo hello > /dev/ttyS0” to see if you can trigger any response from the servo controller. If that doesn’t cause any lights to flicker, make sure you have the right serial port number! COM1 on windows corresponds to /dev/ttyS0 - if you are using a different port, you’ll need to specify it. Which Windows demo application were you using to test it?
Hi Paul,
Thanks a lot for your fast answer! I made some testing…
Like I mentioned before: When I turn my computer on with the controller connected and powered, during bootup the green LED begins to blink and red LED gets constantly on. When connecting the controller after complete boot process, only yellow LED is on as should be…
Like mentioned before: setserial /dev/ttyS0 auto_irq skip_test autoconfig does the same thing to LEDs as connecting it at boot time, so probably the same thing is done at boot up. This is also a evidence that ttyS0 is correct.
echo “hello” > /dev/ttyS0 makes the yellow LED shine and the red LED blink, after the first green LED flickers. Means again that /dev/ttyS0 is correct which I also used in all testing apps.
Btw: How should I use stty? Are there any parameters I must configure ttyS0 with?
Compile with g++ -o servoctrl pololu.cpp io.cpp. Then ./servoctrl should move first servo. It actually executes without error but the controller doesn’t flicker any lights. I assume that this code uses Pololu-Mode for communication? But actually shouldnt matter as the LEDs don’t even flicker when executing?!
Btw: I can’t use the Linux example from the Pololu Resources section, because my linux has no graphical user interface.
The example application I used on Windows (on my laptop) is pololu_controller.exe, found here: http://gpsbots.com/tutorials/vb/pololu_controller.php. Works good…
Fantastic!
I got the Pololu code working on my Linux machine. Even tough my C skills are bad, I got it to work with a bit of luck! Created a file servoctrl.c which can access ssc.c without graphical user interface.
If anyone is interested in the code: http://webser125.lookass.ch/temp/pololu/servoctrl_code/
Compile with: gcc -o servoctrl ssc.c servoctrl.c
Run it with: ./servoctrl
This will move the servos #0 and #15 on controller #0 with pauses of 2 seconds inbetween.
(also made slight change to sssc.c, I think I changed ttyS1 to ttyS0)
An important thing I found out: Communication with the serial port only works as the root user.
Now I need to find out if I can also use a motor control unit from the rc world with my servo controller, just as I would plug into a rc receiver:
I’m glad you got it working! Do you have an idea of what the problem was, or was it just that the Pololu code worked and the GPSbots didn’t?
Anyway, you (obviously, now) won’t need to use stty. That would be something to use if you wanted to access the serial port from a programming language that didn’t have the cfsetispeed() and tcsetattr() functions, for example a shell script.
It’s weird that your computer sends junk over the serial line on boot up, but I guess I don’t know how common that is. Can you figure out at what stage of the boot process that happens? Are you building a mobile robot where boot-up errors will be a problem?
The problem is, that the GPSBots Code doesn’t work at all. I don’t even get flashing LEDs on the controller - even tough I set the same ttys port.
Currently, I’m not building a robot but using the controller for some random testing and joking-around things, basically for fun
The server it is connected to does not have a monitor so I can’t see at what stage it fails. But it is during Linux (SUSE 9.3) boot-up - it is not during POST or BIOS things. If you want, I can check what the system exactly does when it sends some message to the controller - I’d have to move a monitor and look at this closer… just tell me. But I’m pretty sure it does about this: “setserial /dev/ttyS0 auto_irq skip_test autoconfig”, as this does the same thing. Also, if I launch hardware manager to see system details, it sends the same random junk.
A last question: Does the controller work with a r/c motor control unit (see previously posted image) as normal as with a servo, just as I would also plug both of these in a r/c receiver?
And a concern: If I wanted to power-on the controller and it’s servos 24/7 for non-robotic but industrial use, would the servos be damaged? I’ve seen that in some positions (for low-cost servos even in position “0”) they’re working (making sound) inside while not moving - and they get hot (specially low-cost hitec servo gets very hot when plugged in long - even when not sending moving-commands).
Our servo controllers should work well with RC speed controls. For your servo question, 0 is not the middle position, and if you send servos to their extremes, they can hit mechanical stops and even destroy themselves. A safer position to send them to is around the middle of the range, and the best option is to turn the servos “off” using the extra features available through the Pololu protocol.
Under Ubuntu, setserial isn’t even installed by default, so hopefully that problem is SUSE-specific. Have you looked through the startup files for a setserial command?
I have checked these files and found nothing… But what comes into my mind is, that setserial was not installed on the system by default. So it might be another thing. Maybe hotplug daemon or something similar. I’ll check and hopefully find out.
I’ve made some testing on my system…
The Servo Controller turns on yellow LED when I press the power button on my system (good so far). Only two seconds after I hit return on the Grub boot menu to start Linux, the red LED gets on constantly and the outer green LED starts flashing. At this time, syslogd is not yet started (so there is no log of this time) - and no other daemons too. So it must be something very deep in the kernel as it seems…?
What I do then (because the Servo Controller doesnt work with these LEDs on) is I reconnect power to the Servo Controller, which makes just yellow LED go on so I can use it.
But what’s really funny: When I restart the machine, instead of shutdown / startup, the yellow LED always stays on and I can keep using the controller without reconnecting power to it. Strange…!
Anyway: Does red LED (constant on) and outer green LED (blinking) mean, that the Controller has a wrong baud rate? Shouldn’t there be a command (setserial or stty) which I can use to remove this state and bring the controller to a normal state? I think that would be far easier than debug my Kernel and look what exactly sends stuff on serial line… A solution would be cool, reconnecting power to the controller can be boring…
Yes, the error state you’re describing is because the controller thinks it got too fast of a baud rate. It’s a permanent fatal error on the servo controller that can only be recovered from by a hardware reset. On our newer 8-servo controller, it’s easy to connect one of the serial port handshaking lines to the reset line so that the PC can reset the servo controller; you might want to do a similar thing with your servo controller. You would need to add a level converter, which can be accomplished by two resistors and a transistor (the same circuit as is on the serial receive line).
It sounds like something pretty deep in your kernel is accessing the serial port. What kind of computer are you using? Since you don’t have a monitor attached, is it possible that you have a serial console configured? Can you look around in your /etc/inittab or /boot/grub/menu.lst for anything like this? Have you tried a second serial port? The easiest solution might actually be going through a USB-serial adapter, which would let you keep the serial port turned off until the usbserial module is loaded.
Other than that, I’d look into making the serial support a module and loading it manually after booting, which could give you more control over what’s going on.
-Paul
What really freaks me out, is that a restart of the PC does actually not mess the controller up at boot after the grub menu. Point is, that the controller stays on the green LED instead of changing to the yellow.
I think soldering some additional reset lines is not what I’m going to do. I want to keep the controller as is.
Unfortunately, I’m not very good in kernel compiling or editing/changing modules, I also don’t know about serial consoles. I’ll probably look into the kernel module loading thing soon, when I have time and find a good walkthrough guide.
# what to do when power fails/returns
pf::powerwait:/etc/init.d/powerfail start
pn::powerfailnow:/etc/init.d/powerfail now
#pn::powerfail:/etc/init.d/powerfail now
po::powerokwait:/etc/init.d/powerfail stop
# for ARGO UPS
sh:12345:powerfail:/sbin/shutdown -h now THE POWER IS FAILING
into this part:
# what to do when power fails/returns
#pf::powerwait:/etc/init.d/powerfail start
#pn::powerfailnow:/etc/init.d/powerfail now
#pn::powerfail:/etc/init.d/powerfail now
#po::powerokwait:/etc/init.d/powerfail stop
# for ARGO UPS
#sh:12345:powerfail:/sbin/shutdown -h now THE POWER IS FAILING
These changes didn’t make a difference, same thing. You can see into “/etc/init.d/powerfail” script here: http://webser125.lookass.ch/temp/pololu/powerfail
It does something with /dev/console but I don’t know exactly what it does…
Another interesting file is “/var/log/boot.msg” because it contains information that /var/log/messages doesn’t: http://webser125.lookass.ch/temp/pololu/boot.msg
Found this in it:
<6>Serial: 8250/16550 driver $Revision: 1.90 $ 48 ports, IRQ sharing enabled
<4>ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
<4>ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
<4>ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
<4>ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
That’s probably the time when it messes the controller up. But I don’t know what exactly is done there.
My system only has one serial port, no additional ports on the motherboard… It’s a Shuttle Mainboard with an AMD2400 cpu (all low-cost). System is SUSE Linux 9.3 professional.
Also checked the BIOS but didn’t find anything of interest…
I’ll stay on this and make further tests - maybe one of you got an idea if you quickly look over the files linked here - would be cool. Thanks.
I’m having the same problem with my controller. I run Ubuntu 9.10 on a computer in a sealed box. It is a big pain to unplug and replug the servo controller every time I boot the computer. The problem did not occur for older versions of Linux that I used in the past.
When the computer boots, I get the normal sequence of LEDs as the power turns on. During the boot process the red LED comes on and stays on. I would really like to fix this problem. Does anyone have any ideas?
I have the same ideas that we came up with before - connect a handshaking line to the reset on the board; look for a program that could be accessing the serial port; try loading serial support as a module after boot; use a second serial port; use a USB-serial adapter. Did you consider all of these already? What servo controller do you have?
I could potentially use the serial interface with an adapter but redoing the cables would take a lot of work. I’m using the 16 servo controller. This problem only appeared when I upgraded the computer from an old version of 8.04 to Ubuntu 9.10. So at the moment I am hoping for a software fix. It seems to be something with how the serial device is autodetected and mounted as a device.
Thanks
Even if you cannot find a software fix, you still have the option of using a handshaking line to reset the device. Good luck, and please let us know if you need help or figure it out!
Created a file 
