JunoJR Learning
Skip to learning content
← Sunflower Robotics: Sense, Decide, Move
Mission 1 of 6Public first mission

1. Give your robot a mission

Make a simulated seed-delivery robot take one explainable step.

Architect skill: Define a small system by its inputs, decisions, outputs, and evidence.

The full mission is planned for 75 minutes. Split it into short activities and take breaks. Laptop or desktop for the Python browser simulation. No robot is needed for the introduction. Physical hardware needs a separate adult safety review.

Your place, at your pace

Stop after any activity. Ticks are your own notes, not an assessment. Remembering your place is optional and does not sync to another device.

Checklist changes stay in this page unless you choose to remember them.

Jump to the coding workspace ↓

A small activity is enough

Give a fictional robot one small seed-delivery job and explain its first allowed step.

Parent prep · before you start
  • Browser: keep the initial experiment export, then put from main import self_test and self_test() on separate lines in experiment.py. Select Run file experiment.py and Run. Download: python3 main.py --self-test.
  • Provide paper sensor/decision/action cards; the child can choose cards while the parent reads Python output.

Activity 1 of 3 · 6 minutes

Draw one mission

Child · driver & designer
Sketch two invented seed stations and four sensors.
Parent · thinking partner
Ask how one decision could be checked without physical movement.
  1. Write move only with valid, fresh, healthy and clear required data.
  2. Connect request/sensors → decide → command → motion_label.
  3. Mark the whole drawing simulation only.
Look for this: The mission has an observable software decision, not a claim of seed delivery in a room.

Walk through an example

Predict before revealing the result, then try the change in the real workspace. This explanation does not run or test your code.

Before

The clear request is {left:0.25,right:0.25,seconds:0.2}; seeded sensor values are fresh and above 20.

One change

Run the clear scenario with seed 7 through decide.

Demo prompt 1 of 2

A permitted request

One case can reveal the full decision path.

Try in the workspace: Open main.py’s scenario(name, seed) function and point to its request dictionary (left 0.25, right 0.25, seconds 0.2). Run clear with seed 7; then point to decision.command and display in the printed JSON. The request is in source, not a printed request field.

Check what actually happened

Run each check yourself. Mark it only after comparing the actual output with the expectation; a tick does not automatically test your code.

Signs to discuss together

  • Actual clear output supports the diagram.
  • The child labels simulation and explains the final zeros.

Stuck? Make the problem smaller

Read the output together. Undo your last small change and run again. Export a copy before resetting files. If this device cannot run the project, read the full reference below and use the parent guide to prepare another computer.

Python says it cannot open main.py.

Check that the terminal is in the folder containing the saved file and that the filename is main.py, not main.py.txt. Ask the instructor to verify the folder.

The long JSON line feels unreadable.

Find the quoted labels decision, display, and after_duration first; ignore field order. Copy the line into your notebook and add line breaks without changing values.

Explain together

  • Which field is a request and which is a decision?
  • What would need a real measurement?

Before you pause: A labeled architecture drawing and a prediction-log entry containing the actual clear-scenario result. Export workspace files for a portable backup and remember this activity or write its name on paper.

Build, run, observe

Full lesson reference ↓

Use Run in the workspace after one small edit. Browser output is evidence of this browser run; native devices and physical robots need separate checks.

Sunflower simulation workspace

Opening the original starter…

Full authored lesson · setup, code, checks & extensions

The complete original lesson is preserved here. Its downloaded-project instructions describe the local development path; the browser introduction above needs no installation. Longer and native/hardware tasks may need the adult-prepared tools listed in the course overview.

By the end, you can…

  • Describe sense → decide → act with a concrete example.
  • Run the provided Python starter and read its output.
  • Predict a result before observing it.

Keep your starter project and builder notebook open. Make one change at a time and save a working copy before trying the next idea.

1. Draw one small mission

A robot needs a job whose success you can check. Our fictional robot carries seeds between two marked stations. Today we only decide whether one short forward request is allowed.

  1. Draw two stations on paper and label the route as fictional.
  2. Write: 'Move only when the required measurements are valid and the path is clear.'
  3. Add four sensor boxes, a decision box, and two wheel-command boxes. Connect them with arrows.

2. Open the local starter

The computer will print synthetic observations and decisions. It will not connect to a robot. Python's standard library supplies everything it needs.

  1. Download /lab-starters/sunflower-robotics.zip and extract main.py and README.txt into the same new folder.
  2. Open a terminal in that folder. Run python3 main.py --self-test; ask your instructor to substitute py on Windows if needed.
  3. Copy the PASS line into prediction-log.txt. If the command fails, resolve it before editing the file.

terminal · sh

python3 main.py --self-test
python3 main.py --scenario clear --seed 7

3. Predict, run, and label

A request is an intention. The decision function determines whether that request becomes a command. The display is a label for the simulated action.

  1. Predict the display for the clear scenario before running it.
  2. Run the clear scenario. Find sensors_cm, decision.reason, decision.command, display, and after_duration.
  3. Underline the positive left/right values and the final zeros. Explain why a stopped end state can follow a permitted move.

4. Make the architecture visible

A diagram becomes useful when every box points to a real value or function.

  1. Label the sensor box mock_sensors, the decision box decide, and the display box motion_label.
  2. Write one sentence distinguishing a synthetic distance from a measured distance.
  3. Have a partner trace the clear scenario across your diagram without your help; revise any confusing arrow.

Ask your AI coach

Use the JR Playground if configured, or ask an adult to operate their approved coding assistant. These prompts also work as questions for a human partner.

You are our instructor's robot-design coach. Using only this synthetic clear-scenario output, explain request, decision, and final stopped state in three short sentences. Name one thing this simulation cannot prove about a physical robot. Ask us to check your explanation.

Before accepting its answer

  • Match every claimed field to the actual JSON output.
  • Reject any claim that a motor moved or a sensor measured the room.
  • Point to after_duration and explain that it is produced by the teaching program, not physical feedback.

Prove it works

  1. Test 1: Run python3 main.py --self-test.

    Expected: PASS: 16 checks (14 decisions, command limits, repeatable sensors)

  2. Test 2: Run python3 main.py --scenario clear --seed 7.

    Expected: decision.reason is clear, display is FORWARD, command is left 0.25/right 0.25/seconds 0.2, and after_duration contains three zeros.

If you get stuck

Python says it cannot open main.py.

Check that the terminal is in the folder containing the saved file and that the filename is main.py, not main.py.txt. Ask the instructor to verify the folder.

The long JSON line feels unreadable.

Find the quoted labels decision, display, and after_duration first; ignore field order. Copy the line into your notebook and add line breaks without changing values.

Choose your challenge

Build together · guided
Ages 9–10: an adult runs the commands while the learner arranges sensor/decision/action cards and reads FORWARD or STOP.
Take the controls · independent
Ages 11–13: alternate predictor and terminal-driver roles; each learner explains a different output field.
Go deeper · architecture challenge
Ages 14–16: inspect the call sequence from main to run_scenario to decide and annotate where data crosses each boundary.

Save your evidence

A labeled architecture drawing and a prediction-log entry containing the actual clear-scenario result.

Reflect: Which part of your evidence shows what the program decided, and which part would require a real measurement?

Try this with your camp team

Make a human robot chain: four learners hold sensor cards, one applies a decision rule, and one holds the action card. Swap roles before checking the computer result.

After the public first mission, a parent or guardian uses the existing access flow to open later authored missions. Your workspace remains available.