I’ve uploaded a video to Youtube with an example of the motor protocol. It explains how the information is passed from the PC to the “Buffer Control” brick and then – using the Motor Protocol – is passed to the daisy-chained-EV3’s.
In the example I use a NXT to receive the selected color (here simulated with a color sensor and a color cube), which is then passed to an EV3 that show the selected color on the display.
Some remarks to the NXT / EV3 programming:
- If you use the NXT/EV3 motor block to rotate ’90 degrees’ and the motor is rotated back by the EV3/NXT motor, the motor ‘thinks’ that it went back 90 degrees. This resulted in the following ‘strange’ behavior: the next time that the ‘rotate 90 degrees’ command is executed, the motor adds 90 degrees to it. In order words: first time it is executed it rotates 90 degrees, second time 180 degrees, third time 270 degrees, etc. I solved this problem (both on the NXT and EV3 side) as follows: set motor on, directly followed by a ‘wait until motor rotates 90 degrees’. And this works fine, as you can see in the video.
- Some smart people out there, have already questioned the use of two motors. And they are right: this protocol can also be implemented with one motor. For example: rotation 90 degrees is Blue, rotation 180 degrees is Green, rotation -90 degrees is Red and rotation -180 degrees is Yellow. I used two motors, just to show how you can use more motors and that you can implement a complex protocol if you need it. For example, if you use two motors and 90/180 degrees of rotation, you can pass 24 different messages:
- An excerpt of the EV3 program: