Hand-raising response device and program

Abstract

This system provides a means of detecting and notifying students and other users of raising their hands to ask questions, making the process more enjoyable in university and other similar environments. [Solution] The hand-raising reaction device 10, which is attached to a person's upper limb, includes a sensor 11, a control unit 12, and a sound-emitting unit 14. The sensor measures motion or angle such as acceleration and angular velocity of the upper limb. The control unit performs a detection process to detect when the upper limb is in a raised hand state based on the sensor's measurement value, and a sound-emitting process to emit a signal sound from the sound-emitting unit to notify others of the detection. Additionally, the device may be provided with a light-emitting unit to perform light-emitting processing, or a storage unit 13 to store a counter, increasing the counter each time the hand is raised, and using that value to change the manner of sound-emitting processing and light-emitting processing.

Description

Technical Field

[0001] This invention relates to a hand-raising reaction device worn on the upper limb and responsive to hand-raising.

Background Art

[0002] As a result of prior art literature research, 75 related documents were found regarding this application. After excluding misdetections and family documents, the number was narrowed down to 33. Half of them are introduced below. The complete research results are attached to the early examination statement.

Prior Art Documents

Patent Documents

[0003]

Patent Document 1

Patent Document 2

Patent Document 3

Patent Document 4

Patent Document 5

Patent Document 6

Patent Document 7

Patent Document 8

Patent Document 9

Patent Document 10

Patent Document 11

Patent Document 12

Patent Document 13

Patent Document 14

[0004] The inventors, who are university students, noticed that in face-to-face classes at their university, due to the large number of students and the layout of the classroom, it was difficult for instructors to notice when students raised their hands to ask questions, resulting in a small number of students raising their hands.

[0005] Therefore, a means of notifying teachers when a student raises their hand is needed. The inventor thought that by emitting a signal sound, raising a hand to ask a question could be made more enjoyable.

[0006] The following is a comparison with prior art documents. None of the documents disclose an invention, as in this application, that uses a sensor attached to the upper limb to detect a raised hand and emits a signal sound to notify others of that fact. The essence of this invention lies in this combination.

[0007] Reference 1 ('058): Discloses a “hand and foot movement sensor” that is “at least partially wearable by the user” (p7). Discloses that the sensor can detect arm-raising movements (p19). However, it does not disclose that the sensor emits sound when a hand is raised, nor does it disclose its use as a signal to inform others that a hand has been raised, as it is a controller for a game device. Reference 2 ('508): This document discloses the use of an accelerometer attached to the arm to detect various actions such as eating and smoking, but it makes no mention of raising the hand, nor is it intended to notify others of these actions. Reference 3 ('848): See

[0028] ,

[0030] . This document mainly concerns a device that recognizes arm movements using electromyography, and although it mentions acceleration sensors, it is questionable whether it belongs to the same technical field as the present invention. Furthermore, it does not disclose what is done as a result of recognizing arm movements, and in particular, it neither discloses nor suggests how to signal that a raised hand has been detected. Reference 4('419): See

[0014] ,

[0017] . A device is disclosed that detects periodic occurrences of movements such as "movements of the arm moving up, down, left, and right." However, raising one's hand is not a periodic movement, and in the present invention's device, it is necessary to notify the user of a hand raise even if it occurs only once. For this reason, Reference 4 lacks the qualifications to be cited as a prior art invention, and we believe that there are many obstacles to the development of the present invention from the invention disclosed in Reference 4. Reference 5 ('232): Section

[0027] describes the case when the arm is moved up and down, and section

[0032] discloses the generation of sound according to the direction of movement. However, in Reference 5, microphone audio is used as input, it is analyzed, and sound is output, so the sound output function is considered to be integrated with the sound input function. We believe that separating this and replacing the input with a motion sensor such as an acceleration sensor, and making the output sound unrelated to the input, is outside the scope of Reference 5. Furthermore, it is not shown that the sound output in Reference 5 is a signal sound that notifies others that a hand has been raised, as in the present invention. On the contrary, as shown in

[0033] , the output sound in Reference 5 is the input sound with effect processing applied, and since the input sound is assumed to be wind noise, even if effect processing is applied, we do not think it can be used as a notification signal sound. Reference 6 ('993): The invention described in this document controls a robotic arm in accordance with the movement of a person's upper limb (see

[0035] , etc.). It does not disclose the ability to emit sound in response to a raised hand, and we believe that the control of the robotic arm described in this application is technically different. Reference 7('602): This is a control input for a blood pressure monitor.

[0055] discloses "recognition of a gesture of raising the wrist to heart level," but we believe that the detected action differs from that of the present invention. Furthermore, the means of sound generation and signal application are not disclosed, and the blood pressure monitor and the present invention belong to different technical fields. Reference 8 ('880): The device disclosed in this document is a device for detecting motor movements such as running, throwing, and jumping. The device of this application is specialized in detecting hand raising and differs from detecting movements that are part of motor movements such as running, throwing, and jumping. Furthermore, although the use of electronic sounds is disclosed, the sound emitted by this device is intended to notify the user of the movement. Therefore, in order for the device to reach a third party to notify them of the hand raising detection, it would be necessary to increase the volume, but there is no apparent motivation for doing so. Reference 9 ('650): The differences are that the alarm condition is when the hand comes into close proximity to mucous membranes such as the face, and that it does not notify third parties. Reference 10('625): See

[0032] ,

[0079] . Signaling upper limb elevation is not disclosed, and the technical field is different. Reference 11('604): This is a device for evaluating upper limb elevation movements, but it does not disclose how to detect upper limb elevation as an event, nor does it have a means of producing sound. Reference 12 ('761): The signal is sent to the game console and is not contained within the device itself. Reference 13('060):

[0037] ,

[0038] discloses the evaluation of operations involving moving the arm up, down, left, and right, but sound is part of the game and not for signaling purposes. Reference 14('529): The device is not worn on the upper limbs, nor does it emit sound in response to raising the arm itself. Reference 15('117): It is not explicitly stated that the device is worn on the hand. It is also not disclosed that a signal sound is emitted when the arm is raised. Reference 16('421): Sound reproduction is not disclosed. [Means for solving the problem]

[0008] The present invention comprises a sensor, a control unit, and a sound-generating unit.and a light-emitting unit and a memory unit that stores at least a counter. having The sensor is worn on a person's upper limb and can measure one or more of the movements or angles of the upper limb. The control unit performs a detection process of detecting that the upper limb is in a raised hand state based on the measurement value of the sensor, and when the detection is made The detection a sounding process of emitting a signal sound for notifying others from the sounding unit and, When the above detection occurs, a light emission process is executed to cause the light-emitting unit to emit light. The control unit increments the counter by 1 when the detection occurs. The light emission process is characterized by changing the color of the light emitted by the light-emitting unit, the blinking interval of the light emitted, or the brightness of the light emitted, according to the value of the counter. It is a raised hand reaction device.

[0009] Also disclosed is a program for causing a device having a sensor, a control unit, and a sounding unit and, light-emitting part and memory part to function as the above-described raised hand reaction device.

[0010] By using this device, raising a hand can be detected and notified to others, making it easier for others to notice the raised hand. Also, it is considered that the adoption of a signal sound makes raising a hand more enjoyable.

Brief Description of the Drawings

[0011] [Figure 1] It is a block diagram of the raised hand reaction device according to the present invention. [Figure 2] It shows a state where the sensor is worn on the upper limb. [Figure 3] It shows various arrangement forms of each part of the device other than the sensor. [Figure 4] It shows a state where each part of the device other than the sensor is placed on a table. [Figure 5] It shows a block diagram of the raised hand reaction device in a certain embodiment. [[ID=5M]] [Figure 6] It shows a block diagram of the raised hand reaction device in a certain embodiment. [Figure 7] It shows a two-dimensional code reader or an IC card reader used as a user identification information input means or a connection destination information input means. [Figure 8]This is a flowchart for executing periodic processes. [Figure 9] This is a flowchart for the programmatic control of a hand-raising response device. [Figure 10] This is an example of a measurement value that would not be expected under normal use. [Figure 11] This describes the method for representing angles in this embodiment. [Figure 12] This is a flowchart for implementing a judgment cooldown. [Figure 13] Examples of interruption conditions are shown. [Figure 14] This indicates that the user's hands are down. [Figure 15] This shows the user in the process of raising their hand. [Figure 16] This shows the user raising their hand. [Figure 17] This is a machine diagram of a state of one embodiment. [Figure 18] This is a flowchart for using the light-emitting part. [Figure 19] This block diagram shows that the hand-raising response device and the server communicate wirelessly or via the internet. [Figure 20] This is an example of connection destination information. [Figure 21] The system appears to be reading connection information and user identification information from the IC card used for the student ID. [Figure 22] The 2D code appears to be used to input connection destination information and user identification information separately. [Figure 23] This is an example of a startup message. [Figure 24] This is an example of a hand-raising detection message. [Figure 25] This is an example of a message for entering user identification information. [Figure 26] This is an example of a Ping message. [Figure 27] This is an example of a battery level message. [Figure 28] This is a block diagram of the system including the hand-raising reaction device. [Figure 29]This is a block diagram of the server. [Figure 30] This is a block diagram showing the system when a user information management system is connected to it. [Figure 31] This shows how a client uses server functions via a web browser. [Figure 32] This shows how a client uses server functions via a mobile app. [Figure 33] This shows how a client uses server functions via a chat application interface. [Figure 34] This is an example of a device registration webpage. [Figure 35] This is an example of a webpage for confirming participation by raising hands. [Figure 36] This illustrates how a raised hand signal is transmitted from the hand-raising response device to the server and then to the client. [Figure 37] This is an example of a webpage that uses methods for verifying the identity of the participant and the identity of the person being verified. [Figure 38] Another embodiment, a system that does not include a hand-raising reaction device, is shown. [Figure 39] This is a block diagram of a device without sensors. [Figure 40] This is a flowchart of the server's processing in an embodiment of a quiz game. [Figure 41] This is an example of a screen displayed to the client in a quiz game implementation. [Figure 42] This is a circuit diagram relating to an embodiment. [Figure 43] The component layout of the embodiment is shown. [Figure 44] The component layout of the embodiment is shown. "Trademark" indicates that the trademark of the control board 353 was printed in that orientation. [Figure 45] This example demonstrates that the method of representing angles differs from that of the embodiment. [Figure 46] This is a flowchart for periodic processing. [Figure 47] The state machine of the embodiment is shown. [Figure 48]Program page 1. [Figure 49] Program page 2. [Figure 50] Page 3 of the program. [Figure 51] Page 4 of the program. [Figure 52] Program page 5. [Figure 53] Page 6 of the program. [Modes for carrying out the invention]

[0012] Embodiments of the present invention are described below. Reference numerals correspond to those in the drawings. The following embodiments are merely examples and are not limited to those described below. Necessary design modifications may be made without departing from the spirit of the invention, or components from the same or different embodiments may be combined as needed. Furthermore, "includes," "has," and "equips" do not exclude the existence of other configurations, but are interpreted as "includes (has, equips) but is not limited to these." Also, the order of steps such as control and information processing can be arbitrarily rearranged within the scope that achieves their objectives.

[0013] <Hardware Configuration> The hand-raising response device 10 according to this application (hereinafter simply referred to as "this device") has at least one sensor 11, a control unit 12, and a sound-producing unit 14. A block diagram is shown in Figure 1. The sensor detects the movement or angle of the upper limb and is, for example, an acceleration sensor, an angular velocity sensor, an angle sensor, or a combination thereof. An example of a sensor that can be used in this device is the MPU6050, which is a 3-axis acceleration / 3-axis gyroscope sensor. The control unit is a component for performing control and is, for example, a processor (including a microprocessor / microcontroller) that executes a program, or an FPGA. The sound-producing unit is a component that emits sound and is, for example, a buzzer or a speaker. Furthermore, this device usually has a storage unit (including registers / memory) 13 connected to the control unit.

[0014] This device can be constructed using a so-called microcontroller board, which has components such as a microcontroller arranged on it. An example of a microcontroller board is the Arduino® Uno. A microcontroller is an integrated circuit that combines components such as a processor (which functions as a control unit) and RAM (which functions as a memory unit). Microcontrollers may also include flash memory for programming. Examples of microcontrollers include the ATMEGA328P used in Arduino and the ESP32®.

[0015] Furthermore, this device can be manufactured using System on Chip (SoC) components. An SoC is a single integrated circuit chip that combines the functions of a processor (which functions as a control unit), a microcontroller (such as RAM, which functions as memory), and additional components. A commercially available board that utilizes an SoC is the Raspberry Pi®. Note that the aforementioned sensors may also be mounted on the microcontroller or SoC.

[0016] Naturally, this device can also be implemented as a computer having the aforementioned sensors and sound-producing unit, such as a personal computer, mobile phone, smartphone, or tablet device. Typically, computers have a sound-producing unit (speaker) connected, and most smartphones and tablet devices have accelerometers and angular velocity sensors. As is well known, a computer includes a processor that functions as a control unit, and main memory (RAM) and auxiliary memory that function as storage units.

[0017] The program may be recorded on a recording medium. Examples of recording media include flash memory, RAM, ROM, HDD, SSD, CD, DVD, USB memory, and memory card. The control unit reads the program instructions recorded on the recording medium and executes them.

[0018] The sensor 22 is attached to the upper limb 21, as shown in Figure 2, to detect the movement or angle of the upper limb 21. Possible attachment locations for the sensor include the hand, fingers, wrist, forearm, elbow, and upper arm. Adhesive tape, hook-and-loop fasteners, strings, metal, rubber, cloth, paper, or plastic bands, rubber bands, etc., can be used to attach the sensor. Alternatively, the sensor can be attached to the upper limb area of ​​the user's clothing, such as the sleeve, or to a wristband, armband, or glove. Other parts of the device, namely the control unit and sound-generating unit, may be placed in the same location as the sensor or in a location separate from the sensor. In particular, as shown in Figure 3, the other parts of the device may be slung over the shoulder (31a), hung around the neck (31b), or placed overhead (31c). It is also acceptable to store the other parts of the device, other than the sensor, in the user's clothing pockets or backpack, attach them to the arms, torso, or legs, or attach them to clothing, hats, helmets, headbands, glasses, or masks. The sensor may be attached to one upper limb, and the other parts of the device, other than the sensor, to the other upper limb. The other parts of the device 31d may be placed on the knee, or, as shown in Figure 4, they may simply be placed on a table or in a desk drawer, attached to the lid of a laptop computer, or mounted on a chair. The control unit and the sound-producing unit may be placed in the same location or in different locations. Preferably, the sound-producing unit is placed in the same location as the sensor, or on the head. If placed on the head, it is desirable that the sound-producing unit be placed on top of the head or on the forehead.

[0019] The sensor is connected to the control unit via a wired interface such as I2C, SPI, USB, or RS-232, or via a wireless interface such as Wi-Fi, ZigBee®, Bluetooth®, or infrared. A sensor that outputs analog values ​​may also be connected via an A / D converter. Microcontroller boards such as Arduino typically have dedicated pins for inputting analog values, which can be used. In some cases, the sensor may integrate measured values ​​such as acceleration or angular velocity to obtain an angle, which is then used as the sensor's measurement value. A configuration is also conceivable in which the sensor's measurement value is stored in a buffer, such as a FIFO buffer, and the control unit reads the value from that buffer.

[0020] The sound-producing unit is, for example, a buzzer or a speaker. A simple piezoelectric buzzer or speaker can function as the sound-producing unit, but ideally, an 8Ω speaker combined with an amplifier circuit to amplify the sound is preferable. One sound-producing unit or multiple units may be provided. If multiple units are provided, they may be placed in the same location or in different locations. The volume of the sound-producing unit may be controlled by the control unit. This can be achieved, for example, by using a resistor, such as a digital potentiometer, in the amplifier circuit and adjusting the resistance value with the control unit.

[0021] The power supply for this device is preferably provided by dry cell batteries or rechargeable batteries (including mobile batteries), but may also be supplied from another device such as a personal computer or smartphone via a well-known interface such as USB, or from a power outlet.

[0022] The following describes the various parts that can be additionally connected to this device 10. Please refer to the block diagram in Figure 5. Firstly, a light-emitting unit 15 can be provided in this device. The light-emitting unit is, for example, an LED. The light-emitting unit can be turned on and off by the control unit. It may also be possible to change its color and brightness by the control unit. The arrangement of the light-emitting unit is the same as the arrangement of "parts of this device other than the sensor" described above. It is preferable to place the light-emitting unit in the same location as the sound-emitting unit, but this is not required. Secondly, the device may be equipped with a vibrating unit 16. The vibrating unit is, for example, a vibration motor, which can vibrate under the control of the control unit. The vibrating unit is preferably attached to the body, and particularly preferably to the same upper limb to which the sensor is attached. Naturally, it is possible to implement the sound-producing, light-emitting, and vibrating components all at the same time. In another embodiment applying the present invention, the device may not have a sound-producing unit, but only a light-emitting unit, or a light-emitting unit and a vibration unit. In this case, the sound-producing process described later is not performed, and instead, corresponding processes, such as light emission processing and vibration processing, are performed.

[0023] Referring to Figure 6, an additional configuration may be provided to the device 10: a communication unit 17. The communication unit is the part that communicates with external devices via wired or wireless means. Wired communication can be performed via, for example, USB or Ethernet, and wireless communication can be performed via, for example, wireless LAN, ZigBee, Bluetooth, or infrared. One of the above communication methods may be adopted, or two or more may be adopted simultaneously. The communication unit can transmit and / or receive signals under the control of the control unit. The communication unit may also be able to connect to the internet or a mobile phone network. Specific communication protocols will be described later. As an additional configuration, the device may be provided with user identification information input means 18 for inputting information that identifies the user. This may be, for example, a barcode reader, a two-dimensional code reader 41, an IC card reader 43, or a biometric information reading sensor such as a fingerprint sensor, as shown in Figure 7. The code reader may be a dedicated device or a general-purpose camera. The IC card may be, for example, a student ID card 44. The user identification information input means may also be implemented as a communication function. In this case, an external device such as a computer accesses the device and inputs user identification information into it. As an additional configuration, the device may be provided with connection destination information input means 19 for inputting information necessary for connecting the communication unit. This may be, for example, a barcode reader, a 2D code reader, or an IC card reader. This may be shared with the user identification information input means, and the same 2D code reader or the like may be used. As an additional configuration, the device may be equipped with a location information acquisition unit 20. The location information acquisition unit acquires the location information of the device. This can be done using GPS or other GNSS, radio waves from a mobile phone base station, or wireless beacons.

[0024] <Program Control> The following describes the processing performed by the control unit. The control unit's processing can be implemented as periodic processing or event-driven processing. Periodic processing 62, as shown in Figure 8, is a process executed periodically and can be implemented, for example, by an infinite loop, the Arduino loop function, or a handler scheduled to run periodically. Event-driven processing is a process executed in response to a specific event and can be implemented, for example, by an interrupt handler or a hat block in the programming language Scratch®. This specific event occurs, for example, when a sensor measurement changes, the sensor measurement meets / fails a predetermined condition, and / or an abnormal condition occurs. Furthermore, initialization processing 61 can be performed when the control unit is started and / or initialized. This can be implemented, for example, by the Arduino setup function.

[0025] The following describes the processing and program of the apparatus according to the present invention in an embodiment that uses periodic processing. One execution of periodic processing is defined as one cycle. The number of cycles can be used as a unit of time. Please refer to Figure 9.

[0026] In step 71, the control unit acquires measured values ​​related to the motion or angle of the sensor via the interface described above. In this specification, the vertical axis is defined as the Z-axis. Measured values ​​related to the sensor's motion include acceleration and angular velocity. When stable, the Z-axis value of the acceleration sensor reflects gravity. Measured values ​​related to the sensor's angle are given as Euler angles, i.e., yaw, pitch, and roll. Alternatively, rotation can be represented using a rotation matrix, quaternion, etc. In this specification, angles are shown in Euler angles. The specific acquisition method depends on the hardware, but those skilled in the art can verify it by referring to the sensor's datasheet, publicly available documents, etc. The example shows the case using the MPU6050. In patterns where measurements are stored in a buffer, buffer overflow handling may be performed at this step. Buffer overflows can occur due to various factors, such as a decrease in the frequency of periodic processing or poor connection to the sensor. If buffer overflows occur chronically, it is necessary to increase the frequency of periodic processing or improve the efficiency of the processing. When a buffer overflow occurs, it is desirable to create space in the buffer. This can be done, for example, by clearing the buffer or retrieving more buffer items than usual. Also, since the measurements obtained during a buffer overflow may be unreliable, it may be considered to discard them and skip the remainder of the current cycle of periodic processing. (This is equivalent to continuing in an infinite loop.)

[0027] In some embodiments, the measured values ​​are further validated. For example, if a measured value is abnormal, such as a value exceeding the sensor's detection range or a value not expected under normal use of the device, the measured value can be discarded and the periodic processing can be interrupted. Specific numerical values ​​are disclosed in the embodiments, but for example, considering the normal range of motion of the human upper limb, a pitch significantly exceeding 90° is not expected under normal use (see Figure 10), and can therefore be considered abnormal. For example, 120°, 135°, or 150° can be used as this threshold. Furthermore, in the event of a buffer overflow or detection of an abnormal measured value, the periodic processing can be stopped (or detection processing, etc., can be skipped) for a predetermined stable cool-down period, and the device can wait for its operation to stabilize. (This stable cool-down is usually separate from the judgment cool-down described later.)

[0028] After obtaining the measurement value, the control unit determines in step 72 whether it corresponds to a raised hand. The steps together constitute the detection process. In the simplest determination method, this is determined when the pitch of the Euler angle exceeds a certain reference value, for example, 45°, 60°, or 75° in the vertically upward direction from the horizontal plane. Note that in this embodiment (excluding the example), please refer to Figure 11 for the method of expressing angles. Alternatively, this determination may be conditional on the measurement value corresponding to a raised hand, for example, the pitch of the Euler angle exceeding a certain reference value, for a predetermined period of time. If the pitch falls below the reference value during that time, the determination fails and the process is restarted from the beginning. In another detection method, this is determined when the angular velocity corresponding to the change in pitch is positive for a predetermined time, i.e., the time it takes for a person to raise their hand (this period is called the angular velocity determination period), and then changes to negative, thereby detecting a raised hand. In the inventors' measurements, the time it takes for a person to raise their hand is 0.5 seconds. The timeframe was 3 seconds. Note that the positive / negative determination may be unstable due to measurement errors during actual measurements. In the inventors' measurements, in the case of raising a hand, the angular velocity corresponding to the pitch change exceeded 10° / s, remained above 10° / s until the hand was fully raised, and then fell below 10° / s. On the other hand, when the device remained on a flat surface, the absolute value of the angular velocity was less than 10° / s. Therefore, it is believed that adopting 10° / s as the threshold instead of 0 would allow for more accurate detection. In other words, in this detection method, after the angular velocity corresponding to the pitch change changes from less than 10° / s to more than 10° / s, it maintains that state for 0.5 to 3 seconds (angular velocity determination period), and then falls below 10° / s, which constitutes detection of raising a hand. If the angular velocity determination period is too short (e.g., less than 0.5 seconds) or too long (e.g., more than 3 seconds), it is not considered a hand raising. In this case, hand raising detection is avoided until the angular velocity approaches 0° / s, for example, the absolute value is less than 10° / s.

[0029] In step 73, the control unit sends a signal tone to the sound-producing unit to notify others that a hand has been raised. (Sound production process) This can be done, for example, using the tone function of Arduino. In one embodiment, in addition to the audio output, a HI / LO output is made to indicate whether a sound should be emitted, and the sound-producing unit circuit takes a logical AND of the audio output and the HI / LO output. This prevents noise from being emitted when the control unit does not emit a sound. In one embodiment, the sound is a sound of a predetermined frequency that lasts for a predetermined time, for example, 1 second, 2 seconds, or 5 seconds. The predetermined time and predetermined frequency can be changed as appropriate by the implementer. In one embodiment, the frequency of the emitted sound changes midway through. In one embodiment, the predetermined time is defined by the number of execution cycles of the periodic processing, for example, 30, 50, or 100 executions of the periodic processing. The number of steps can also be changed by the implementer as appropriate. Furthermore, audio files in WAV, MP3, or other formats may be read and played. These audio files may be written to the same recording medium as the program, or they may be read from a different recording medium, such as an SD card. In this embodiment, the sound generation process is non-blocking, meaning it does not wait for the sound to finish playing; however, it may also be blocking, meaning it waits for the sound to finish playing. Given the purpose of notifying others that a hand has been raised, it is desirable that this sound be played at a high volume. (In contrast, conventional smartwatch-type terminals, for example, are intended for the user's personal use, so the signal sound is relatively low volume.)

[0030] In one embodiment, as shown in the flowchart of Figure 12, after sound processing, the device enters a judgment cooldown state for a certain period of time. Hand raising is not detected during the judgment cooldown state. To implement this, for example, a cooldown variable is prepared and set as the number of cycles to cool down at the start of sound processing, when sound playback ends, or after a predetermined time has elapsed since the start of sound processing (86). At the beginning of each cycle, it is checked whether this variable is positive (81), and if it is positive, the variable is decremented (82), and the remainder of the current cycle of periodic processing is skipped. In this case, for example, free space may be created in the buffer.

[0031] In one embodiment, after the sound processing, the detection process is not performed until the hand is interrupted once. The condition for the hand being interrupted once (interruption condition) may be a negation of the hand detection judgment condition, a stricter condition (i.e., a negation of the hand detection judgment condition with further limitations on the measured value), or a condition different from the hand detection judgment condition (for example, angular velocity may be used for hand detection judgment, and angle for interruption condition judgment). For example, as shown in Figure 13, new hand detection may not be performed until the pitch of the Euler angle no longer exceeds a certain reference value, for example, 15°, 30°, or 45° vertically upward from the horizontal plane. This prevents multiple detections from occurring if the hand is being raised continuously. If the conditions are confirmed continuously for a predetermined period, for example, if the pitch of the Euler angle remains below a certain reference value for a predetermined number of cycles, it may be determined that the raising of the hand has been interrupted. This state in which the interruption condition for a predetermined period has been confirmed is called the "hand raising interruption confirmation state." In this case, if the interruption condition is no longer met during that predetermined period (for example, if the predetermined number of cycles is 10, the pitch reference value is 15°, and in the 9th cycle the pitch of the Euler angle becomes 20°, which does not meet the condition), the determination is restarted from the beginning. In other words, it is determined that the raising of the hand has not been interrupted until the predetermined period interruption condition is met again. Similarly, in the event of an error, for example, a buffer overflow or the detection of an abnormal measurement value, the process may be restarted from the beginning. In one embodiment, the judgment cooldown state and the hand-raising interruption confirmation state are simultaneous. For example, if the cooldown is 50 cycles and the predetermined cycle for hand-raising interruption confirmation is 10 cycles, the next detection process is performed in the 51st cycle if the interruption condition has been met for 10 consecutive cycles up to the 50th cycle, or in the next cycle after the interruption condition has been met for 10 consecutive cycles otherwise. In another embodiment, both are confirmed sequentially. In this case, the former may be confirmed first (i.e., the interruption confirmation is performed after the cooldown has elapsed), or the latter may be confirmed first (i.e., the cooldown is performed after the interruption confirmation).

[0032] Figures 14 to 16 show a user 32 using the device raising their upper limb 21. Figure 17 shows the state machine, illustrating various embodiments as illustrated above.

[0033] <Additional configuration> Figure 18 shows a flowchart of an embodiment in which a light-emitting unit is provided. In this embodiment, in step 74, the control unit causes the light-emitting unit to emit light. (Light emission processing) In one embodiment, the control unit causes the light-emitting unit to blink at regular time intervals, that is, to repeatedly turn on and off, as a type of light emission. This interval is, for example, 0.5 seconds, 1 second, or 5 cycles, 10 cycles, or 50 cycles, but the value can be chosen appropriately. Note that it may be possible to switch between performing sound emission processing and light emission processing (including performing both) using a switch provided in the device. Also, the on time (on-off interval) and off time (off-on interval) during blinking may be the same or different.

[0034] In one embodiment, the device stores a counter in a memory unit. The counter's initial value is 0, and it increments by 1 each time a hand is raised. The counter can be incremented stepwise, for example, by the control unit. In one embodiment, the counter value is used in the sound generation process. In one embodiment, the sound to be reproduced can be changed depending on the counter value. For example, if the counter is at its minimum value (1), i.e., for the first hand raise, sound A is reproduced; if the counter is greater than the minimum value (2 or more), sound B is reproduced. In one embodiment, the volume can be changed depending on the counter value. This may be done by the control unit adjusting the volume when sending sound to the sound generation unit (software control), or by the control unit adjusting the resistance value of the amplifier circuit in the sound generation unit (hardware control). In one embodiment, the volume when the counter is at its minimum value (1) is lower than when the counter is greater than the minimum value (2 or more). Generalizing this, in one embodiment, the volume may be minimum when the counter is at its minimum value (1), increase as the counter increases, and reach a maximum when the counter is N or greater. (N is an integer greater than or equal to the minimum value + 1 (2), and is determined appropriately considering the mode of use, the resolution of the digital potentiometer, etc.) This makes it easier to notice, for example, a user who raises their hand multiple times because they were not called on in class, as the volume increases with each raised hand until it reaches its maximum. However, in some classes, there may be relatively few opportunities or participants to raise their hands. In such cases, to make the first user to raise their hand more noticeable, the volume may be set to a value other than the minimum (e.g., maximum, or somewhere between minimum and maximum) when the counter is at its minimum value (2), to the minimum when the counter is one value above the minimum (3 or more), and to the maximum or to increase as the counter increases when the counter is two or more values ​​above the minimum (3 or more). The volume when the counter is two values ​​above the minimum (3) may be the same as the volume when the counter is at its minimum value (1), or the former or the latter may be made larger. Note that "minimum" and "maximum" are not necessarily the minimum and maximum volumes specified by the sound-producing unit or control unit, but can be set appropriately within the range of sound production. Both the sound and volume may be changed according to the counter value.Furthermore, in this case, the counter was incremented before the pronunciation processing, so the minimum value of the counter at the time of pronunciation processing was 1 (the various values ​​in this case are indicated in parentheses as "minimum value (1)" and "minimum value + 1 (2)"). However, if the counter is incremented after the pronunciation processing, the minimum value of the counter at the time of pronunciation processing is 0. Also, the counter may stop at N (even if N is the maximum value of the counter), or it may allow values ​​exceeding N for use in communication functions, etc., as described later.

[0035] In embodiments equipped with a light-emitting unit, the brightness of the light-emitting unit can be varied according to the value of the counter. Similar to volume, the brightness can be set to the minimum when the counter is at its lowest value (1) and to the maximum when the counter is at M (this M is also an integer greater than or equal to the minimum value + 1 (2), and is determined appropriately considering the manner of use, output resolution, etc. N may be the same as or different from M). Alternatively, the brightness may be set to a value other than the minimum (e.g., the maximum, or an intermediate value between the minimum and maximum) when the counter is at its lowest value (1), and to the minimum when the counter is at its lowest value + 1 (2). Furthermore, the blinking behavior or blinking interval of the light-emitting part may be changed according to the counter value. For example, the light may blink when the counter is at its minimum value (1), and remain lit without blinking when the counter is at or above the minimum value + 1 (2), or conversely, it may remain lit when the counter is at its minimum value (1) and blink when it is at or above the minimum value + 1 (2). Alternatively, the blinking interval may increase as the counter increases, for example, to counter * 0.1 seconds. Preferably, after the counter reaches a predetermined value (for example, 10), the blinking interval becomes a value independent of the counter, for example, a fixed value. The rate at which this interval increases can be set as appropriate by the implementer. Furthermore, the on-time and off-time during flashing may depend on the counter for only one of them, or on both. In the latter case, the way in which they change, such as the rate of increase or the value of the counter (the predetermined value) when the flashing interval is fixed, may be the same for both or different. Note that, here too, the counter was incremented before the light emission process, so the minimum value of the counter is 1 (the various values ​​in this case are indicated in parentheses as "minimum value (1)" and "minimum value + 1 (2)"), but it is also possible to increment it afterward, in which case the minimum value of the counter will be 0. When performing both sound emission and light emission processes, it is preferable to increment the counter either before or after both processes. In one embodiment, the light-emitting unit is a full-color LED or similar, with adjustable color, and the control unit can adjust the color of the light-emitting unit. In this case, the color may be changed according to the value of a counter. Furthermore, two or more of the brightness, blinking, and color may be changed.

[0036] Furthermore, the execution of either the sound-producing process or the light-emitting process (or both) may be changed depending on the counter value. For example, if the counter is 1, only light emission may be performed, and if the counter is 2 or greater, both sound emission and light emission may be performed; or conversely, if the counter is 1, only sound emission may be performed, and if it is 2 or greater, both sound emission and light emission may be performed. The execution of sound emission, light emission, or both may also be differentiated depending on whether the counter is even or odd.

[0037] In one embodiment, sound, volume, brightness, flashing, color, etc., can be changed according to the measured angle or measured angular velocity. For example, when raising a hand to respond in class, a user confident in their response is likely to raise their hand quickly. Therefore, the faster the speed of raising the hand, i.e., the faster the angular velocity corresponding to the change in pitch, the more confident the user is in their response. Alternatively, a user confident in their response is likely to raise their hand more vertically. Therefore, the larger the pitch measured from the horizontal, the more confident the user is in their response. Using this, if the maximum value of the angular velocity measured in a step, or the measured angle, exceeds a predetermined threshold, the volume or brightness can be increased, or the flashing interval can be shortened compared to when it does not exceed the threshold. Alternatively, the volume or frequency can be increased in accordance with the increase in the maximum value of the angular velocity or the angle. The system could also play a certain sound or emit a certain color when the measured angular velocity or angle is within a predetermined range, and play a different sound or emit a different color when it is within another predetermined range that does not overlap with the first range. Instead of using the maximum value of the angular velocity, statistical values ​​such as the median or third quartile can also be used.

[0038] <User Identification Information> It would be even more desirable if the device user, for example, a person who raises their hand, could be identified without visual inspection. Therefore, as an additional configuration, the device can be equipped with the aforementioned user identification information input means. This uses a barcode, 2D code, IC card such as a student or employee ID, or the user's biometric information, which are distributed separately to the user, to identify the user. The control unit receives the input from the user identification information input means and stores it in the memory unit. This information can be used, for example, for communication conducted by the communication unit, and if the user identification information is stored within the device, it can also be used later by the device lender to identify the device user.

[0039] <Communication> In some embodiments, the device has communication functions implemented by a communication unit. For example, the device can send a hand-raising detection message when it detects a raised hand. In some embodiments, the device can send a startup message when it starts up. In some embodiments, the device can send the battery level, for example, remaining time or percentage. In some embodiments, the device can periodically send PINGs. The transmitted information is received by the server. An example of an embodiment is shown in Figure 19. In some embodiments, the device is connected to the server by a wired connection, either directly or via a router. In some embodiments, the device is connected to the server wirelessly, either directly or via a router. In some embodiments, the server is connected to the device via the internet or a mobile phone network. A computer (including personal computers, mobile phones, smartphones, tablet devices, etc.) or a dedicated base station can be used as the server. When communication functionality is provided, it is desirable to distinguish between devices using a device identifier. This may be an identifier assigned and fixed at the time of shipment, or an identifier that can be assigned by the device lessor or user. The identifier may also be rewritten via the communication function. For example, a computer connected to this device by a wired connection can send identifier rewriting information to this device. This device receives the identifier rewriting information and changes the identifier to the given one. MAC addresses, IP addresses, Bluetooth addresses, etc., may be used as device identifiers. Furthermore, if this device has means for identifying the user, such as the user identification information input means mentioned above, user identification information may be used instead of a device identifier to distinguish between devices. A configuration that possesses both a device identifier and user identification information is also possible. It is also conceivable that multiple identifiers exist. For example, devices using the Internet Protocol are usually assigned a MAC address and an IP address, and a third device identifier or user identification information for use at the application layer may also be assigned. Device identifiers and / or user identification information are included in the information transmitted by this device. This includes situations where the device identifier is necessarily included in the transmitted information due to the adoption of specifications such as TCP / IP and Bluetooth. Furthermore, as will be discussed later, it is possible that the device may be used for personal purposes. It is also possible to communicate with the device outside of production use, such as when configuring the device. In this case, it is conceivable that the server and the device could be connected via USB or similar, allowing one server to communicate with only one device simultaneously.

[0040] Specific examples of communication methods are given, but communication methods are not limited to these. As a first example of a communication method, one using WebSocket is shown. The WebSocket server can be connected via wireless LAN, Ethernet, or a mobile phone network. In one embodiment, since the device is managed by a specific organization, such as a university or company, the connection destination information, such as wireless LAN access point information or WebSocket server address, as exemplified in Figure 20, can be fixed to the connection destination within the organization and embedded in the firmware. In one embodiment, the connection destination is a server managed by the device manufacturer or a third party, and the device connects to the server via the internet. In one embodiment, the connection destination can be rewritten by the user. In one embodiment, an automatic configuration means such as WPS can be used to connect to a wireless LAN. In one embodiment, connection information to a mobile phone network is provided to the device as connection destination information via a SIM card. In one embodiment, the connection destination information is acquired by the device via a connection destination information input means. In one embodiment, the user identification information input means and the connection destination information input means are implemented with the same configuration, for example, the same 2D code reader or IC card reader. For example, the connection destination information is acquired by the user identification information input When a power source acquires user identification information, it acquires it simultaneously. For example, when a user identification information input means reads a 2D code, both user identification information and connection destination information are recorded in the 2D code, so both can be acquired. Alternatively, as shown in Figure 21, when a user identification information input means 43 reads an IC card, such as a student ID 44 or employee ID, both user identification information (student number, employee number, etc.) and connection destination information are recorded in the IC card, so both can be acquired. An example is shown in Figure 22. In one embodiment, the device acquires user identification information by reading a first two-dimensional code 111 containing user identification information from a two-dimensional code reader 41, and acquires connection destination information by reading a second two-dimensional code 112 containing connection destination information. A similar configuration may be implemented using a barcode reader, IC card reader, or other means that serves as both a user identification information input means and a connection destination information input means. This connection destination may be within the organization, i.e., on-premise, or managed by the manufacturer or a third party. The acquired connection destination information is preferably stored permanently. A second example of a communication method is ZigBee. Due to its low power consumption and implementation cost, ZigBee is ideal for implementing this device using Arduino or similar boards. In its simplest configuration, each device acts as an end device, and the server acts as the coordinator. Other network topologies may also be used. In this case, the PAN ID may be fixed as connection destination information, but this is not mandatory. If the PAN ID is fixed, it is desirable to use different PAN IDs for different rooms. To facilitate this, it is advisable to implement a means for inputting connection destination information. In this case, it is desirable to use a barcode reader or a 2D code reader.

[0041] The following are examples of application-layer communication protocols. These can be adopted independently of the communication methods described above, but the details may need to be modified depending on the specifications of the communication method. For example, ZigBee is generally known to have a slower communication speed than Wi-Fi. For this reason, it would be advisable to serialize messages in the JSON format, which is easier to implement, for WebSocket over Wi-Fi, and as byte data, which saves bandwidth, for ZigBee. Fields can be sent as part of the body or as headers, such as HTTP headers during the WebSocket handshake. Examples of messages to be sent and received are shown here, but it is not necessary to implement all of them. Also, "messages may include fields" means that you may include all or any combination of the one or more fields exemplified, or you may not include any fields at all. This device may send a startup message at startup or when acquiring a connection destination (see Figure 23). The startup message may include a device identifier field, a startup time field indicating the startup time, a location information field indicating the location information acquired by the location information acquisition unit, and / or a device information field. The device information may include, for example, the device model number, version information, battery level, and / or operating status (malfunction detection status). The startup message may also function as a handshake for various communication methods, such as WebSocket. The device may send a hand-raising detection message when a hand-raising is detected (see Figure 24). Preferably, a hand-raising detection message is sent. The hand-raising detection message may include a device identifier field, a timestamp field indicating the detection time, a sensor measurement value field, a counter field which is a counter value, a location information field, and / or a user identification information field. The sensor measurement value field includes the raw value measured by the sensor and / or a converted value thereof. For example, when the sensor returns angular velocity as a signed 16-bit value, this can be converted to ° / s and sent. "Measurement" includes indirect measurements, in particular when the sensor measures acceleration and each velocity and obtains an angle. The obtained angle can be converted to an Euler angle, one or more components of the Euler angle, a quaternion, and / or a rotation matrix and sent. The timestamp field can indicate the timestamp as year, month, day, hour, minute, and second, or as a standard timestamp (e.g., POSIX timestamp), or as the elapsed time since the start time. If the device has a means for inputting user identification information, preferably, the device sends a user identification information input message when user identification information is input. (See Figure 25) The user identification information input message may include a device identifier field, a timestamp field indicating the input time, a user identification information field, a location information field, and / or a previous user identification information field indicating user identification information stored in the device before the input of the user identification information. The timestamp is as described above. This device may periodically send PING messages, for example, at predetermined intervals (see Figure 26). The PING message may include a device identifier field, a timestamp field indicating the transmission time, a user identification information field, and / or a location information field. This device may send a battery level message (see Figure 27). The battery level message may include a battery usage field indicating whether power is being supplied from the battery, a battery level acquisition status field indicating whether the battery level can be acquired, and / or a battery level field indicating the remaining battery level. The battery level message can be sent at startup, periodically, when charging starts, when charging stops, and / or when the battery level reaches a predetermined percentage or remaining time. The battery level message may also not be sent when the battery is not being used and / or when the battery level cannot be acquired. Furthermore, the server may add authentication fields that can be used for authentication. Authentication methods include password authentication and public key authentication using the signing key in the IC card used for user identification information input. When authentication is performed, the server performs authentication when it receives a message, and only if authentication is successful does each part process the message reception.

[0042] <System> In one embodiment, a system 100 can be configured including one or more of these devices 10 and a server 101 that communicates with these devices. In one embodiment, this system includes a client 102, which will be described later. A block diagram of this system is shown in Figure 28. As shown in block diagram 29, the server 101 can implement all or any combination of the following parts: a device registration unit 121, a device list display unit 122, a device details display unit 123, a device unregistration unit 124, a broadcast unit 125, a call unit 126, a hand-raising reception unit 127, and a user identification information reception unit 128. Here, the database includes relational databases, NoSQL databases, and other types of databases, as well as a recordable file system and memory capable of storing at least information between sessions. A session can be defined as the period during which the server is continuously running, or the period during which the device is continuously used by the same user in the same location. As an example of the latter, one class period, the rental time of a room where the device is used, or working hours at a company can be defined as one session. In one embodiment, the server also functions as a web server, and one or more of the above components are implemented as handlers for HTTP requests of the web server. In another embodiment, each component is implemented as a handler for a REST API. When a component "returns" content, it can be implemented by the server sending a response containing serialized data, such as text, web pages, images, audio, video, or information, corresponding to the content requested by a client accessing the server. Clients include computers (personal computers, mobile phones, tablet devices, etc.). Clients are typically used by teachers, speakers, etc. Furthermore, the server and client can be the same computer. That is, the server, which directly interacts with the device, and the client, which functions as an interface to the server, may be implemented on the same computer.

[0043] The device registration unit registers devices that are connected to or scheduled to be connected to the server. Registration may be performed automatically upon receiving a device startup message or other message, or it may be performed manually. In communication methods where the concept of pairing exists, registration may be performed along with pairing without waiting for message reception. Registration records at least the device identifier of the device. In addition, a registration number, name, user identification information, timestamp, etc. may be registered. Furthermore, in addition to, or instead of, user identification information of the person to whom the device is leased or the user who should be using this device (original user identification information) may be registered. The device list display unit returns a list of registered devices. The list includes all or part of the information for each registered device. Search and filter functions may be provided for this list. The device details display unit returns registration information for a predetermined device, such as a device specified in a URL parameter or request body. The device deregistration unit deletes the registration information of a specified device from the database. This can be done automatically (for example, after a predetermined period has elapsed since the last message was received) or at the request of the device or client. The broadcast unit sends a broadcast message, as described below, to one or more devices. The server automatically broadcasts when it receives a broadcast request containing information related to one or more fields of a broadcast message sent by a client, or in other predetermined cases. This broadcast may be sent individually and sequentially to all registered devices, or it may use a broadcast method specific to the communication method, such as IP broadcasting. Note that in communication methods where a specific destination cannot be specified (below the application layer), all communication can be considered a broadcast; in this case, a broadcast refers to one where the server does not specify the destination device identifier. Broadcasts will be discussed later. The call unit sends a call message, as described below, to one or more specific devices. The server makes a call when it receives a call request containing information relating to one or more fields of the call message sent by the client, or automatically in predetermined cases. The information includes the device identifier of the destination device or conditions for the server to calculate the device identifier (such as database filter conditions). In communication methods where a specific destination cannot be specified, the transmission content includes the device identifier of the device to receive the message, and the call is realized when the device compares the device identifier in the transmission content with its own device identifier.

[0044] The hand-raising reception unit receives and processes hand-raising detection messages from the device. In one embodiment, after receiving a hand-raising detection message, the hand-raising reception unit stores information relating to all or any combination of the message's fields in a database. In one embodiment, the hand-raising reception unit activates a lamp, speaker, etc. In one embodiment, activating the speaker includes reading aloud the device identifier or user identification information of the received message, such as name, keywords, or full name. In one embodiment, the hand-raising reception unit sends a response call message to the device that sent the hand-raising detection message at the time of reception. In one embodiment, a message indicating that the hand-raising has been received is broadcast at the time of reception. In one embodiment, as shown in Figure 30, this system 100 is part of a user information management system 103 such as an attendance management system, a grade management system, or a time and attendance management system, or similar Because it is connected to the system, when a raised hand is received, the user identification information and other information related to that user are passed to the user information management system, and appropriate processing can be performed. For example, when a raised hand is received, the user associated with that user identification information can be marked as present in the user information management system at the time the hand is raised. It is also conceivable that the receipt of a raised hand may be taken into consideration when evaluating the user's grade. For example, the user information management system records the cumulative number of times each user has raised their hand, and the server instructs the user information management system to increase the cumulative number of raised hands each time a hand is raised. Alternatively, using the counter in the raised hand acceptance message (or the number of times the user has raised their hand recorded by the system), it may be possible to limit the number of raised hands to a predetermined number, for example, one time, within a certain time period (for example, the same class period or training), or conversely, to increase the grade evaluation depending on the number of raised hands within a certain time period. The user identification information receiving unit receives and processes user identification information input messages from the device. In one embodiment, after receiving the user identification information input message, the user identification information receiving unit stores information relating to all or any combination thereof of the message's fields in a database. In one embodiment, the user identification information receiving unit activates a lamp, speaker, etc. In one embodiment, activating the speaker includes reading aloud the device identifier or the name, keyword, name, etc. relating to the user identification information in the received message. In one embodiment, the user identification information receiving unit sends a response call message to the device that sent the user identification information input message upon reception. In one embodiment, a message indicating that the user identification information has been received is broadcast upon reception. In one embodiment, the server performs special processing if the received user identification information differs from the original user identification information and / or is already associated with another device, particularly if it is associated with another device that is currently connected. For example, the server may ignore the user identification information input message or include that fact in the user identification information reception message sent to the client, causing the client to display a warning.

[0045] This section explains the client. The client connects to the server to utilize its various functions. This can be done via a web browser, as shown in Figure 31, or by using a dedicated application, such as a mobile app, as shown in Figure 32. Alternatively, a chat application can be used as the client interface, as shown in Figure 33. In this case, for example, the server receives messages sent to the chat application using the chat application's third-party application integration or bot account function, and the server's response is sent to the chat. The following explanation focuses on a client using a web browser, but a web browser is not required. In this case, "web page" should be read as "application screen" or "interface." The web pages provided by the server may include a device registration web page, a device list display web page, a device details display web page, a device deregistration web page, a broadcast web page, and a call web page. It is also acceptable to implement all or some of these web pages. Each web page is provided by the corresponding part of the server. For example, the device registration unit provides a device registration webpage as shown in Figure 34, and the client displays this webpage. The client's user, such as a teacher, enters information about the device, such as the device identifier, on the device registration webpage and presses the submit button. This sends the information to the server. As mentioned above, the information that can be entered is as described above, but in particular, in such manual registration, it is desirable to be able to register the user identification information of the user who should be using the device. The server may also provide a hand-raising confirmation webpage as shown in Figure 35. Figure 36 shows how it works. When the hand-raising reception unit of server 101 receives a hand raised by the hand-raising response device 10, server 101 sends a hand-raising confirmation message to client 102 in real time. WebSocket or the like can be used for this. The client, which displays the hand-raising confirmation webpage that has received the hand-raising confirmation message, displays on the hand-raising confirmation webpage that the hand has been raised. Alternatively, instead of WebSocket, the client may periodically poll the server to receive hand-raising confirmation messages. The content of the hand-raising confirmation message sent by the server may be the same as the hand-raising detection message, or fields may be added, modified, or deleted as needed, or the format may be changed (for example, from binary data to JSON). For example, the reception time on the server side may be included, or if the timestamp in the message is the elapsed time since the start time, it may be changed to a POSIX timestamp or hour-minute-second format. The server may provide a user identification information verification webpage. Similar to the hand-raising verification webpage, the server's user identification information receiving unit sends a user identification information reception message when it receives user identification information, and the client displaying the user identification information verification webpage receives this reception message. Furthermore, the timing for sending the response call payload may be set not when the server receives a message from the device, but when the client performs a predetermined action, for example, when a confirmation action is performed on the hand-raising confirmation webpage or the user identification information confirmation webpage, for example, when the displayed confirmation button is pressed. When this confirmation action occurs, the client instructs the server to send the response call payload. The server receives this instruction and sends the response call payload.

[0046] In embodiments using a client, the client user can visually confirm the raised hand, and the client can also confirm the raised hand. Therefore, in a configuration where the user identification information shown by the device is displayed on the hand-raising confirmation webpage, if the device user has another person's user identification information entered into the device, the client user can detect this. In one embodiment, the hand-raising confirmation webpage can be provided with means for verifying the identity of the person and / or verifying the identity of another person when the hand-raising is accepted. An example of this is shown in Figure 37. These can be implemented, for example, as GUI buttons or keyboard input. The identity verification means is used when the client user confirms, by another means, for example, visually, that the client user matches the person whose user identification information is presented. Conversely, the means for verifying the identity of another person is used when the client This is used when the user confirms, by other means, such as visual inspection, that there is a discrepancy between the client user and the person associated with the presented user identification information. In one embodiment, after the use of the identity verification means and / or the other-person verification means, the result (whether the identity verification means was used or the other-person verification means was used) is transmitted from the client to the server (or user information management system). The server can, if necessary, forward the result to the user information management system. For example, in a configuration where the system records attendance and evaluates grades based on raised hands, attendance recording and grade evaluation can be performed only if the identity verification means is used or if the other-person verification means is not used within a certain time after the hand is raised. Alternatively, it is conceivable that the user information management system would record the use of the other-person verification means.

[0047] This section explains broadcasts and calls. Broadcasts and calls can be used for various purposes. A broadcast message has a header and a payload. The header is not simple (i.e., the payload is the message). Alternatively, the header can include processing conditions for the broadcast message that should be evaluated by the receiving device. For example, a counter must be at a predetermined value or within a predetermined range. This allows messages to be sent to devices that meet the conditions without individually calling each device. The header may also include a timestamp or a digital signature that allows the device to verify that the message originated from a server. A call message also consists of a header and a payload. The header of a call message identifies the receiving device using one or more device identifiers. This can be implemented as transmission data at the application layer, or it can be implemented at another layer, such as the network layer, using existing communication methods that include the device's IP address in the header. In this case, the application layer data will consist only of the payload.

[0048] The following describes possible types of broadcast payloads, which may also be implemented as call payloads. In one embodiment, the broadcast payload can include all or any combination of the following: a time synchronization broadcast payload that synchronizes the server's time, a function deactivation broadcast payload that causes the receiving device to stop functions other than communication, a function reactivation broadcast payload that allows the receiving device to resume functions from deactivation, a mute broadcast payload (in a configuration with a sound-emitting unit) that prevents the receiving device from emitting sound, a mute deactivation broadcast payload that allows the receiving device to emit sound, a light-off broadcast payload (in a configuration with a light-emitting unit) that prevents the receiving device from emitting light, a light-off deactivation broadcast payload that allows the receiving device to emit light, and a vibration broadcast payload (in a configuration with a vibration unit). A device that receives a vibration broadcast payload activates its vibration unit. In this case, the sound-emitting unit and / or light-emitting unit may be activated simultaneously. If a device receives a message containing an unsupported broadcast payload or call payload, it may discard and ignore it, or send the message to the server and respond to the server.

[0049] Furthermore, a response call payload may be implemented as the response call message. This is sent by the server when it receives a raised hand and / or user identification information. When a device receives a message containing a response call payload, it is desirable that it performs actions such as emitting light, making a sound, and / or vibrating so that the device user can recognize it. It is also desirable that the actions corresponding to receiving a raised hand and the actions corresponding to receiving user identification information are different. After detecting a raised hand, it is possible to refrain from detecting raised hands again until a response call payload is received. However, in case the response call payload is not received due to communication failure or other reasons, it is possible to allow hand detection again after a cooldown period (e.g., 1 minute) has elapsed.

[0050] As illustrated in Figure 38, the above system can be applied to devices other than the hand-raising reaction device. For example, a transmitting device can be used instead of the hand-raising reaction device. The transmitting device typically includes a control unit 12 and a memory unit 13. The transmitting device sends messages through the operation of a human interface, such as a (physical) button 131, switch, pedal, or a computer's graphical user interface, such as a smartphone 132. In this case, the operation is used instead of hand-raising detection, and the message is used instead of the hand-raising detection message. Figure 39 shows a block diagram of the transmitting device. The display of the transmitting device may be used as the light-emitting unit 15, the speaker of the transmitting device as the sound-producing unit 14, and the vibrator of the transmitting device as the vibration unit. A general-purpose computer (including personal computers, mobile phones, tablet terminals, etc.) can be used as the transmitting device, and it is not necessary for it to have a sensor for hand-raising detection. Such a transmitting device and a hand-raising reaction device may be mixed in the system, or only one of them may be used.

[0051] <Applications of the device> Several applications of this device are shown below. As mentioned in the previous paragraph, this device can be applied to devices other than hand-raising reaction devices. The methods of application in those cases are also described in the previous paragraph. Firstly, it is well known that video conferencing systems, such as online meeting systems, have a function to indicate raising one's hand. This function is traditionally operated by clicking a button or using keyboard shortcuts. Therefore, this device can be used for operation input. In a simple embodiment, one of these devices is connected to one video phone terminal (for example, a computer running a video phone program). When the device detects a raised hand, it communicates with the video phone terminal to instruct the terminal to raise its hand on the video phone. In this case, the video phone terminal acts as both the server and the client. Alternatively, user identification information can be linked to an account on the video conferencing system, so that in a video conference with any number of users using the device, only the account associated with the user using the device can raise their hand.

[0052] Secondly, the device may be made available for use in quizzes. In this embodiment, the server accepts the first raised hands of N devices (where N is a predetermined integer greater than or equal to 1) detected within the answer period for a given question. The answer period may be a predetermined time, for example, 30 seconds, or it may be unlimited. Preferably, embodiments are implemented in which the response call payload is sent after the confirmation operation, and embodiments in which the server does not detect raised hands again until the response call payload is received. Furthermore, after accepting raised hands from N devices, the detection of further raised hands may be stopped. This can be implemented by the server preparing an acceptance counter, incrementing it each time a raised hand is accepted (144) (145), and sending a function stop broadcast payload when the acceptance counter reaches N (143). This shows the overall flow of a single question. In particular, the server's processing flow is shown in Figure 40. First, the server enables the detection of raised hands from devices related to users participating in the quiz (141). For example, it sends a function restart broadcast payload. The reception counter is reset to 0 at this point (142). Next, the server accepts raised hands from N devices. Preferably, this is implemented as a queue. Each time the server receives a raised hand detection message, or after the answer period ends, it sends user identification information and other information related to the device that raised its hand to the client (146). This may be the same as the raised hand detection message mentioned above, or in a different form. If N is 2 or more, i.e., if multiple users are answering, the client will receive the information at this point. It is desirable that Ant be able to determine the order of hand-raising regardless of the order in which the information is sent. To achieve this, for example, the information to be sent may include an order or timestamp, or the information may be sent in the order in which hand-raising was detected after the answer period has ended. In this case, if N devices have raised their hands, further hand-raising detection may be stopped as described above. The client displays the quiz screen, for example, the quiz web page provided by the server, and on that screen, the information sent from the server is displayed in the order in which hand-raising was detected. At this time, the displayed information usually includes user identification information related to the hand-raising. The client user receives the answer (outside the system) and determines whether it is correct or incorrect. If the answer is correct, the client user performs a correct answer action on the client (e.g.: The client performs an action on the screen (for example, by pressing the correct answer button displayed on the screen shown in Figure 41), or an incorrect action (for example, by pressing the incorrect answer button displayed on the screen shown in Figure 41) if the answer is incorrect. When the correct action is performed, the client sends a correct answer message to the server; when the incorrect action is performed, the client sends an incorrect answer message. When the server receives a correct answer message (147, 149 YES), it sends a response call payload (148) and terminates processing. (Proceed to the next question.) When the server receives an incorrect answer message (147, 149 NO), it also sends a response call payload (148), but there are two possible subsequent actions. In this case, processing may be terminated in the same way as with a correct answer message. (In this case, N=1.)As an alternative implementation, the server that receives an incorrect answer message may decrement the reception counter by 1 (150), and when the reception counter reaches a predetermined value, for example, 0 (151), it may send a function restart broadcast payload. As a result, if a person who raises their hand gives an incorrect answer, for example, if everyone gives an incorrect answer, the right to raise a hand is given to someone who has not yet raised their hand. Alternatively, the server that receives an incorrect answer message may decrement the reception counter by 1, and when the reception counter reaches 0, it may terminate the process. In other words, if all those who raise their hands give an incorrect answer, the system proceeds to the next question. If re-answering by the same person is permitted, the system may send a response call payload to the device related to the answerer (=the device that detected the raised hand related to the incorrect answer message) when it receives an incorrect answer message. If re-answering is not permitted, and the right to raise a hand is granted upon an incorrect answer, the system may store the device identifier or user identification information of the devices that detected raised hands within the answer period, and terminate the process after all devices have detected raised hands. The response call payload may also include whether the answer is correct or incorrect, and the receiving device may change its operation accordingly, for example, by emitting light, making sound, or vibrating. Furthermore, the server or client may transmit information on correct and incorrect answers to the aforementioned user information management system for use in performance evaluation, etc.

[0053] Instead of receiving answers outside the system, answers may be entered into a device (or another computer connected to the device) and submitted via a raise of hand. In this case, the answer may be included in the raise of hand detection message or sent separately to a server. The server presents the received answer to the client. In another embodiment, the server automatically verifies the correctness of the answer without presenting it to the client. In one embodiment, this is determined by whether the answer matches a predetermined value or satisfies predetermined conditions. In another embodiment, the correctness of the answer is determined by inputting the question and answer into a large-scale language model and determining whether its output indicates a correct or incorrect answer.

[0054] The invention relating to the hand-raising response device, etc., has been described above. Naturally, computers, devices, terminals, transmitters, servers, clients, etc., operate as the hand-raising response device, terminal, transmitter, server, client, etc., according to the present invention by being controlled by programs. Furthermore, computers, devices, terminals, transmitters, servers, clients, etc., operate as the hand-raising response device, terminal, transmitter, server, client, etc., according to the present invention by executing information processing methods. Conversely, the hand-raising response device, terminal, transmitter, server, client, etc., according to the present invention may be defined by the programs or information processing methods they execute. Also, in order to control the entire system including the hand-raising response device, terminal, transmitter, server, client, etc., programs are executed or information processing methods are executed by the hand-raising response device, terminal, transmitter, server, client, etc., that constitute the system.

[0055] <Note> Claim 1: Having a sensor, a control unit, and a sound-generating unit, The sensor is attached to a person's upper limb and is capable of measuring one or more of the movements or angles of the upper limb. The control unit performs a detection process to detect whether the upper limb is in an elevated position based on the measurement value of the sensor, When the above detection occurs, the sound generation unit performs a sound generation process to emit a signal sound to notify others of the detection. Hand-raising reaction device. Claim 2: Furthermore, having a storage unit that stores at least a counter, The control unit increments the counter by 1 when the detection occurs. The sound generation process is characterized by changing the sound or volume of the sound generation unit according to the value of the counter. The hand-raising reaction device according to claim 1. Claim 3: The change is a change in volume, When the counter reaches its lowest value, the volume is set to the minimum volume. When the counter exceeds the minimum value but falls below a predetermined value, the volume is increased as the counter increases. The volume is set to maximum volume when the counter of the counter is equal to or greater than the predetermined value. The hand-raising reaction device according to claim 2. Claim 4: The change is a change in volume, When the counter reaches its lowest value, the volume is set to the first volume. If the counter is 1 greater than the minimum value, the volume is set to a minimum volume smaller than the first volume. If the counter is 2 or more above the minimum value and below a predetermined value, the volume will be increased as the counter increases. The volume is set to maximum volume when the counter of the counter is equal to or greater than the predetermined value. The hand-raising reaction device according to claim 2. Claim 5: Further having a light-emitting part, The control unit further performs a light-emitting process to cause the light-emitting unit to emit light when the detection occurs. The hand-raising reaction device according to claim 1. Claim 6: Furthermore, having a storage unit that stores at least a counter, The control unit increments the counter by 1 when the detection occurs. The light emission process is characterized by changing the color of the light emitted by the light-emitting unit, the blinking interval of the light emitted, or the brightness of the light emitted, according to the value of the counter. The hand-raising reaction device according to claim 5. Claim 7: If the counter has not reached a predetermined value, the light emission process increases the blinking interval of the light emission unit as the counter increases. If the counter reaches the predetermined value, the flashing interval of the light-emitting unit will be made independent of the counter. Characterized by, The hand-raising reaction device according to claim 6. Claim 8: A program for causing a device having a sensor, a control unit, and a sound-generating unit to function as a hand-raising response device according to any one of Claims 1 to 7. [Examples]

[0056] Here, we introduce a simple embodiment prototyped by the inventors. In this embodiment, the device detects a raised hand based on pitch and, upon detection, performs sound generation via a speaker and illumination of a yellow LED. Furthermore, a counter is stored in memory (RAM), and the blinking interval of the LED is changed according to the counter value. The sound generation process involves playing a 1000Hz sound for 30 cycles, followed by a 1500Hz sound for 50 cycles.

[0057] The components used in this embodiment are as follows: The control board 310 is an ELEGOO (registered trademark) Uno R3. This includes an ATMEGA328P microcontroller (control unit and memory unit) 311. The GY-521 incorporates a 3-axis accelerometer / angular velocity sensor, the MPU6050, as sensor 320. This sensor is connected to the microcontroller via I2C. The sound-producing unit 330 is an AP-203 small speaker (diameter 57mm, impedance 8Ω). Light-emitting part 340 is a yellow LED (specifications unknown). Other components include: resistor R1 (1kΩ±5%), resistor R2 (10Ω±5%), potentiometer R3 (TSR-3386T-EY5, 10kΩ), amplifier circuit IC1 (LM386G), electrolytic capacitors C1 and C2 (25V 10μF), electrolytic capacitor C3 (16V 220μF), polypropylene film capacitor C4 (100V 0.056μF), breadboard, appropriate amount of jumper wire, rubber bands, bands / elastic for attachment to the arm, and power supply means such as batteries. In this example, the MPU5060 library from Electronic Cats is used. This library can be obtained from github.com / ElectronicCats / mpu6050.

[0058] The circuit diagram is shown in Figure 42. On the control board 310, "SCL," "SDA," "4," "2," "5V," and "GND" refer to the pins with the same names. Note that "4" and "2" are digital pins. SCL, SDA, GND, VCC on the sensor and pins 1-8 on IC1 also refer to the same pins. (Do not connect XDA, XCL, ADO, INT on the sensor and pin 7 on IC1.)

[0059] Place the components, excluding the sensor, on breadboard 351 according to the circuit diagram. The sensor is connected using jumper wires (not shown) rather than being inserted into the breadboard. The light-emitting part (LED) 356 is inserted into the breadboard. Then, use rubber bands 357 to secure breadboard 351, sensor 354, and control board 353. At this time, the side of the sensor with the IC and the text "MPU6050" should be the front, and the side with the text "GY-521" should be the back (facing the breadboard). Similarly, the side of the control board with the microcontroller should be the front. Also, position the sensor in the direction of the SCL / SDA pins on the control board. Rubber bands 357 are used to secure the sensor. Two jumpers are used to secure the pin section to the breadboard, and two more are used to secure the 3.3V pin and pin 11 of the control board 353 to the breadboard. A band 352 (rubber, etc.) is then attached over the top for attachment to the arm. In this embodiment, the part containing the sensor 354 is positioned towards the elbow, and the opposite side (towards pins 1 and A5 of the control board 353) is positioned towards the wrist. Finally, the breadboard is wired with jumper wires. The top surface of the USB serial connection terminal on the control board may be insulated with a seal or similar material, and the speaker 355 may be placed on top of it. The two will be in close contact due to the speaker's magnet. An example of attachment to the arm is shown in Figure 43, and a view of it from above is shown in Figure 44.

[0060] Before writing the program described below, place the device on a flat surface such as a tabletop and calibrate the sensor using a known method. For calibration methods, please refer to the following document: blog.livedoor.jp / revolution_include / archives / 2815979.html The values ​​shown under "Your offsets" are, from left to right, Accel_X, Accel_Y, Accel_Z, Gyro_X, Gyro_Y, and Gyro_Z.

[0061] Here, we will note some points regarding the units of measurement. In the previous embodiments, the vertically upward direction was considered positive for clarity, but in the program of this embodiment, the vertically upward direction is negative. Also, the pitch is ±0 when the device is rotated clockwise around the sensor axis, -π / 2 when the breadboard is vertically upward (i.e., from above, control board, sensor, arm raised), ±π when the breadboard is upside down, and π / 2 when the breadboard is vertically downward (i.e., from above, sensor, control board, arm hanging down). Please refer to Figure 45 for this as well.

[0062] Figures 48 to 53 show the programs written to and executed by the microcontroller. Figure 48 shows constant and macro definitions. Wire.h is the standard Arduino library, and MPU6050_6Axis_MotionApps20.h is a library from Electronic Cats. The constants Accel_X, Accel_Y, Accel_Z, Gyro_X, Gyro_Y, and Gyro_Z are values ​​obtained from the calibration described above. Since these values ​​differ for each sensor, the values ​​shown in the figure are only those specific to the inventor's environment. The constant SPEAKER indicates the pin to which the speaker is connected (pin 4), and the constant LED indicates the pin to which the LED (the light-emitting part) is connected (pin 2). Constants beginning with STATE_ indicate the state. These are stored in the 8-bit integer variable state. The first three bits from LSB indicate the processing state of this device. The processing state is one of six: DETECTING (initial state 371 in Figure 47, i.e., detection processing started), DETECT_AND (detection in progress state 372), PLAYING_A (first sound processing state 373 = playing a 1000Hz sound), PLAYING_B (second sound processing state 374 = playing a 1500Hz sound), WAITING_FOR_COOLDOWN (decision cooldown state 375), and WAITING_FOR_FLAT (waiting for hand-raising interruption state 376). The processing states are assigned integer numbers in the order described above, making them comparable. MSB (STATE_DISCARDING) is set in case of errors such as buffer overflow or detection of abnormal measurement values, and is used to periodically suspend processing for a certain period. The remaining bits are unused. HAND_RAISED_THRESHOLD is the pitch reference value for determining whether a raised hand is raised; in this case, -0.75 was used. Therefore, 180° / π * -0.75 ≈ -43°. FLAT_THRESHOLD is the pitch threshold value used to determine the hand-raising interruption condition; in this case, -0.25 was adopted. 180° / π * -0.25 ≈ -14°. ERROR_THRESHOLD is the threshold value used to determine if the absolute value of the pitch measurement is abnormal; in this case, 2.2 is used. That is, if the pitch measurement exceeds 2.2 or falls below -2.2, it is considered an abnormal value. The macro FREQ is used to change the blinking interval of the light-emitting part according to the value of the counter, but the details will be explained later.

[0063] Figures 49 and 50 show the variable definitions. The important ones are explained here. `ypr` is an array containing three floats, storing the Euler angles expressed in the aforementioned angle units, i.e., yaw, pitch, and roll, in that order. `ticks` is a cycle unit, indicating the number of remaining cycles when determining whether a certain condition has been met for a predetermined number of cycles. `state` is the aforementioned state. `discard_cooldown` indicates STATE_DISCARDING, i.e., the remaining time for periodic processing suspension in case of error (remaining time for stable cooldown), in cycle units. `count` is a counter. `flip_ticks_left`, `flip_ticks`, and `led_lit` are all used to control the light-emitting part, and represent the number of cycles until the next on / off switch, the number of cycles for switching between on and off (i.e., the blinking switch interval), and whether the light-emitting part is currently lit, respectively.

[0064] Figure 46 shows that the setup function 361 and the loop function 362 function as initialization and periodic processing, respectively. Their source code is shown in Figures 50 and 51. The setup function performs the initialization process. First, the I2C connection is started by calling Wire.begin();. The initGyro function is called to initialize the sensor. The pinMode function sets the speaker and LED pins for digital output. The loop function executes the periodic processing described later. The getGyro function shown in Figures 51 and 52 retrieves sensor measurements, calculates Euler angles, and handles errors. The initGyro function shown in Figures 52 and 53 initializes the sensor.

[0065] The initGyro function first initializes the MPU6050 and checks for a connection. If the connection fails, it enters an infinite loop. Next, it sets the calibration offset as described above. It also enables the sensor's DMP (Digital Motion Processor). This causes the sensor to calculate quaternions from raw measurements and periodically output the results to the FIFO buffer.

[0066] The getGyro function first checks the status of the MPU6050. If a FIFO buffer overflow is detected, the buffer is reset, the STATE_DISCARDING bit in the state is set, and a 5-cycle stable cooldown (discard_cooldown) is initiated. This is because, as mentioned earlier, the inventor's empirical rule was that the value retrieved from the buffer during a buffer overflow often deviated from the normal measurement. After waiting 5 cycles, detection processing and other operations resume. Note that a buffer overflow is determined by whether the 5th bit of the flag (FIFO_OFLOW_INT) in the MPU6050's status register is set, or by whether the buffer size has reached a predetermined value (1024). Next, check if data is available. This is determined by checking if the second bit of the status register flag is set. (According to the datasheet, DATA_RDY_INT is the first bit, but this is probably an error in the datasheet.) If data is available, the angular velocity data (gyroData) and quaternion (q) are retrieved from the FIFO buffer. Gravity data (gravity) is calculated from the quaternion, and Euler angles (ypr) are calculated from the quaternion and gravity data. Finally, as mentioned above, anomaly detection of the pitch is performed. If the absolute value of the pitch measurement exceeds ERROR_THRESHOLD, it is determined to be an anomaly, the STATE_DISCARDING bit in state is set, and the system enters a stable cool-down. Unlike buffer overflow, anomalies in pitch can occur not only due to electrical factors such as noise or poor contact, but also due to mechanical factors such as simply dropping the device on the floor or not properly attaching the device to the upper limb. Since device malfunction (i.e., false detection of raised hand) is undesirable, the cool-down is set to 10 cycles, which is longer than the cool-down for buffer overflow. Naturally, the cool-down and ERROR_THRESHOLD can be adjusted as needed.

[0067] This explains the periodic processing performed by the loop function. At the beginning of the loop function, the LED blinking process is performed. This process is also performed during the stable cooldown. When the state is equal to or greater than the first state of sound processing, flip_ticks_left is decremented. When it becomes 0, i.e., when the blinking switching interval has elapsed, the on state of the LED (led_lit) is reversed, and the new state is output to the LED pin. The blinking switching interval is also assigned to flip_ticks_left, and the countdown starts again. If the state is less than the first state of sound processing, the LED is turned off and this is output to the LED pin. The `getGyro` function is called to retrieve the sensor value as part of the detection process. Next, a stable cooldown check is performed. If the STATE_DISCARDING bit is set in the state, the stable cooldown (discard_cooldown) is decremented. If the stable cooldown is 0, the STATE_DISCARDING bit in the state is removed, and all checks that were paused for the stable cooldown are restarted from the beginning. In other words, if a check for whether the raised hand state will continue for a predetermined period (STATE_DETECT_AND state) was performed immediately before entering the stable cooldown, it returns to the initial state (STATE_DETECTING), and if a check for interruption of the raised hand condition (STATE_WAITING_FOR_FLAT) was in progress, the check is restarted from the beginning. This means that an additional 10 consecutive cycles of checking for interruption of the raised hand must be performed. If the stable cooldown is 0, processing continues; otherwise, the periodic processing is interrupted here. The next periodic processing will start from the beginning of the loop function.

[0068] The switch statement implements a state machine as shown in Figure 47. (For simplicity, stable cooldown is not shown in Figure 47.) Note that since there is a break statement between each state case, even after a state transition, the execution of the processing for the next state must wait until the next cycle. When the current state is the initial state 371, i.e., STATE_DETECTING, if the pitch is less than HAND_RAISED_THRESHOLD (note that the angle direction is reversed compared to the embodiment), it means that the sensor value corresponds to hand-raised detection. To determine if this will continue for 10 cycles, the state is changed to the detection state (STATE_DETECT_AND), and 10 is assigned to the remaining cycle count (ticks). When the current state is detection state 372, i.e., STATE_DETECT_AND, if the pitch exceeds HAND_RAISED_THRESHOLD, it means that hand-raising detection has stopped. In other words, it was not possible to detect a hand-raising for 10 consecutive cycles. Therefore, it transitions to the initial state (STATE_DETECTING). Otherwise, the remaining cycle count is decremented, and if it is 0, it is officially detected that a hand-raising occurred (this completes the detection process). The counter is incremented, and the process proceeds to sound and light emission. For sound emission, the tone function is used to send a 1000Hz audio signal to the SPEAKER pin. For light emission, led_lit is set to true, outputting it to the LED pin, and the blinking interval and the number of cycles until the next on / off switch are set to numbers dependent on the counter. Specifically, if the incremented counter is 10 or greater, it is 50 cycles; otherwise, it is counter * 5 cycles. This is defined by the FREQ macro. The state then transitions to the first state of sound emission (STATE_PLAYING_A), and 30 is assigned to the remaining cycle count (ticks). In other words, the 1000Hz sound is played for 30 cycles. When the current state is the first sound processing state 373 (STATE_PLAYING_A), the remaining cycle count is decremented. When the remaining cycle count reaches 0, the system transitions to the second sound processing state and simultaneously sends out a 1500Hz audio signal. The remaining cycle count (ticks) is set to 50. Therefore, the 1500Hz sound is played for 50 cycles. When the current state is the second sound processing state 374 (STATE_PLAYING_B), the remaining cycle count is decremented. When the remaining cycle count reaches 0, the speaker's sound playback is stopped using the noTone function, and the system transitions to the judgment cooldown state. The length of the judgment cooldown is also specified in the ticks variable in cycle units, which is 300 cycles in this case. When the current state is the judgment cooldown state 375 (STATE_WAITING_FOR_COOLDOWN), the remaining cycle count is decremented, and when the remaining cycle count reaches 0, the state transitions to the hand-raising interruption waiting state. The number of cycles (10 cycles) for which the hand-raising interruption should continue to be checked is specified in the ticks variable. When the current state is state 376 (STATE_WAITING_FOR_FLAT), the interruption condition, i.e., whether the pitch is greater than or equal to FLAT_THRESHOLD, is checked. If the pitch is less than FLAT_THRESHOLD, the hand raise is continued, so 10 is assigned to the ticks variable again, and the hand raise interruption check returns to the beginning. Otherwise, the remaining cycle count is decremented, and when the remaining cycle count is 0, it transitions to the initial state. After that, if a hand raise is detected again, the sound and light emission processes will naturally be performed again. [Industrial applicability]

[0069] The apparatus, programs, etc., according to the present invention are expected to be used in various settings such as education, employee training, and entertainment. Furthermore, by incorporating sound-producing, light-emitting, and vibration-producing units, it can be used in educational settings for visually impaired, hearing-impaired, and other individuals. [Explanation of symbols]

[0070] 10 Hand-raising reaction device 11,22 sensors 12 Control Unit 13 Storage section 14. Pronunciation Section 15 Light-emitting part 16 Vibrating part 17 Communications Department 18 User identification information acquisition means 19 Connection destination information input means 20 Location information acquisition section 21 Upper limb 31a, 31b, 31c, 31d: Parts of the hand-raising reaction device other than the sensor 32 User 41. 2D barcode reader 42 Paper with a 2D code printed on it 43 IC card reader 44 Student ID 91 Initial state 92 Stable cooldown state 93 Detection in progress 94 Pronunciation 95 Judgment Cooldown State 96. Waiting for the hand-raising to be interrupted. 100 Systems 101 Server 102 clients 103 User Information Management System 104 Smartphones 111 Two-dimensional code containing user identification information 112 2D code containing connection destination information 121 Device Registration Section 122 Device List Display Unit 123 Device details display area 124 Device registration deregistration unit 125 Broadcast Department 126 Call Department 127 Hand-raising reception desk 128 User Identification Information Reception Department 131 Button (Transmitter) 132 Smartphone (transmitter) 133 Transmitter 310,353 Control boards 311 Microcontrollers 320,354 3-axis acceleration / angular velocity sensor 330,355 Pronunciation section 340,356 Light-emitting parts 351 Breadboard 352 Fixing Band 357 rubber bands 371 Initial state 372 Detection in progress 373 Pronunciation Processing First State 374 Pronunciation Processing Second State 375 Judgment Cooldown State 376 Waiting for the hand-raising to be interrupted.

Claims

1. It has a sensor, a control unit, a sound-emitting unit, a light-emitting unit, and a storage unit that stores at least a counter. The sensor is attached to a person's upper limb and is capable of measuring one or more of the movements or angles of the upper limb. The control unit performs a detection process to detect whether the upper limb is in an elevated position based on the measurement value of the sensor, When the aforementioned detection occurs, the sound generation unit emits a signal sound to notify others of the detection, When the above detection occurs, a light emission process is executed to cause the light-emitting part to emit light. The control unit increments the counter by 1 when the detection occurs. The light emission process is characterized by changing the color of the light emitted by the light-emitting unit, the blinking interval of the light emitted, or the brightness of the light emitted, according to the value of the counter. Hand-raising reaction device.

2. The sound generation process is characterized by changing the sound or volume of the sound generation unit according to the value of the counter. The hand-raising reaction device according to claim 1.

3. If the counter has not reached a predetermined value, the light emission process increases the blinking interval of the light emission unit as the counter increases. If the counter reaches the predetermined value, the flashing interval of the light-emitting unit will be made independent of the counter. Characterized by, The hand-raising reaction device according to claim 1.

4. A program for causing a device having a sensor, a control unit, a sound-emitting unit, a light-emitting unit, and a memory unit to function as a hand-raising response device according to any one of claims 1 to 3.

Images