Exploring the CodeBug device features one of the most interesting possibilities is developing useful tools to teach electronics to newbies, young people and kids. Associating these tools to playable projects, it is possible to involve these persons, introducing them to a vision of what electronic is, maybe more difficult when following an academic approach.
This is the first post of a series of "experiments" trying to introduce some of this concepts. The approach of this post will be a sort of making-of. Beyond the limits of the CodeBug device I will expand (or export) the same idea to the BBC micro:bit that offers more options and flexibility. We can expect that along the next year we will find on the market a number of these low-cost, easy to use micro controller devices that will enter the competition.
This post results to be an hybrid not orientes as-is to young kids audience. What I aim is showing what can be done with these boards, exploring their educational features.
A first IoT educational project has already been created as explained in the QuizBug post and exposed on Drobott.com with a decent return of interest especially by social and media. I consider this the next step, a more formalised definition addressed to the educational approach.
The educational model
The educational model should be a format replicable many times, applied to different components. It will be divided in a documental part and practical part, slightly different to be a "course".
Take a look to the following image from the CodeBug official site home page:
The key points are Start fast and easy, Explore and Become inspired: master in physical computing etc... Then exploring in depth the offered projects under the lable Learn these sounds most of a well-done recycle operation: CodeBug has 4 sensitive buttons, two push-buttons and a LED matrix display; all the physical computer experiments presented on this section (and many other articles published on forums, IoT discussions etc.) always recycle the same concept: feedback on sensitive touch (or button press) and few more.
So, is CodeBug only usable to flash LEDs, sense-push buttons and write scrolling strings on the display (or moving sprites) ? To be honest, despite the implicit limitations I think no.
1. One component, one tool
Every component should be presented as a simple boxed object. In this case we use a 5V stepper motor and a half-bridge L293D IC. The components should be easy to connect, and also the motor should be boxed in a proper way.
2. Data sheets reviewing
The producer data sheets as we are used to see are not very helpful for newbies. Every components needs a easier document as well as a clear circuitry explanation of the connections.
The image above shows the pinout of the L293D and should be accomplished by a clear explanation of their meaning. The document should have different levels of reading, depending on the interested of the audience to go more or less in depth to understand the sections.
Always following our example the same should be done for the stepper motor:
3. Please explain the principle!
Most of the passed information should be presented as images. The simple scheme above together with a short chapter explaining how the stepper motors differs from the traditional DC motors gives a value-added resource and the basic knowledge to understand how the kit works.
One of the things I see on too many projects presented for the entry-level micro controller experiment boards, and CodeBug too, is that there is no explanation of the principles: these project IMHO are most receipts than teaching examples.
Unfortunately this contributes creating a sort of scission between the experts and the newbies. After following one of these receipts users are able to replicate what they saw but - most probably - have not idea of what to do if they are asked to apply the same principle to a different circuit. In my opinion, proposing this kind of approach is far from to educate...
4. Enjoy the project
I think when addressing to a young and non-expert audience and kids, to include in the kit the option to make something attracting. The next step is finding something that plays better using the stepper motor and CodeBug. A real IoT application of the explained concept.
The CodeBug software is rarely commented or explained in detail. Unfortunately this becomes an issue with CodeBug: probably one of the most urgent issues that the CodeBug guys should solve. CodeBug programs can't be developed locally, there is no option to manage a source in any way (excluding the case of seeing it in the browser), there is no option to download it for any kind of storage. Also in this case any project just invite the user to make his own copy (online) of the existing application and run it. Another receipt-approach.
Controlling a stepper motor: test sample
The question is: is it possible to control a stepper motor with CodeBug?
With four output pins (that are also the sensing buttons and more depending on what we configure) the answer is yes. What is shown in this post is the proof of concept, I mean something really working based on the use of the only two components mentioned above: a 5V, 6 wires unipolar stepper motor and a L293D half-bridge IC.
The connections between the stepper motor and the L293D on the breadboard are the same shown on the circuit above. Wire colours follows the coil terminals order (based on the motor specific datasheet). The two components datasheet can be downloaded from this article.
As the stepper motor (Soyo 4V unipolar stepper motor) is powered by an external power source a 1N4001 diode is used between the positive external power and the circuit common ground.
The four controlling PINs of the L239D A1, A2, B1, B2) are connected respectively to the PIN 0, 1, 2, 3 (or legs) of the CodeBug configured as output.
The applied principle
Depending on the order and logic levels when the stepper motor receives the four pulses to the coils it moves, one step every series of pulses. The rotation speed is determined by the frequency of the pulses. With the four PINs there are 4 logic configurations that should be sent in order to move the motor by steps:
When all the four pulses are sent to Off the motor does not moves. The four sequence values in the order 1-2-3-4 moves the motor clockwise while the sequence in the opposite order 4-3-2-1 moves the motor counterclockwise.
The CodeBug graphic program
The CodeBug program is available for any usage at the following link: http://www.codebug.org.uk/create/codebug/2452/bugstep/
The following images shows the most important parts of the program:
The first part set the four PINs of the CodeBug as output. The variable Speed is set to the default value: this is the number of ms that the program wait after every sequence. As high is the speed value as low is the motor speed and vice-versa.
First of all all the four PIN (legs) of the CodeBug are turned Off so the motor is initially stopped. The other task of the initialisation part is writing the scrolling text. All this part runs once when the program start.
2. Infinite loop
The program should run continuously enabling the user to run or stop the motor. A similar procedure we are used to see in the Arduino and other microcontroller boards is reached by an infinite loop.
The On/Off motor state instead is controlled by the boolean variable Running initially set to false (the motor is stopped).
3. Motor control
The control of the motor is managed by the two tactile push buttons A and B of the CodeBug: the first starts the motor, the second stop it. The two images below shows the two cases. Note that when the button B is pressed, together with changing the state of the Running flag the motors is stopped.
4. Executing a step
The following image shows the code relative to the execution of a single step.
The four PINs (legs) of the CodeBug are set to the desired pattern (see the table above) then the program pauses for the speed number of milliseconds. Last action is drawing the sprite corresponding to one of the four positions to animate the display.
To see the simple motor stepper controller at work take a look to the following video.
Any suggestion to improve the described model is welcome.