Due Dates and Times:       (See the Course Calendar.)

Summary:

You are to write a program to control the gizmo. It will be developed incrementally. The assignment is divided into the following three tasks, each of which task may be further divided into incremental stages:

1. Measure the natural harmonic frequency of the gizmo's blade, by periodically polling the sensors.
2. Make the gizmo swing back and forth smoothly, according to its natural harmonic period, by periodically activating the solenoid.
3. Make the gizmo display a text message, by turning on and off the LEDs while keeping the blade swinging back and forth smoothly.

You will be asked to demonstrate your progress at the end of each task.

• Apply your knowledge of Linux, clocks, and periodic tasks to the control of a real device.
• Experience first-hand the effects of failure to meet a hard timing requirement

1. Write a program to measure the natural period of your gizmo. The program should use a periodic task to poll the values of the two sensors. It should poll them frequently enough to get an accurate measurement. You can start from the state model described in class. If the state-machine model is not reliable enough to consistently determine a fixed point in each cycle, modify it.

   When you have completed this stage, send an e-mail to me containing a message with the period you measured, in millseconds, with the source code of your test program attached.

2. Write a new program, using the information gained in the previous step, to make the gizmo swing back and forth smoothly, according to its natural harmonic period.

   When you have completed this stage, arrange a meeting with me to demonstrate it, and give me a printed copy of your code at the same time, so that I can observe the motion and look at the code during our meeting.

3. Extend the program developed in Stage 2, by adding to it the capability of using the LEDs to display a text string. Ideally, the module should support long strings by scrolling the text, and should support modification of the text string at run time.

   When you have completed this stage, arrange a meeting with me to demonstrate it, and give me a printed copy of your code at the same time, so that I can observe the motion and look at the code during our meeting. Then, send me by e-mail the entire code in digital form.

1. Start by reading all of the notes on gizmos, including the advice there.

2. Apply the incremental and evolutionary development approach. Start with a simple solution, and add features on to an already working kernel module. Here are some suggestions:

   • Stage 1:
     • Write a task to poll the sensors, either continually or periodically, to measure the time between major state changes. Start with the examples of code given in class, which show how to read the sensors.
     • Initially, use your hand move the blade.
     • If you are able, see if you can use the solenoid to "pulse" the blade once, enough to get it moving
   • Stage 2:
     • Start with the example of a periodic task given by the link at the end of the class notes on the software provided for this assignment, which should be able to be compiled and run, or a chopped-down subset of it.
     • Ideally, your software should use the sensors to keep track of the blade position and include a feedback loop to keep the pulling of the solenoid in phase with the motion of the blade. However, to get a modestly working solution you can measure the blade period and drive it using a hard-coded periodic loop.
     • You will need to figure out when, within each cycle of the blade, to turn the solenoid on, and how long to leave it on. Determine this by a combination of reasoning (for initial guesses) and experimentation (for fine tuning). Apply the bisection method to zero in on values that work well.
     • When you are ready to work on the feedback method of controlling the time of pulling, initially skip over the problem of starting the blade moving. The logic and timing needed to start the blade will be different from that needed to keep it moving. For a first generation solution you can use your hand to get the blade started swinging. Then all you need to do is keep it moving.
     • You can add code to make the system self-starting once you have figured out how to keep a hand-started system moving.
   • Stage 3:
     • Start by displaying a single character or pattern, say a pattern of alternative vertical bars (| | | | |). Work on controlling the timing so that the image appears stable (no drifting, and as jitter as possible).
     • Start by dividing time equally and only display characters near the middle of the blade's motion, to avoid the bunching problem (see more detail in the note on nonlinearity below). Later, if you have time, you can try dividing time unequally so as to extend the range of the display.
     • Add in a bit-mapped font (via a table) and convert it to display a text string.
     • Add in a way to dynamically change the text string, e.g., via an RTLinux FIFO.
     • Add in the scrolling feature.

3. Design your solution before coding it. Do a preliminary design of the whole system before you start coding Stage 1. Revise the design as you learn more.

4. There are several timing parameter what you will want to be able to tune easily. This tuning will be much easier, and your program will be simpler to read and debug, if you make good use of tables (arrays of numbers) rather than complex control structures (switches, nested if-statements).

5. Keep in mind that you have the following timing constraints:

   1. Polling the sensors, periodically, to keep track of the blade position.
   2. Turning on the solenoid, periodically, to keep the blade moving
   3. Turning off the solenoid, some time after you turn it on.

   Though these are conceptually different tasks, each with their own timing constraints, for this first assignment you should try to implement all of them in a single periodic task (a "cyclic executive"), which polls the sensors and then optionally turns the solenoid on or off. Later, you will be asked to re-program this assignment using multiple threads.

6. You will need a bit-mapped font to generate your images. You are only required to support the 26 letters of the Roman alphabet, and only required to support one version of each letter (no need for upper or lower case). Of course, supporting a larger set of characters is better. Since you have 8 vertical pixels to work with, you could use the 8-pixel font from the X-windows "clean" family. I don't want you to spend a lot of time on the font. The following was used by one student in a prior term. If you are satisfied with it, you may use it.

   unsigned char letters[27][7] = {
    /* a */ {63, 72, 136, 136, 72, 63, 0},     
    /* b */ {255, 145, 145, 145, 106, 4, 0},   
    /* c */ {60, 66, 129, 129, 66, 102, 0},    
    /* d */ {255, 129, 129, 66, 102, 60, 0},   
    /* e */ {255, 145, 145, 145, 145, 145, 0}, 
    /* f */ {255, 144, 144, 144, 144, 144, 0}, 
    /* g */ {126, 129, 129, 137, 137, 142, 0}, 
    /* h */ {255, 16, 16, 16, 16, 255, 0},
    /* i */ {129, 129, 255, 129, 129, 129, 0},
    /* j */ {129, 129, 129, 255, 128, 128, 0},
    /* k */ {255, 0, 8, 36, 66, 129, 0},
    /* l */ {255, 1, 1, 1, 1, 1, 0},
    /* m */ {255, 64, 32, 32, 64, 255, 0},
    /* n */ {255, 64, 32, 16, 8, 255, 0},
    /* o */ {126, 129, 129, 129, 129, 126, 0},
    /* p */ {255, 144, 144, 144, 144, 96, 0},
    /* q */ {126, 129, 129, 133, 130, 125, 0},
    /* r */ {255, 144, 152, 148, 146, 97, 0},
    /* s */ {96, 145, 145, 145, 145, 142, 0},
    /* t */ {128, 128, 255, 128, 128, 128, 0},
    /* u */ {254, 1, 1, 1 , 1, 254, 0},
    /* v */ {252, 2, 1, 1, 2, 252, 0},
    /* w */ {255, 2, 4, 4, 2, 255, 0},
    /* x */ {195, 36, 24, 24, 36, 195, 0},
    /* y */ {192, 32, 31, 16, 32, 192, 0},
    /* z */ {131, 133, 137, 145, 161, 193, 0}
   };
   

   If you find a better font, and are wiling to share it with the class, please let me know.

• Basic notes on Gizmos
• Class notes on the Gizmo I/O driver and programming periodic tasks in Linux, including links to example programs and files.
• Assembly code provided by the DAQ vendor
  I used this code, provided by the DAQ vendor, as a starting point for the code for the Linux I/O driver code I wrote. I've provided it to you in case you are curious, but there is no real need for you to read it.

Delivery Method:

1. On the due date, arrange with me a time that you will demonstrate your working software.
2. At the demonstration, provide to me a hard copy of your software, including enough internal documentation for me to read it and make sense of it. The documentation must include at least a high level description of your design, including the number of tasks, each task's scheduling requirements, and each task's functional responsibilities.
3. By e-mail, turn in an electronic copy of your work. In the subject line of the e-mail, mention the assignment number.

Assessment:

The solutions will be judged primarily on how well they perform, including both the quality of the blade motion (smooth, regular) and the robustness of the algorithm used. In particular:

1. A solution that makes effective use of feedback control will receive a higher score than one that uses open-loop control.
2. A solution that provides a way to dynamically determine the blade period to fit the hardware device will receive a higher score than one that relies on a hard-coded or manually input period value.
3. A solution that does not require hand starting will receive a higher score than one that needs to be started by hand.
4. A solution that moves smoothly over a moderately large arc of stable width will receive a higher score than one that moves irregularly, moves over a small ark, or moves in such a wide arc that there is risk of damage to the device.
5. A solution that works on other gizmos than the one you are using (e.g., one with a different type of blade and a slightly different harmonic period) will receive a higher score.
6. A solution that can display more characters, making more effective use of the full arc of blade travel, will receive a higher score.
7. A solution that avoids bunching and stretching will receive a higher score.
8. A solution that allows the text to be modified will receive a higher score.
9. A solution that supports scrolling will receive a higher score.

Because of the cumulative nature of the project, if the overall score on the final delivery of this project (motion and image) is higher than that on the prior partial delivery, that score will stand for the entire project. If the score is lower, the average of the two scores will be used as the project score.