Configuring Sensors and Motors

Blueprint on LaunchPad

Configuring Sensors and Motors: Implementation Notes

Sensor Configuration

In NXT-G, every time you use a sensor, you have to configure it — state what sort of sensor it is and on what port.

In Enchanting, most of this is taken care of in the Sensor Configuration pane. A mockup follows:



You specify what the sensor does, what type of sensor it is, and what you want to call it. In the image above, the item on sensor port 1 measures brightness. It just happens to use an NXT Colour Sensor to do that. Throughout my code, I refer to it as "Light Sensor".

When I give this code to a friend, s/he can say, "Well, I've got a colour sensor, but it is on port 3" and, in the configuration pane, re-arrange it to be on port 3. No code changes have to occur.

Another friend might say, "Well, I don't have a colour sensor, but I do have a light sensor, and that'll work for measuring brightness." That person, then uses the drop-down menu in the block and changes the sensor that measures brightness from a colour sensor to a light sensor. No code has to change.

Front End Requirements:

• We need to be able to draw hat blocks, possibly in different colours. The yellow hat blocks in this image do not move.
• The blocks will either come up in the coding pane or in an overlay over the window.
• The user will be able to drag different sensor configurations out of the pane on the left, just as the drag code tiles into the coding pane in Scratch.
• If a user renames a sensor, the name should change everywhere in the code to match.
• If a user's code references a sensor that is not configured, they either need:
  • to be told that things are not properly configured
  • to have the program compile and run anyway, but ignore that sensor.

Motor Configuration

I'd like motors to be configurable in the same way. Here is a mockup:



As you can see, a user can set which port a motor is on. Right now the focus will be on using NXT motors. In the future, we might make it possible to use RCX-style motors, PowerFunction motors, or motor multiplexers.

It sometimes happens that you need to make the motors drive backwards to make the robot go forwards. When configuring a motor, a user can note that, and in the code, tell the robot to go forwards. (A friend, with a different robot, can adjust the one setting, and leave the code intact.)

I'd also like users to be able to configure a 'pilot' — which tells the robot how large the wheels are, how they are driven, and allows you to write code like "drive forward 10 cm" and "turn the robot 180 degrees". On a different robot, you just need to adjust the settings here and the distances and degrees will work properly.

One flaw with this approach is that it needs to be obvious that you can not use the same blocks for configuring the motors ports that you use to configure the pilot. I welcome suggestions on improving it.

UI Notes

I have two thoughts for incorporating the configuration panels into the UI.

• Do it in the same way variables are done. On the variable menu, you can create a variable, and it brings up a menu that lets you do so. After you have created a variable, new code blocks show up in the menu.
• Do it the same way costumes are done. Above the central pane in Scratch are some tabs that control what the pane shows. The tabs say "Scripts", "Costumes", and "Sounds". It may make sense to add one that says "Configuration". The downside to this, though, is that the scripts, costumes, and sounds are specific to the sprite, and the configuration is the same for the whole robot.

---