ASSEB Class 10 AI & Robotics common mistakes
ASSEB Class 10 AI & Robotics · Understand the traps and how to avoid them.
When asked to classify a system as rule-based, classical machine learning, or deep learning, the candidate labels anything 'AI' as machine learning, or treats a decision-tree classifier as deep learning because it 'learns'.
The syllabus vocabulary (AI, ML, deep learning, rule-based expert system) is taught as a ladder, but candidates memorise the words without a decision rule. Marketing language ('AI-powered') reinforces the idea that AI equals ML, and a decision tree's branching looks like a neural network diagram to a first-time learner.
What to do instead
Before answering, apply a fixed two-question test: (1) Are the decision rules written by a human or learned from data? (2) If learned, does the model learn its own features through many stacked layers, or does it work on human-chosen features? Write the answer to both questions in the margin, then pick the label. Practise on 10 familiar systems (spam filter, chess engine with hand-coded rules, face unlock, thermostat, recommendation feed) and justify each in one sentence.
The candidate describes a training pipeline in the wrong order, for example collecting data, training the model, then cleaning and splitting the data, or evaluating on the same rows used for training.
Textbook diagrams are remembered as a list of nouns rather than a causal sequence, so the order is reconstructed from memory. The consequence of leakage (an unrealistically high accuracy) is not visible unless the candidate has actually run the experiment, so the step feels optional.
What to do instead
Memorise one canonical sequence and recite it before any pipeline question: define the problem and target, collect data, clean and label, split into train/validation/test, train, validate and tune, test once, deploy and monitor. For any scenario, explicitly state which rows the model never sees during training. If a reported accuracy is above 99% on a realistic task, flag leakage as the first hypothesis.
The candidate evaluates a classifier on an imbalanced dataset using accuracy alone, and reports that a model with 97% accuracy on a 3% positive class is 'excellent' without checking recall, precision, or the confusion matrix.
Accuracy is the only metric most beginners can compute by hand, and it is the first one taught. The base-rate trap is counter-intuitive: predicting 'negative' every time scores 97%, so a high number feels like evidence of learning rather than evidence of a lazy model.
What to do instead
For every classification scenario, first write the class balance, then choose the metric from the cost of errors: missed positives (disease, fraud, defect) demand recall; false alarms are costly demand precision; a balance needs F1. Always sketch the 2x2 confusion matrix and fill in the all-negative baseline before judging any number. State explicitly what the 97% model does on a positive case.
The candidate confuses supervised and unsupervised learning, or calls clustering 'classification', because both group things into categories.
Both tasks produce labels or groups, and the surface description ('the system sorts customers into groups') sounds identical. The distinguishing fact, whether ground-truth labels existed during training, is a single word that is easy to skip when reading quickly.
What to do instead
Ask one question of every scenario: did anyone supply the correct answer for each training example? If yes, supervised (and if the answer is continuous, regression; if categorical, classification). If no labels existed and structure was discovered, unsupervised (clustering, association, dimensionality reduction). If an agent learns from reward signals, reinforcement learning. Write the label source next to the scenario before choosing the algorithm.
When asked to interpret an image-processing or NLP task, the candidate picks a model family by name association rather than by data type, for example proposing an RNN for image classification or a CNN for translating a sentence.
Model names are memorised as a list with vague tags ('CNN is for images' is often the only association retained), and under time pressure the candidate grabs the most familiar term. The structural reason (convolution exploits spatial locality; recurrence or attention handles sequence order) is rarely rehearsed.
What to do instead
Build a two-column mapping and rehearse it: grid-like spatial data with local patterns -> CNN; ordered sequences where context matters -> RNN/LSTM or transformer; text classification can use either bag-of-words with classical ML or a transformer. For each answer, add one clause explaining why the architecture matches the data structure, because examiners award the reasoning, not the acronym.
The candidate treats a sensor reading as ground truth, for example reporting an ultrasonic distance as exact, ignoring range limits, beam angle, surface reflectivity, or the difference between raw and filtered values.
Classroom exercises use clean numbers, so sensors appear digital and precise. Real datasheet caveats (dead zone below a few centimetres, soft surfaces absorbing sound, ambient light saturating an IR sensor) are learned as trivia rather than as design constraints.
What to do instead
For each sensor, memorise four parameters: what physical quantity it measures, its range, its main error source, and its output type (analog, digital, or bus). When a question involves a robot behaviour, state the error source and one mitigation (median filtering, sensor fusion, timeout on missing echo, calibration). Never quote a sensor value without units and an uncertainty or condition.
The candidate selects an actuator or driver without checking voltage and current compatibility, for example wiring a high-current DC motor directly to a microcontroller pin or ignoring that a servo needs an external supply.
Block diagrams hide electrical reality: the arrow from controller to motor looks like a signal path, so the power path is forgotten. Candidates also conflate the control signal (PWM) with the power that actually turns the shaft.
What to do instead
Redraw every actuation chain as three separate lines: signal (PWM, direction, or bus command), power (motor supply with shared ground), and protection (driver, flyback diode, current limit). State the microcontroller pin current limit and the motor stall current, and insert a driver stage whenever the load exceeds the pin rating. For servos, always mention a separate supply with common ground.
In a project-development question, the candidate jumps straight to the final build, omitting problem definition, requirements, iterative testing, and evaluation, or claims success without any measurable test.
Project questions reward storytelling, and the exciting part is the robot. The design-cycle language (define, design, build, test, iterate) is treated as filler rather than as the marking scheme, and candidates have often only seen finished projects, not the failed prototypes.
What to do instead
Answer project prompts with a fixed skeleton: user problem and success criterion (a number), constraints (budget, power, time), block diagram, build, test plan with at least one measurable metric, one documented failure and the iteration it triggered, then final evaluation against the original criterion. Even in a short answer, include the success criterion and one test result.
The candidate answers an ethics question with a general statement ('AI should be fair and safe') instead of naming the specific harm, the affected group, the trade-off, and a concrete mitigation.
Ethics is perceived as opinion, so candidates switch to vague moral language and stop analysing. They also fear that naming a trade-off looks like disagreeing with the 'right' answer, when examiners want the tension made explicit.
What to do instead
Use a four-part structure for every ethics scenario: who is affected, what concrete harm or bias could occur (with the data or design cause), which values conflict (privacy vs accuracy, safety vs autonomy), and one implementable mitigation (consent and data minimisation, bias testing across subgroups, human override, logging and audit, clear disclosure that a system is automated). Ground each point in the scenario's specifics.
The candidate states a safety measure for a robot without linking it to the failure it prevents, for example 'add an emergency stop' with no mention of the hazardous motion, detection method, or what state the system enters afterwards.
Safety features are memorised as a checklist of components rather than as responses to identified hazards. Without a hazard analysis, the candidate cannot say which risk each device reduces, so answers read as a parts list.
What to do instead
For any robot scenario, run a short hazard pass: list two or three credible hazards (unexpected motion, pinch point, loss of communication, sensor blind spot), then pair each with a layered control (software limit, watchdog timeout, physical guard, emergency stop) and state the safe state on trigger (power removed to actuators, brakes engaged, alert raised). Mention that the emergency stop is supplementary to design-level risk reduction, not a substitute for it.