Sometimes a single extension method needs to service several different
instances of the same opcode. This can happen with variables or custom
procedures, for example. This change allows the extension method to
inspect the `blockInfo` for instance data, including arbitrary
extension-specific properties if necessary.
- turnOn() renamed to _turnOn() and marked as a private function, i.e. it should only be called by BoostMotor-functions, not opcodes.
- New function turnOnForever() to be called by opcodes.
- turnOff() now sets the motor state.
- _clearRotationState now does a check for null rather than a truthy value
- all motor state setting removed from Boost-class and opcodes: stopAllMotors(), motorOnFor(), motorOnForRotation(), motorOn(), motorOff()
- turnOnForever(), turnOnFor() and turnOnForDegrees() now have a resetState-parameter with the default value of true. This allows the setMotorPower() and setMotorDirection()-functions to not reset state, to avoid them resolving the promises of the original motor commands that they are affecting.
BoostMotor now has a status getter/setter that replaces isOn() and is responsible for clearing various motor state parameters.
A new BoostMotorState-enum contains the possible states a motor can be in.
Since time-based motor commands really just trigger a BoostMotor.turnOn(), it's the opcodes that are responsible for setting the motor state.
873b56c985
In the following commit I changed the functionality so that we add a fixed amount (10) more power than the target speed, e.g. for speed 50 it would provide power 60. This is fine for high speeds, but for low speeds it provides poor torque:
e3cdbffa2a
I assume it would be possible to design some sort of calculation that enabled high torque for low speeds, and vice versa. I will discuss with the team.
- added an else-case to both setMotorDirection() and setMotorPower() so that dynamic speed/direction changes also affect the motorOn()-blocks just like the time- and rotation-based ones.
This was caused because the case for BoostMessage.PORT_FEEDBACK didn't handle the BoostPortFeedback.DISCARDED type, which corresponds to a command failing on the Boost hub.
There's quite a few interactions between degrees, their sign, and the currently set direction for the motor the degrees relate to. In this case, BoostMotor.turnOnDegrees() was being run with -degrees, and since that function does a Math.max between 0 and degrees, it resulted in 0 degrees.
Because of this, and for clarity, turnOnDegrees now only gets called with positive values. If running CCW, that should be specified in the direction-parameter.
Partly resolves#2087, #2088.
This was happening because scratch-vm is responsible for timed motor commands rather than using the Boost hubs commands to run motors for a specific amount of time.
This meant that when we simply sent a motorOn-command, the hub would immediately return feedback for the motor that the command had completed.
The fix for this was, for timed motor commands, to not receive feedback from the motor, and instead have scratch-vm modify the BoostMotor._status.
TODO: Fix for rotation-based commands.
Agreed. Changed to 50%.
- BoostMotorMaxPower changed to BoostMotorMaxPowerAdd and now describes an extra boost (no pun intended) to the motor. Documentation added that describes the feature.
- _colorBucket renamed to _colorSamples for clarity.
- oldColor is renamed to previousColor, and is now initialized in this._sensors.
- Modified documentation.
These compatibility changes:
- Use runtime.currentMSecs for the Clock timer "now" value
- Start executing hats before other threads change values
- Update test and fixtures to work with earlier hat execution
- Add test for hat execution block order
- Creating Boost._colorBucket will contains BoostColorSampleSize-amount of samples
- Boost._onMessage administers the _colorBucket and assigns Boost._sensors.color a value if all items in the bucket match.
E.g. if BoostColorSampleSize is set to 3, three continuous readings of the same color are required for the color to be detected by scratch-vm.
- Renamed BoostOutputCommandFeedback to BoostPortFeedback and its values for brevity
- Removed buf2hex-function
- Removed BoostMotor._pendingPositionOrigin (unused)
- Removed Boost._led (unused)
- Simplified _onMessage-handling of BoostPortFeedback-messages
- motorOnForRotation() now returns a Promise.all rather than a single promise. This solves two bugs:
-- when running turn ABCD for 3 rotations without motors connected to CD, the block would finish yielding immediately.
-- when running turn C for X rotations without a motor connected to C, the motor would never finish yielding.
- BoostMotor-class now has pendingPositionDestination, the rotation-equivalent of pendingTimeout, that stores a destination the motor should reach. When using setMotorPower() or setMotorDirection() while a motorOnForRotation()-block is running, a new motorOnForRotation()-command will be run for the remaining amount of degrees but with new power/direction, cancelling the old command.
- BoostMotor._status is only affected by feedback from the hub.
- setMotorPower() and setMotorDirection() no longer yields, since they just set state.
From design meeting regarding block design:
- Renamed all motors-label to ABCD.
- Added 'AB' motor label to address built-in motor pair.
- use the word direction in the setMotorDirection-block
- moved argument label in motor position reporter
- changed wording of color-sensing block.
- removed isTilted-boolean reporter
- removed changeLightHueBy-block
- fixed pingDevice-function bug.
-- Using a max-power setting of 100 rather than following the speed in the motor-commands will allow motors to run at really slow speeds.
-- As a result, motor-commands now use max-power of 100 regardless of speed and setMotorPower no longer scales according to a minimum speed of 20.
- BLE-rate enums consolidated into BoostBLE enum
Reduce the amount of code that needs to evaluated before we can
starting the target project if there is one. It is key to note that the
music extension includes ~2MB of base64 encoded sound samples. This
skips evaluating those samples and decoding base64 into binary typed
arrays.
Motors:
- motor position will now initially report 0 instead of false
- removed remaining motor position zeroing functions.
- removed startBraking().
- turnOn() and turnOnForDegrees() are now using an absolute max power as per the protocol documentation.
- the "turn for rotations"-block now accepts negative values.
-- turnOnForDegrees() accepts a direction to reflect the change above. The direction from the block is calculated against the motors current direction.
- commented EV3 tacho calculation code for motor positioning removed.
- Changed BoostMotorLabel to reflect actual motor block argument.
- startMotorPower() renamed to setMotorPower() since it doesn't start the motor.
- setMotorPower() will not start the motor.
- Max number of rotations for a motor-block is clamped to 100 rotations.
- 'Default' removed from BoostMotorLabel-enum as it wasn't used.
Sensors:
- removed remaining distance-related functions.
- color-reporters default value is now none rather than black.
- tilt-angles left and right switched to reflect the hubs orientation.
- Added BoostColorLabel-enum for color sensing block argument labels
- Regrouped blocks to be grouped by functionality, promoting color sensing
- Added 'any' to whenColor hat-block which triggers if the color sensor reports a value that is not none. Implemented an oldColor-value that allows the hat-block to trigger between color-changes, even if the sensor doesnt see 'none' in the meantime.
- Regroup blocks by functionality, i.e. motors, led, color-sensing, etc.
- Remove motor position zero-ing as concept and use MathUtil.wrapClamp to instead wrap everything around 360 degrees.
- WIP: "Set motor power to"-block should update motors that are currently running to emphasize principle that blocks have actions.
- Added IOs from documentation to BoostIO enumotor follows the speed set by Scratch and not the highest possible speed.
- Cleaned up line breaks in codebrake rather than float when stopping.
- Cleaned up documentationensors
- Deleted unused MOTOR_OUTPUT from BoostMode-enumbased on BoostMode-enum
- Set default-value for "set motor power to"-block to be all motors after feedback from @ericrosenbaum
- Implemented check in getMotorPosition() to see if motor is actually there before reporting position
This is a slight ergonomics improvement for faster benchmark loading.
We should be able to apply this to gui as well if it already does do
the same thing.
- Simplified generateOutputCommand() to follow the LEGO Wireless Protocol command-structure. Every output-command must have a portID, execution information, sub-command, and then followed by a custom payload which must be defined according to the protocol documentation mentioned in the extension.
- Simple motor commands now use the above subcommand-structure rather than the former primitive command structure.
- stopLED()-function removed since it's not used
- Implemented check of pendingPromiseFunction() for motors before firing.
- Added descriptions to BoostMode-enums
- Improved motor-position handling
- Added helper-functions for converting to/from motor position values
- Added default value to BoostMotor._pendingPromiseFunction
- Added changeLedColorBy-block
- Only motors will now try to resolve motor-promises
- Changed motor position wording from 'zero' to 'reset'
- Modified tilt-thresholds to improve tilt-handling
