The present invention is related generally to the learning of science, technology, engineering, and mathematics, and in particular to a robotics construction kit.
Systems exist for children to construct and program robots but no robotics construction toys use the same modular blocks paradigm or enable children to build robots without programming. Existing systems for constructing robots are centralized, with one computer that controls robot operation. None of these products embody a distributed computing model and none allow the modular construction of robots by beginners. The few toys that contain more than one node of computation are passive entertainment products.
An exemplary educational construction kit is disclosed. The exemplary kit has a plurality of blocks, each one of the plurality of blocks having an integral block data flow, a power exchange, and a structural connector side, wherein each one of the plurality of blocks respectively includes. The exemplary kit also has reprogrammable software to enable end-users to reprogram a unique and a specific behavior of each of the plurality of blocks. The exemplary kit also has an embedded electronic device with a microcontroller that processes the reprogrammable software to instruct the respective block to perform the unique and the specific behavior. Interconnection of two or more blocks of the plurality of blocks forms a distributed communication network. At least one block of the plurality of blocks further includes an additional component to allow the at least one block to perform a different behavior from at least one other block of the plurality of blocks.
An exemplary method to reprogram modular units is disclosed. The exemplary method includes providing a plurality of interconnected modular units in adjacent orientation thereto, wherein each modular unit includes reprogrammable software, wherein at least one unit of the plurality of interconnected modular units further includes an additional component to allow the at least one unit to perform a different behavior from at least one other unit of the plurality of interconnected modular units. The exemplary method also includes using a computer or mobile device running a Web browser to communicate with the plurality of interconnected modular units. The exemplary method also includes reporting individual pairwise connections of the plurality of interconnected modular units to the computer or mobile device. The exemplary method also includes selecting a node displayed by the computer or mobile device associated with a target modular unit to be reprogrammed. The exemplary method also includes selecting a replacement source code, and compiling a native code for the target modular unit to generate a reprogramming packet. The exemplary method also includes passing the reprogramming packet to the target modular unit to replace the reprogrammable software on the target modular unit.
Various aspects and embodiments of the invention is illustrated by the following drawings figures in conjunction with the accompanying description, in which:
As used herein in the specification and claims, including as used in the examples and unless otherwise expressly specified, all numbers may be read as if prefaced by the word “about”, even if the term does not expressly appear. Also, any numerical range recited herein is intended to include all subranges subsumed therein.
The present invention can be any size. For illustration purposes only, blocks 2 can be 40 mm plastic cube-shaped blocks that snap together with magnetic 23 and electric connectors 24, 25, 26 (
Every block 2 contains a microcontroller and supporting electronics. The microcontroller in each block runs a program in firmware, which provides the default behavior of the blocks. All blocks initially run the same firmware program. In alternative embodiments of the present invention, users may replace the initial firmware using a reprogramming interface described below.
There are four categories of blocks: Sensors, Operators, Actuators, and Utilities. Different colors of plastic indicate the block categories. Sensor blocks sense signals from the environment (including light, sound, touch, motion and distance from objects) and pass signals to connected neighboring blocks. Operator blocks apply functions to those signals including arithmetic functions that compute a number from two or more numbers, such as sum, maximum, minimum, inverse and threshold. Actuator blocks convert signals they receive into various types of action. For example, a motorized tread block (
Now turning to
In one embodiment of embedded electronic device 4 one or more printed circuit boards 4A can be configured to be adjacent to an inner surface 12 of side 6. In the case where there is more than one printed circuit board, solder joints 18 electrically couple three individual circuit boards 4A, 4B, 4C, as shown in
Each block 2 contains a core set of identical embedded electronic device 4 on one or more printed circuit boards: a microcontroller, programming header, shift register, and power management circuitry. In addition, some blocks contain additional electronics and mechanics specific to their functions. For example, the motorized tread block (see
Each sensor block and each actuator block has a special face that houses its sensor or actuator. These special faces may or may not contain hermaphroditic connectors to attach to other blocks. For example, the special spinning face 45 of the rotation actuator block 47 (see
Now turning to
Now turning to
Now turning to
Now turning to
Now turning to
Now turning to
Now turning to
Now turning to
The embedded electronic device 4 inside each block 2 includes a printed circuit board 33 having a motherboard 4A, a daughterboard 4B, and wing boards 4C (see
An electrical connector 20 can also use magnetic force to from an integral electrical and structural connector to hold parts together physically as well as electrically to connect pairs of blocks 2.
The connector 20 shown here is four-way rotationally symmetric. It could easily be modified to support a different number of rotations, such as two or six (or more). The connector 20 shown herein supports three electrical contacts, in this case for conducting a power signal, a ground signal, and a data signal, but it could be easily modified for more or fewer contacts.
The connector 20 has a front, or outer surface 11, which contacts another connector when it is connected, and a back, or interior side, which contacts a circuit board.
Embedded magnets 23 on each face or side 6 of block 2 and concentric rings 25, 26 and a center spring pin 24 connect the blocks 2 electrically. The magnets 23 on one block 2 and outer rings 26 on the other block 2 hold each pair of blocks 2 together physically by magnetic force.
When a pair of connectors 20 are held together physically by the magnets 23, and exerts an axial force that compresses the rings 25, 26, which holds the rings 25, 26 firmly against the circuit board 33 behind them. This force also holds the outer rings 26 and spring pins 24 in contact with one another on the outer surface 11 of side 6. The outer rings 26 can be made of any magnetic material, such as stamped steel.
The rings 25, 26 connect electrically using metal spring clips to contact circuit boards 33 mounted on the inner surface 12 of each side 6.
On the back, or interior side, or inner surface 12 of the connector 20, a printed circuit board 33 makes electrical contact with the spring pin 24 and the sprung wings 27, 29 of inner and outer rings 25, 26, respectively.
Each block in a construction possesses a dynamic one-byte value that determines how it operates with regards to software, block data values and behaviors. These values originate in sensor blocks, travel through the construction from block to neighboring block and are consumed by actuator blocks. Thus, sensors are data sources and actuators are data sinks. Operator blocks change data values that pass through them, according to their pre-programmed functions. Utility blocks (except for blocker blocks) simply pass data unchanged.
A Sensor block computes its value from environmental input. A light sensor block, for example, computes a value of 5 in a dark room and over 200 outside on a sunny day. For example, a touch sensor has a resting value of zero and 255 when it contacts another object.
Each Actuator block derives its value from data it receives from its neighbors. The Actuator block's action depends on this value. For example, a tread block drives along a surface with a speed proportional to its value. A Rotation block with a value of zero remains still, but with a value of 127 it rotates its active face at half speed.
The default firmware computes the Actuator block's value as the weighted average of the values it receives from all sources. Values originating closer to the block are weighted higher than values originating further away. The formula is as follows:
V=Sum (V1/D1+V2/D2+. . . Vn/Dn)/n
where n is the total number of packets in the Action block's data store, V1, . . . n are the sensor values in arrived data packets, and D1, . . . n are the distances (hop-counts) for these data packets, respectively.
An Operator block computes its value as a function of the values it receives from its neighbors. The value of a Sum block, for example, is the arithmetic sum of its neighbors' values. The value of a Maximum block is the largest of its neighbors' values.
A simple example illustrates the flow of data values and resulting behaviors.
The robot (shown in
Programs running in the blocks exchange data through the electrical connections on the block faces. They form a network that communicates data from sensor blocks to actuator blocks.
Blocks operate asynchronously, transferring data pairwise with no central clock. Each sensor block's value derives from its embedded sensor. Every other block's value is computed as a function of the number of steps from every sensor data source in the construction, with closer sensors having a greater influence than sensor that are farther away. Two sensor blocks at either end of a chain of blocks, for example, create a gradient of values along the blocks between them.
Each data transfer between a pair of blocks is done as a packet. Packets originate at sensor blocks, which produce the data values from their sensor readings. Packets are consumed by actuator blocks, which use the data values to determine the actuator's physical behavior.
Each packet contains the unique ID of the originating sensor block, a time stamp that indicates when the packet was created, a hop-count, and a data value. Each time a packet moves from one block to another, its hop-count is incremented by one. The hop-count therefore describes the distance the packet has traveled through the network from its sensor block source.
A propagation algorithm in the firmware program running in each block manages the flow of packets through the block. On arrival of an incoming packet from a neighboring block, the propagation algorithm compares the incoming packet's originating sensor block ID with other packets in its store. If any packets in its store have the same ID as the arriving packet, it compares the time stamps of the two packets. If the arriving packet is older than the packet in its store, it ignores the arriving packet. If the packet in its store is older, it deletes the packet in its store and adds the incoming packet to its store.
Each block constantly tries to establish a data connection with each of its neighbors, successively. Whenever a connection between two blocks is established, each connected block adds to its data store the contents of its neighbor's data store, eliminating the oldest packets originating from the same sensor, as described above.
The reprogramming system enables users to change a firmware program that runs in any unit of a distributed modular robot shown in
A distributed modular robot is a collection, also called ensemble, of individual units also called modules, each comprising a microcontroller and additional electronics and mechanical components, and the having the ability to communicate with other units, some but not necessarily all of which include a sensor, such as a light, sound, or distance sensor, or an actuator such as a motor, speaker, or LED.
The overall behavior of a distributed modular robot is produced by local interactions among its units: A distributed modular robot has no single controlling unit. Therefore to program and reprogram the robot's behavior, a user must enter controlling code, called firmware, into individual units.
The reprogramming system described herein enables a user to compose and compile a program on a computer or mobile device, also called the programming platform, and load the resulting compiled firmware code into some or all of the robot's units. This enables a user to change the physical behavior of individual units and hence the behavior of the distributed modular robot.
Other embodiments of the present invention allowed the user to otherwise replace the unit's source code by (i) entering a new source code in an editor on the computer or mobile device, or (ii) editing previously entered source code selected from a database.
The wireless communication unit reports, to the editor and compiler, the currently connected units' identities and connections of the modular robot to the reprogramming environment. The programming editor and compiler displays this to the user, for example as a graph in which nodes represent units 36 and edges represent connections 30 between units (
The programming platform, using the target unit's unique ID as an index, retrieves source code from a database stored on a server and displayed in a text-editing area 43 on the PC or mobile device screen 31. The user enters new source code in the text-editing area, compiles it, and downloads it into a unit.
Upon the user's request, which is indicated for example by the user pressing a button in the editor and compiler's screen interface, the editor and compiler posts the new source code to the database stored on the server, stamped with the current date and time.
The database contains source code for the firmware that is currently running on the unit, as well as previous versions of the firmware. The user can revert to a previous version of the firmware by selecting it in a menu; the editor and compiler displays the source code for this previous version in a text-editing area and the user can compile and download the program into the unit. Other embodiments of the present invention provide the capability of entering a new source code in an editor on the computer or mobile device or editing previously entered source code selected from a database.
In addition to posting the new source code to the database, when the user requests it, the editor and compiler compiles the user's program. If the code compiles without error, the editor and compiler sends the code to the wireless communication unit, which routes it to the designated target unit in the modular robot. The wireless communication unit waits for acknowledgement from the target unit that it has been successfully reprogrammed. When it receives this acknowledgement, the wireless communication unit conveys it to the programming editor and compiler, which in turn conveys it to the user. If the wireless communication unit receives no acknowledgement within a set time, the wireless communication unit conveys this information to the editor and compiler, which conveys to the user that reprogramming has failed.
The user's compiled program is copied from the wireless communication unit through the network of units in the modular robot to its designated target unit.
When a unit in the modular robot receives a reprogramming packet that is targeted for another unit, it passes the packet to all the units it is connected to.
When a neighbor unit 42 in the modular robot receives a reprogramming packet that is targeted for another unit (target unit 40) that is directly connected to it, neighbor unit 42 passes the reprogramming packet to the target unit 40 and prepares to reprogram the target unit 40.
When the target unit 40 receives a reprogramming packet addressed to it, it restarts its microcontroller in reprogramming mode, also called bootloader mode, which begins to execute the bootloader program that is stored in its memory. When the target unit 40 restarts, it signals to its neighbor unit 42 that it is ready and waits for reprogramming by its neighbor unit 42.
The neighbor unit 42 waits until it receives a ready message from the target unit 40 and then reprograms the microcontroller of the target unit 40 using the bootloader program that resides on the microcontroller. The neighbor unit 42 sends the target unit 40 a reprogram message. The target unit 40 resets itself and starts its bootloader program when it receives the reprogram message. The bootloader program sets the target unit 40 to receive a new application program from the neighbor unit 42. The target unit 40 signals to the neighbor unit 42 when the reprogramming sequence is complete, and the target unit 40 passes an acknowledgement packet, also called ready packet, back to the wireless communication unit. Both target and neighbor units then return to their ordinary modes of operation.
While the disclosure has been described in detail and with reference to specific embodiments thereof, it will be apparent to one skilled in the art that various changes and modifications can be made therein without departing from the spirit and scope of the embodiments. Thus, it is intended that the present disclosure cover the modifications and variations of this disclosure provided they come within the scope of the appended claims and their equivalents.
This application is a continuation of U.S. patent application Ser. No. 13/386,707 filed on Jan. 24, 2012 and entitled “Modular Robotics,” which is a U.S. national stage entry of PCT Application No. PCT/US2010/002084, filed Jul. 23, 2010 and entitled “Modular Robotics,” which claims priority to U.S. Provisional Application No. 61/228,169 filed Jul. 24, 2009 and U.S. Provisional Application No. 61/343,400 filed Apr. 28, 2010, the entire disclosures of which are hereby incorporated by reference for all proper purposes.
Number | Date | Country | |
---|---|---|---|
61343400 | Apr 2010 | US | |
61228169 | Jul 2009 | US |
Number | Date | Country | |
---|---|---|---|
Parent | 13386707 | Jan 2012 | US |
Child | 15264044 | US |