THE TYPE B ASSIGNMENT
A type B assignment is of any form you want it to be, provided that I agree to it. You choose it, design it, and execute it under your own initiative. You can undertake type B assignments in groups of one, two, or three. Groups of one are distinguished as LONERS; henceforth, GROUP refers to groups of more than one. Because of the limited amount of equipment at our disposal, you might have to share with other students or groups. I introduced ( strictly reintroduced ) group assignments in 1992 by popular demand, and they work well if you're determined to make them work, but they haven't been as good as anyone expected. That's mainly because few groups have really got down to the planning and organisation that's necessary to define and coordinate the group members' contributions.
First decide how you're going to do the assignment - prepare to go it alone or join a group. Then choose an assignment. This includes both choosing a device or topic to work on, and determining just what you intend to do with it. The most useful piece of advice is : DON'T be overambitious when selecting your topic; a limited proposal executed excellently is better than a grandiose plan left uncompleted. It's also easier to write up in your report. Choose something simple; decide just what you want to do; design your experiments carefully; then do the experiments. Then if you have some spare time, extend – or, better, deepen – what you've done.
To help you in your choice, you can inspect a list of delightful assignment opportunities, where I have provided some suggestions for topics. You might also like to refer to a list of available equipment.
You are not restricted to the topics or equipment in the lists. You might have some pet project you would like to pursue, or something you noticed while perusing the report you reviewed for your type A assignment or while preparing for your seminar might have given you some ideas. Provided that your proposal is feasible in principle, that the equipment needed is available, and that the topic has some discernible connection with real-time control or robotics, it might do. Ask me.
My choice of topics isn't random. Apart from the obvious need to stick to the machinery we have, I've only listed topics which ( for loners ) give some chance to achieve something in a rather short time, or ( for groups ) seem to me to be organisable as several complementary parallel activities. Each of the suggestions comes decorated with more or less material in the way of comment, information, queries, and other items, all intended to alert you to various aspects of the topic. They are not intended as instructions, but to help you to get to grips with the topic as quickly as possible in the very limited time available. It is your job to decide just what to do, and how much of it to do. There's no compelling reason why you should keep all the bits and pieces separate - for example, you might make the robot put an object somewhere, then get the turtle to push it around. ( That might be a two-person assignment. ) You do not need to find something totally original to do, though a mildly new slant is nice; I'll be happy provided that you can't just copy some earlier report and expect to get credit for it.
A WARNING, FROM EXPERIENCE, ABOUT ELECTRONICS : If you want to build some electronic circuitry, and you're not experienced in electronic construction, don't. This is not a good opportunity to find out about it. If you REALLY want to try, well, all right, then, but it's at your own risk, and you must be prepared to read it up and ask for help when you need it. As we're not an electronics department, that might mean search for help when you need it.
In many cases, there is some documentation in the form of reports from previous assignments, articles from hobby magazines, manufacturers' blurbs, literature references, or whatever; most of the collection is listed in the 773 LIBRARY CATALOGUE. A lot of this material ( all the old 473 assignment reports, and a few other oddments ) lurks in box files which normally live in the 773 laboratory. You are welcome to borrow any bit you like, but put it back. And in the right file. PLEASE DON'T LOSE IT : it might not be immortal literature, and even the first editions of the reports aren't likely to be in great demand, but the collection is very useful. Be warned that the quality of the assignment reports is unpredictable, so you should not necessarily believe all you read. Also, the excerpts from hobby magazines are not always totally reliable; they shouldn't do you any harm, but use them as sources of ideas rather than absolute truth, and always read them critically.
If many ( say, > 10 ) people enrol for the course, pressure of numbers forces us to do more in the way of simulators and other work which doesn't involve anything mechanical. Simulators have their place, but they can never capture the feel of the real thing. For one thing, they are too precise; real machinery isn't precise or completely reproducible, and it wears and breaks down. For another thing, software is too forgiving. A real machine forces you to obey the laws of the universe we inhabit, but with software you can get away with quite bizarre views of the universe which are quite unacceptable in studies supposed to be related to the real world.
Bear in mind when choosing your assignment that you set your own standard. When I assess an assignment ( see below ), I assess what's there. I want it to be a thorough treatment of something or other; so if you've chosen a big topic and don't have time to complete a thorough treatment, I'll moan. ( Well, no, I won't; regard it as a technical term for giving you fewer marks. ) I'll also moan if I think you've missed a bit which should have been there – so don't leave loose ends, always make connections to topics which appear in the course, and so on. That's easier if your aim is comparatively modest. Of course, if it's too modest, I'll moan about that - each report has to look like three-eighths of the practical requirement for a two-point graduate course.
Notice that the intention is to learn, not just to have a jolly time driving trains or whatever. I hope you do enjoy the trains or whatever, but remember the ulterior motive. You won't learn much at all if you don't work at it a bit. Please analyse your experience, and see how it fits in with the topics we discuss in the lectures and seminars. Obviously enough, the assignments you will do are on a very small scale by industrial standards, so the behaviour you observe is usually a simplified version of what you'd find in a factory. Nevertheless, the same principles apply, and it is enlightening to see how your observations reflect on the more general field. I therefore expect you to spend a little time in the library reading about related "real" topics. Textbooks or review articles are probably more appropriate than journals and research; try the engineering library.
This timetable is NOT A JOKE. In the old days, 473ers sometimes took it that way, and often got away with it, but I can no longer afford such luxuries. Marking a 473 assignment took me several hours, and occasionally days, and I don't expect 773 assignments to be much different. Now we've changed to semesters, there's not nearly as much spare time after the end of lectures with semesters as there used to be, and I have to fit the marking in there somewhere.
I've taken the view that, though the details are different, every assignment has four stages :
GROUPS : Aim for something which falls fairly naturally into a separate job for each member of your group, with as few interactions as you can manage. Make sure that all of you understand what's involved, and that all your understandings agree.
GROUP : Decide who's doing what and when. CAREFULLY design interfaces between your several areas of responsibility : record them so that any parts which need to communicate can be constructed separately. Develop contingency plans in case something turns out to be harder than you expect. ( What will you do if one of you gets stuck on an important component ? ) If you can, arrange for a halfway stage to assess how things are going, and particularly whether you're all keeping in step - and also as an approximation to a completed job in case the last part turns out to be hard. Check each of your jobs, make sure that you can do it in the time available. If you can't, you might have to revise the specification.
GROUPS : Watch everyone's progress, make sure that everyone is running level, more or less. Switch jobs between people if you need to – and discuss why you had to in your report. Note the remarks above about a halfway stage; two one-week tasks each gives you more flexibility that a single two-week task each.
GROUPS : Make sure that your individual reports fit together properly; combine together to write a plausible introduction and conclusion.
I emphasise that you needn't stick to that pattern if you prefer some other approach, but I think it contains some sensible ideas that you should take into account whatever you are doing.
I've already mentioned the report; here's some more detail. In general, the report should contain whatever is needed to show that you have performed the assignment, that you understand what you did, why you did it, what you found when you did it, and what it means. An effective, though not mandatory, form is to present the material in three main sections :
Bear in mind that a major function of the report is to impress me, and anyone else who might read it ( you'd be surprised ), with your high intelligence and deep understanding of the topic. A sequence of statements to the effect "I did this - then I did this - then I did this …" isn't too effective. It's much better to do fewer things, but to take care to explain clearly why you did them and what the consequences meant. Take care with software ( or hardware, of course ) design, and show off its merits. Comment on programming techniques, and comment on the usefulness of the programming language. Ask what sort of system you've produced : is it hard or soft real-time ? What are the timing constraints ? Are you sure they can be met ? The SORT OF CHECKLIST tabulates a set of words which might or might not be relevant to your work.
It is often a good idea first to give a fairly high level description of what happens, then to fill in the details of how it's done. It's much easier to understand a description of code, machinery, or electronics if you know what it's supposed to do.
Don't include lots of extraneous material. It's sensible to give a ( brief ) general description of the machinery or whatever, but you don't need to mention the possible applications to astrophysics unless they're relevant to what you say in the body of the report, or you need them in the discussion part. And contrariwise : if you do mention astrophysics, be sure to point out where it's relevant in the later description, unless it's very obvious. It's nice to know that you've heard of astrophysics ( particularly if you can spell it correctly ); it's even nicer to discover that you know why it's useful and what it can do. ( NOTE : for "astrophysics", read any pet topic you have in mind. ) DO include comments relating your experimental work to other control topics – "This is an example of hierarchic control"; "this part of the system functions as a real-time executive", etc. – and give references if you can. This tells me whether you've been awake during the lectures.
If you give explanations for things ( which you will almost certainly do somewhere ), make sure that they make sense. Do not guess : it's sometimes obvious. If you can't offer an explanation of your own, find a reference, or make it clear that you've made an assumption.
Assess your work critically. If your original bright idea turned out to be a miserable flop, say so - but explain why it was a flop, and why your original expectations were mistaken. As ( if ? ) you learn more about computer control in the course, apply your knowledge as far as possible to the assignments, and include any conclusions in your report. You might also try reading the textbooks.
Finally, it's a good idea to suggest some further work which could usefully be done. That isn't an invitation to let your imagination run wild : stay within the bounds of practicality. Anything you suggest should lead on in a sensible way from something you have described in the report - perhaps an extension to some new application, or a way of solving a problem which you have characterised.
As always, material acquired from other sources ( books, reports, etc. ) should be properly acknowledged. Notice that this includes your own previous reports, if your assignments are linked together. As with any other source, if you use material from them, summarise the useful stuff and give the reference. Do not assume that it's immediately available to the reader. If you use references, refer to them. That's what they're for. Anyone can produce a set of plausible titles and stick them at the end of the report; that isn't impressive. It is impressive if you use other publications well, as sources of information you need in your account of your work. It's also educational. Also, do write your list of references effectively, so that someone else could look up the material if it's needed. See the checklist for recommended forms.
If ( as is usually the case ) you have written code as a part of your assignment, it is helpful to have it available for reference if required. Append a listing to your report. I'm unlikely to pore over it, so provided that it's just about legible it will do. With a laserprinter, you can get away with seven-point type – perhaps even six-point if you can find a very clear typeface. With a bit of judicious editing, you can get three columns on an A4 sheet.
Three practical points :
Ugh.
It is my job to produce a set of marks which fairly represents your achievements. It is, of course, impossible : you are all doing different things, so there isn't even any sound way of getting a reliable ranking. I try to determine from your reports how well you can apply the course material to whatever it is you're trying to do. I try to assess the reports in such a way that the results are more or less independent of the subject matter; that means that I concentrate on the treatment rather than on the detail of the machinery.
You might find a representation of my marking sheet of interest. It's from 1995, and there might be some changes, but it gives a general idea of factors I take into account. There's a sort of description of how it works too.
If you've looked at the marking sheet, you will doubtless have noticed that there is nothing very specific in the list of topics for marking. Each item is general, and I've already said that I will leave out any that isn't appropriate in an individual case. While I can't think of any other way to approach the job of marking many reports on widely different topics, it does raise obvious problems in producing a list of comparative marks. How can I compare such different raw material ?
I can't. I don't even try very hard. What I do try ( and that's why marking takes me such a long time ) is to pick out something which is rather less obvious, but which I can compare. ( No, not spelling and grammar ! ) What I try to assess is the quality of the arguments and discussions which you present. I want you to show me how you can address a problem, analyse it into components, critically assess different methods of solution, decide on a method to try, interpret what happened when you tried it, and so on. In short, I want to see evidence of graduate brains in action. The subject happens to be real-time control, but really that's a detail - the point of university study is ( I assert ) to develop your powers of analysis and clear thinking, and at the graduate level you should be showing them.
I can't ignore the subject matter entirely. The topic is supposed to be the material implied by the course title, which is reasonable enough. I make that point explicitly because people have tried giving me reports on topics such as ( not a real example ) user interface design which have been quite good reports, but which haven't said anything specific about control systems or robots. It's your responsibility to make the link; if you don't, then, however good the argument, I can't give you many 773 marks for it.
Therefore, supposing that your reports are about work you've done in the general area of robotics and real-time control :
In terms of marks :
Finally, if you feel I've been unduly harsh ( or unduly generous ) in marking, I'm always ready to negotiate. Come and talk about it.
Alan Creak,
March, 1998.