Why enable_servos() and disable_servos() should not be used on the CBCv2

NOTE: This article probably does not apply to the new Link controller.

Older KIPR documentation states that enable_servos() is used to turn on the CBC's servo controller, and disable_servos() is used to turn it off. This has been outdated since the CBCv2 came out in 2010, and I do not recommend this anymore for the CBCv2.

First, let's look at why enabling/disabling servos was necessary. Servos draw a huge amount of power, and will quickly run down a CBC battery if left on for extended periods of time. Because of this, Botball controllers (going back from the current CBCv2 to the CBCv1, XBC, and Handy Board) have disabled the servos by default, and only enable them when necessary.

The oldest Botball controller which supported servos, the Handy Board, was extremely primitive by today's standards. It had a 2MHz CPU, 32KiB of RAM, and its firmware was programmed in ASM and had to fit in 16KiB of RAM (the other 16KiB was for the user program). The Handy Board firmware was thus extremely crammed for space. The Handy Board's developers decided that the best way to allow the 6 servos to be disabled was with a single Boolean (true/false) flag which enabled/disabled all 6 ports. This flag was set to true/false by IC functions (I don't remember their names, but they were similar in usage to enable_servos and disable_servos). The enabled/disabled flag was independent of the positions of each port, so you could set/get positions independently of whether the port in question was enabled (the servo just wouldn't have power).

The XBC kept this system when it was released in 2005. The functions were renamed to enable_servos() and disable_servos(), but the functionality was similar. I'm not sure why the functionality wasn't enhanced, but I'm aware that the XBC's FPGA hardware was pretty much at full capacity with the XBCCam vision system, so maybe there simply wasn't enough room to add an enhanced servo controller.

When the CBCv2 was under development, KIPR changed the setup. Remember that a single flag had previously affected all the ports. This meant that servos couldn't be independently enabled/disabled; if you had one arm moving, all of your other arms were sucking power. KIPR decided to allow each servo to have its own enabled/disabled state. The simplest implementation of this, without adding new variables, was to have a "special" servo position which meant that the servo was disabled.

So, in the new system, setting a servo position to -1 will turn it off. All servos are set to -1 on boot, and setting a servo to a different value will automatically turn it on. What this means is that servos no longer "remember" their position when turned off; you need to explicitly set it to a new position to turn it back on.

As a result, enable_servos() and disable_servos() are obsolete. To enable a servo, set it to a position. To disable the servo, set it to -1. This will ensure that your servos work as expected.

Thanks for reading!

Comments

Does this still apply to the

Does this still apply to the Link?

And by the way, really nice article. I learned a ton about the topic. Thank you for all of the information! YuSheng was right!
(I was recommended to read this by YuSheng.Chen)

Thank you!

EDIT:
This doesn't apply to the Link. Ok thank you!

Terry's picture

Thanks for the overview. I'd

Thanks for the overview. I'd appreciate it if you would review the tutorial on servos
at nasarobotproject.wordpress.com and tell me if you recommend any changes or additions.
All you need do to find the topic is type 'controlling servos' in the search box on the right.

History is a race, between Education and Catastrophe