Robot Basic Lab
Preview learning notebook Download learning notebook
Keyboard Control English translation
To stop a moving device, define its behavior when a key is released or communication is lost, as well as when a key is pressed.
Before practice 01 What happens if key release events are not handled?Description The last movement state may persist, causing movement to continue longer than intended.
02 How can you distinguish missing input from a received quit command?Description Treat missing responses as timeouts and explicit termination as a quit event, with both leading to a safe stopped state.
Execution conditions Reproduce behavior using an input event list. Connecting a real keyboard or device is a separate step that connects the same processing function to the event receiver.
1. From key input to velocity commands Starting conditions t = [ 0 0.1 0.2 0.3 0.4 0.5 ] t=\begin{bmatrix}0&0.1&0.2&0.3&0.4&0.5\end{bmatrix} s, key=[w,w,release,d,quit,w]. Set w=(1,0) and d=(0,-1) m/s.
Procedure Create a pure function that converts each input into vx, vy, and termination state. Set velocity to 0 on release, and ignore all inputs after quit. Record the command vector and state for each input row. Results to retain A processing table with 6 input rows and a processing function. Items to record and points to check
t [s]
key
vx [m/s]
vy [m/s]
Termination state Points to check Does w after quit leave velocity disabled? Do undefined keys trigger a stop or an explicitly defined ignore rule? 2. Time intervals and cumulative movement Starting conditions Assume the velocity from activity 1 is maintained until the next input. The initial position is (0,0) m.
Procedure Calculate Δposition=v*Δt for each interval. Create a position table over time and an xy trajectory plot. Compare with the result when all input intervals are changed to .2 s. Results to retain Compare trajectories and final positions under the two interval conditions. Items to record and points to check
Interval
Δt [s]
Velocity [m/s]
Cumulative position [m] Points to check Did you distinguish velocity from travel distance? Does position remain fixed after termination? 3. Repeated input and long gaps Starting conditions Add a record with repeated w key events at t ∈ { 0 , .01 , .02 } t\in\{0,.01,.02\} s, followed by .5 s without input. Set the timeout to .2 s.
Procedure Compare the behavior to ensure repeated inputs set velocity rather than accumulate acceleration commands. Add a rule to stop when .2 s has elapsed since the last input. Record how commands and positions differ before and after applying a timeout. Results to retain Plots before and after applying a timeout, and 3 sentences describing the behavior rules. Items to record and points to check
Time point
Last input / elapsed time [s]
Timeout?
Velocity
Position Points to check Can you reproduce behavior using recorded events without sending actual OS keyboard input? Are input processing, time updates, and device transmission separated?