WO2019207583A1

WO2019207583A1 - Physical programming interfaces with a single command thread

Info

Publication number: WO2019207583A1
Application number: PCT/IL2019/050459
Authority: WO
Inventors: Amir ASOR
Original assignee: Algobrix Ltd
Priority date: 2018-04-24
Filing date: 2019-04-23
Publication date: 2019-10-31
Also published as: IL258915B; IL258915A

Abstract

This application is an Application of Addition to patent no IL246651- granted 01.11.2017. The application of addition teaches the integration between physical programming interfaces with a single command thread, enabling a single line of command sequencing and having the option of presenting the parameter by a graphic mark on top of the Function Block.

Description

PHYSICAL PROGRAMMING INTERFACES WITH A SINGLE COMMAND THREAD

FIELD OF THE INVENTION

[Para 1 ] This application of addition is an improvement of the invention of patent 5 IL246651 which relates to a physical programming interface with a multi threaded command sequencing, which distinguishes between functions and parameters, by separating them to different planes (horizontal and vertical), and associates the parameter quantitative size and its functionality with their physical appearance and dimensions. The association between the functionality and the0 physical appearance also enables an automatic error prevention system by one- to-one relationship, i.e. , each parameter has a unique receptor in the function block. The system also enables debugging by using lights to inform on functional errors. 5 BACKGROUND OF THE INVENTION AND PRIOR ART

[Para 2] Teaching robotics, computer programming and engineering skills to young learners has recently been growing in popularity due to changes in recent technology and the growing need for capable programmers ["Take a giant step: A blueprint for teaching children in a digital age" Barron, B. et al, (201 1 )].0 ["Transforming American Education: Learning Powered by Technology". U.S.

Department of Education (2010)]. However, there is a constant shortage in programmers due to the complexity of learning and the bu ilt in barriers of programming ["Integration of Innovative Technolog ies and Affective Teaching & Learning in Programming Cou rses" Prasad et al, (201 5)] . Thus, there is a need for a flexible and wide-ranged intu itive physical prog ramming interface which

5 demonstrates the following coding elements for non-programmers:

• Command sequencing.

• Mu lti-thread ing in every cod ing stage

• Clear distinction between fu nctions and parameters of the fu nctions.

• Intu itive visualization of the parameter fu nctionality and scales, e.g.0 connecting the object di mensionality to its programmable value.

• Automatic error prevention to avoid user frustration due to compilation errors.

• Debugging a specific command , which will be referred as the“me cu be”.

[Para B] In the last two decades there has been a growing interest on how to 5 develop such a physical programming interface where a large variety of products have been introduced. However, none of them was able to satisfy all the requ ired elements. In 201 2 a company called Sifteo Cu bes suggested a semi-stage for physical programming by using Siftables which are small computers with a g raphical i nterface. The small computers were able to commu nicate with each0 other to generate simple computer program. However, each cu be is highly expensive and the interface is not physical but rather graphical , u sing separated small computers. This problem is emphasized by the parameters, which are selected in the graphical touch screen and not connected to physical objects and their characteristics.

[Para 4] In 201 1 Modular Robotics Studio introduced the concept of Cubelets, which were small plastic blocks designed to magnetically snap together for the 5 construction of robots. Each block contains its physical meaning (i.e. light, sensor type, movement...) and communicates with each other. Once the blocks are physically connected, they begin to operate without a physical programming interface. This interface has several disadvantages in the teaching of coding, as each block is“alive” and its parameters cannot be reconfigured.

0 [Para 5] In 201 4 Primo Toys launched Cubetto, which was a hands on coding program with physical elements. Their initial robot and programming kit was enhanced in March 201 6. The current product includes a wooden robot and plastic blocks with electronics. Each block is a physical representation of an u nambiguous instruction code (right, left, forward, backward). The coding is 5 conducted on the horizontal plane by placing the plastic blocks. Cubetto has also similar drawbacks as discussed before: there is no clear distinction between function and parameters, Multi-threading is not possible etc...

[Para 6] In 2008, Hsieh et al., [US7,31 6, 567], suggested a toy for teaching programming based on stackable blocks, where each one of them has a memory0 for storage of at least one computer program and they are all the same. The blocks are mechanically stacked and electrically connected to form a computer program. The connected blocks are transmitting the program to a robot for execution. However, US7,31 6, 567 does not differentiate between function blocks

B and parameter blocks since all the programming is conducted based on stacking. US7, 31 6,567 also allows for multi-threading by stacking different blocks to generate several functions. However, this method is limited since only the height dimension locates the sequencing interface, which means the branching process 5 can only be conducted at the beginning of the program.

[Para 7] In 201 4 Sullivan et al. introduced KIBO which was a robotic demo for teaching children how to program ["KIBO robot demo: engaging young children in programming and engineering" Sullivan et al., (201 5)]. KIBO is programmed using physical wooden blocks which, do not contain any electronics but instead,0 each block had a unique barcode. KIBO has an embedded scanner, which allows the user to scan and interpret the coding sequence. However, it allows neither threading, nor parameter control.

[Para 8] In J une 27, 201 6, Google introduced the Project Blokes, which was based on the Tern Tangible Programming, and which very similar to KIBO, is a physical 5 programming interface where programing can be conducted in one plane (vertical or horizontal). The programming is conducted by using a Brain Board, Base Boards, and Pucks. The brain board activates the entire program. Functions are determined by Base Boards, where their functionality is defined by the Pucks which are placed on top of them. Each Puck contains one instruction, which means0 that each Base Board can contain a function with one parameter only. The basic Puck is flat or has a 3D graphics imprinted on it, which means that physical dimensions do not correlate with the logical value. The physical connections of the Brain Board and Base Boards include 2 physical connections for the Brain Board and 4 connections (1 male, B females) to the Base Board. This structure does not use the full 4 directional possibilities of physical programming. For example, threading in four directions straight from the Brain Board is not feasible. In addition, the 1 male\3 females' structure doesn’t allow for a cube to receive 5 inputs from more than one prior cube (e.g. an if statement, or combine threads...). Another important issue is that the interface does not distinguish between functions and parameters, meaning that each function receives only one parameter scale creating a limited flexibility, for example, if a function requires summing its duration period of 2 seconds and also adding external duration 0 value, such as value from sensor or a value from calcu lator function. This limits the programming possibilities as in many cases one wou ld like to change more than one parameter in the function, i.e. controlling a motor’s speed, power and duration all at once.

[Para 9] In addition to the above-mentioned problems, all of the current 5 methods address the issue of debugging the program in a rather limited way. For example, US7, 31 6,567, suggests stacking of same blocks, which cannot support mixtu re of commands. None of them is offering the possibility to ru n a specific block to activate a specific function, i.e. it is not possible to use a“me cube”. In addition, none of the above has a ru n-time debagging system to spot the0 function, which performed on a real time by the external device (PC, Robot, Motor etc.).

[Para 10] IL24665 1 solved the foregoing problem by using the 3D space as the physical programming playground. SUMMARY OF THE INVENTION

[Para 1 1 ] In IL246651 , the code visualization is conducted by using three main building blocks: function block, parameter block and the programed element (motors, sensors, robots, PC). Each function block includes a microcontroller, 5 which allows communication with its neighboring function blocks, distinguishing between function blocks, reading data from parameter blocks and controlling the programed element.

[Para 12] IL246651 separates between function blocks and parameter blocks using different dimensions and different physical axes. The function blocks are0 placed in the horizontal 2D plane, while the parameter blocks are placed in the vertical plane. Placing the function blocks in the horizontal plane allows for multi threading at every point of the program. This is important for even a simple program, which wants to activate different motors in different events of the program independently. In addition, using the vertical plane for the parameter 5 blocks generates a clear correlation between the embodiment of the block (its physical vertical size) and its quantitative representation.

[Para 1 B] Error prevention is conducted by adding complexity to the system of different blocks, which represent different types, correlate with their physical meaning (i.e. a stop shape for stop command) and prevents the user from placing0 blocks, which may lead to compilation errors by controlling their physical connections. Finally, this interface generates a clear visualization of the coding sequence.

[Para 1 4] The system of IL246651 allows for bidirectional communication, during runtime, between function blocks and the programmed element so that, at any 5 given running time, user may know which function block is running by adding notification lights. I.e., when a function block is active (in the programed element), a led is turned on in the operative function block.

[Para 1 5] The application of addition teaches the integration between physical programming interfaces with a single command thread, (instead of mu lti-thread)0 enabling a single line of command sequencing and, each command may have a graphic mark (instead of a parameter) describing the way of command operation related to the interlock system. The change of the graphic mark does not change the function characteristics of the block, but rather serves as an indicator to the user, which parameter has been pre-assigned to the specific function block. 5

BRIEF DESCRIPTION OF THE DRAWINGS

[Para 1 6] Fig. 1 - is a perspective view of changes in component of application of addition.

0 [Para 1 7] Fig. 2 - is a top perspective view of an example similar to fig. 6 of

IL24665 1 but the inside components are passive electric components. [Para 1 8] Fig. 3 - is a schematic circuit diagram of one embodiment similar to fig. B of IL24665 1 but the inside components are passive electric components.

[Para 1 9] Fig. 4 - shows a Function Block similar to fig. B of IL24665 1 , presenting a new scenario in which error prevision is being activated.

5

DETAILED DESCRIPTION OF THE INVENTION

[Para 20] The application of addition teaches the integration between physical programming interfaces with a single command thread, enabling a single line of0 command sequencing.

[Para 21 ] Each command may have a receptor 800 to a stackable parameter 200b or non-stackable parameter 200a, or having a graphic mark, describing how the command operates (for example, the period of time in which a function is preformed 1 01 (fig. /). A parameter may appear as a sticker (1 01 ) and not by5 piling the block parameter. This way the identity of the function block (1 00) includes fixed parameter as well, that are unchangeable. As may be seen in fig. 1 , there is one surface only between each one of the blocks from where voltage and data may flow to and from the next following blocks.

[Para 22] The system as described in this application of addition comprises0 passive-electric parameters 702. The information of passive parameters 701 is been collected by fu nction blocks 1 00, in order to associate the read value to the passive element value (for example by RF-ID, EEPROM, resistors) {fig. 2) [Para 2B] The system as described in this application of addition also comprises passive-electric function blocks 701 . The information of the passive function block 701 is been collected by the play block BOO, in order to associate the read value to the passive element value (for example by RF-ID, EEPROM, resistors) {fig. 5)

The system as described in this application of addition comprises an error prevention sign, which alerts if a function block is put in a place with no option to be implemented by Programmed Element 1 1 0. For example, error prevention light will be active when using a function block 1 00 with a sign of a motor, to program a programmed element of a sou nd (like a Musical keyboard 1 1 0 {fig.4).

Claims

CLAIMS:

1 . A physical programming interface with a single command thread, enabling a single line of command sequencing, comprising passive-electric parameters and passive-electric function blocks

5 wherein each command may have a receptor to a stackable or non-stackable parameter, and; wherein the information of the passive parameters is being collected by function blocks, associating a read value to the passive element value; 0 wherein the information of passive function blocks is being collected by the play block, associating read value to the passive element value; wherein each command may have a graphic mark describing the way of command operation related to the interlock system.

2. A physical programming interface of claim 1 comprising an error prevention sign that alerts when a function block with no option to be implemented by the programmed element is wrongly placed. 5