Rotor controller
From EWiki
Contents |
Introduction
W2SZ has a bunch of antennae up the hill from the shack that need to be remotely rotated. We intend to build a piece of equipment that lives up the hill by the rotors and is connected back to the shack via ethernet. We then run a server in the shack that communicates with the rotor controller up the hill to control the rotors. Currently the rotors have relative positioning, meaning we don't really know where they're aimed. We'd like to move to a system in which we use absolute positioning, so we can quickly lock in on directions and come back to them later.
The controller itself is based on a Silicon Labs C8051F120TB board hooked up to an AB4 Ethernet board as well as a custom rotor controller board. The custom board has a set of 8 relays to control 4 motors in both directions. The rotor controllers also have potentiometers for position feedback, and these are connected to A/D inputs on the CPU.
controller software
The rotor controller itself has a pretty simple job: keep track of where each rotor should be and keep it there. We're working with relays here, so we don't exactly have smooth control, but it should be sufficient. When a packet comes in from the server, it will cause an update to the position value. This will cause a corresponding response in the control routine to bring the rotor back to where it should be.
The TCP/IP stack provided by Silicon Labs has main() calling a server function that takes control until the board shuts down. This routine has a couple of callbacks relevant to us. First, it will callback whenever a packet comes in so we can service it. Second, there is an idle callback to do processing when the server isn't busy. Now, one implementation of the software would put the control loops inside of the idle routine, so whenever the server isn't busy we're updating the rotors, but that isn't a real-time approach. The server could get overloaded with requests and not keep up the updating of the rotors. A better approach would be to set up a timer interrupt and put the control loops inside of the ISR. That way we know for sure how often the rotors are being updated and we can trust we don't overshoot.
control algorithm
The output of the control loop is two relays, one for forward and one for backward. The input is a potentiometer, which will give us an analog voltage input. The simplest algorithm would be to simply go forward when the potentiometer is below the target and backward when it's above with a deadband around the target. This will probably be suboptimal due to a good deal of overshoot. It depends on how quickly the rotors move. Since this is the simplest algorithm, it should probably be what we try first.
Random notes
Ports used by the AB4 Ethernet board: 0, 2, 4, 6, 7
Ports we can use: 1, 3, 5
Communcation protocol
Commands sent to the controller are two 16 bit shorts: first the channel, then the command.
0-360 sets the heading to that value, 400 stops the rotor on that channel, and 500 gets the current status
if the controller gets a 500, it sends back 3 shorts: channel #, heading, and status. status is 0 for stopped, 1 for moving CW and 2 for moving CCW
Status
9-Feb-2008: Got ethernet working happily on board and wrote a program to read analog values. See c:\dev\eth_vanilla and c:\dev\analog on VHF ops computer. Somehow I borked c:\dv\analog_ethernet, so it fails to boot up the ethernet stack. The voltage regulator on the board doesn't like the 12V supply I'm using, and eventually goes into thermal shutdown, screwing things up. Need to fix that, either by wiring in my own 3.3V supply or powering the ethernet & JTAG boards separately.
