# Building an electronic motor simulator

### Some design and programming tips

1. For a processor with no floating point unit like dsPIC, it is sometimes advantageous to use integer arithmetic, especially when timing constraint is stringent and fine precision is not very important. The units in the program may look stange to you because I simply multiply angle degrees by 100 and use integer computation. Notice the lines that compute motor angle increment in the main loop.
minctmp = (unsigned int)3.6*speedcmd; // motor angle increment if (minctmp==0) minctmp=1; // avoid divide by 0 enloop = (unsigned int)encstep/minctmp;

The variable minctmp is of type unsigned int. So at small speed command, the computed minctmp becomes zero, and the computation of enloop causes a divide-by-zero exception. I fix it by inserting the middle line; i.e., to assign a minimal value of 1 to minctmp when it should be zero. (That’s why you can never stop the LEDs rotation completely without feedback. Indeed, this ad-hoc solution makes our emotor resemble the actual motor closely. It is normal for the open-loop case to have small offset that makes the motor drifts slowly at zero command. Our integer arithmetic doesn’t hurt.

2. In a multithread system, we must take into account the well-known read-modify-write issue.TSR1 is exceuted periodically with a high sampling rate and has higher priority than the main loop (CPU priority), while the global variablesminc and encnloop are updated by the main loop. Therefore, the write process must be atomic. There are a couple of ways to do this. The easiest one is to temporarily set the CPU priority to maximum (7) to prevent interrupts, and reset it after writing finishes.
SET_CPU_IPL(7); minc = minctmp; encnloop = enloop; SET_CPU_IPL(0);

This critical section must be done as fast as possible; i.e, just update the variables. Any computation must be done outside. Otherwise, it might affect overall performance since all other threads are blocked.

### Suggestion to improve the emotor

1. Implement two-stage torque disturbance. When a user presses SW1, the speed command is reduced to 0.6 of its present value. After he/she presses it for some period, say, 3 seconds, the disturbance gets stronger; i.e., the speed is reduced further to 0.3 of the original command.
2. Add some user-adjustable delay to the motor by using another VR or jumpers.

### Control lab setup examples

Below are some ideas to experiment with the emotor. We recommend that some communication function be added to collect data for analysis, such as step responses, etc.

1. Implenent a closed-loop velocity control by connecting the emotor to another processor that runs PID algorithm. Adjust PID gains such that speed is regulated at some velocity around half of the maixmum value (The LEDs revolves about 5 cycles/sec.) Push switch SW1 to apply torque disturbance. The emotor must remain at the same speed.
2. Implement a closed-loop position control that commands the emotor to stop at a setpoint.
3. Apply system indentification techniques, such as Least-Square estimation, to achive experimental models of the emotor. Justify the models.
4. Use the experimental models achived from above procedure to design a more advanced controllers by your preferred methods: loop-shaping, QFT, LQG/LTR, $H_\infty$