TableSat Software Upgrades

As was mentioned before, the new flight processor allowed for the TableSat flight code to be written in C code. While this required all of the flight code to be rewritten from scratch, it allowed for much more functionality in the new code.

The flight code, which is discussed in detail in Chapter 3 is split into five main threads which run simultaneously on the processor. The main TableSat thread initializes the TableSat hardware and the other four threads. It then runs in the background, essentially doing nothing, until stopped. The state estimator thread reads the TableSat sensors, converts them to meaningful engineering units, and uses the measurements, as well as a user established state estimator, to estimate the state of the system. It then makes that state estimate available to the controller thread. The controller thread uses the state estimate, along with a user developed controller, to calculate the control authority required to move TableSat such that its state meets a desired value. It then makes the required control authority available to the actuator thread. The actuator thread converts

the desired control authority into the form required by the actuators and sends those commands to the actuators. In the background runs the communications thread. The communications thread conveys information to the user and receives commands from the user and parses them to the correct thread. It allows the user to start and stop TableSat, change the controller, and change the state estimator, for example.

As was mentioned earlier, the new flight processor can send analog com-mands directly to the actuators. The new software takes advantage of this fact by commanding the fans in a continuous fashion, which means the actuators get the exact voltage they request within about ±3 mV, or the resolution of the D/A conversion with voltage regulation. Recall from Chapter 1 that the original Ta-bleSat software used pulse width modulation (PWM), a highly nonlinear process.

When using PWM, the actuators are commanded at their full voltage for a frac-tion of a control cycle. The fracfrac-tion depends on the amount of control desired and the speed of the actuator cycle. For the original TableSat software, there were four actuator cycles per control cycle, which resulted in an actuator resolution of about 3 V. By allowing continuous actuation, the nonlinearity due to using PWM can be eliminated. One of the other goals of the TableSat project was to retain the ability to add nonlinearities back into the system if desired. To that end, the new TableSat software also allows for PWM or Bang-Bang actuation, if desired.

The state estimator, controller, and actuator threads can be executed at any speed up to about 100 Hz, which is the limit of the processor speed. The user can set the cycle speeds, and, the faster the cycles are run, the more TableSat acts as an ideal, continuous system. With its original hardware/software compliment, TableSat’s maximum execution speed was on the order of 2.5 Hz, too slow to be considered a continuous system.

In addition to the continuous actuation and cycle speed variability, there exists within some of the software threads additional functions that can be used to compensate for some of the other nonlinearities in the system. These functions are discussed in detail in Chapter 4. Most notable is the friction compensation function, which accepts as input from the user a desired friction compensation curve. Expressed as voltage per speed, the curve describes the amount of addi-tional voltage to be applied to the calculated controller voltage to compensate for friction in the TableSat system. If the friction compensation curve is correctly identified, this functionality effectively eliminates the nonlinearity due to Table-Sat’s internal friction. If the user wishes to put friction back into the system, the friction compensation can be disabled.

Along with the function to compensate for TableSat friction, the flight code also includes a function that eliminates the dead zone in the actuators.

Each actuator has internal friction, which reduces the effective voltage and thus the effective control authority of the actuator. Because of this internal friction,

there is a voltage below which the actuators will not spin. The actuator dead zone compensation reduces this dead zone from ±2.75 V to ±0.1 V. It does not, however compensate for the internal actuator friction in any other way. So, the nonlinearity is reduced, but not completely eliminated.

Accompanying the new software is a new user interface and TableSat Simulink models with which the user can interact with TableSat. The TableSat GUI and Simulink models are discussed in detail in Chapter 4. The GUI can be used to load different controllers and state estimators, enable/disable friction com-pensation, load new friction compensation curves, and change the cycle speeds, along with other things. In this way, the user can have TableSat act as a lin-ear system, or introduce the nonlinlin-earities back into the system to see how the nonlinearities effect the system response. The TableSat Simulink models allow the user to start and stop control of TableSat and plot the TableSat state real time. In addition, the open-loop Simulink model allows the user to design and implement controllers directly from Simulink, which can allow for more advanced controller and/or estimator design than that which can be implemented using the onboard controller and estimator definitions. Being able to design and implement advanced controllers and state estimators was one of the goals of this project.