Python 102 - Scratch pseudo code example

Using the 'my blocks' capability of Scratch3 to abstract up to "pseudo code" like algorithm using the Scratch block structure. The "coding" detail is hidden in the define blocks.

Just playing with ideas to show an algorithm (as opposed to the final code) in a format readily understood at KS2 level (maybe). This would then leave pupils with the coding challenge of producing the detailed code for the my blocks.

So max in a list might be:

plus I like playing with the speak functionality in Scratch3 :-)

Microbit Line Tracking - hidden parameters

Every day of this past week BT Adastral Park have been running a Crumblebot based line tracking event for Primary and Secondary schools in Suffolk and adjacent counties. That has meant over 100 children per day having great fun while reinforcing some of the crucial parts of the KS2 Computer Science curriculum.

With my CAS hub leader and STEM Ambassador hats on I volunteer at these events in support of the great work that Pam Popay, Jill Southgate and all the BT volunteers put into delivering a great set of instructive and practical days.

As a code club leader at one of the school's attending, Woodbridge Primary School, we are beginning to do some work with microbits and have a few at the club so I thought it would be interesting to implement line tracking using a microbit based robot. I purchased the Kitronik bot which uses visible light instead of infrared to help "show" the principle of operation. Having built the bot and tested the sensitivity of the LDRs some minor tweaking was necessary to pull up the output of the comparator op amps to trigger the digital threshold on the microbit. Having completed the build it was on to a bit of coding..........

In Code Club we are using the Java blocks editor so I used this to code the line following script that Kitronik supply with their build instructions.

Their script uses the LEDs to show which direction the bot is travelling in for each of the detector states (very useful) which I coded using the basic show led block:

What I failed to spot was the additional parameter lurking at the end of the script's show led code; a subtle ",0" which is really important. This parameter is not an option in the above block and what is even less obvious is that the block adds a default 400ms pause in operation. Not a lot of good when following a line!

To overcome this but keep using block based coding it is necessary to convert the block code to javascript and add the ,0 into the led command:

basic.forever(() => {

if (true) {

basic.showLeds(`

. . # . .

. # # # .

# . # . #

. . # . .

. . # . .

`,0)

} else {

    

}

})

Then convert the code back to blocks which results in a script statement that cannot be converted to a block (a bit like a line of assembler in BASIC) but which has the 0 millisecond pause set ....

and results in a line tracking algorithm that works.

Code Club - sign up competition

This term Woodbridge Primary school is experimenting with an after school club sign up session. A bit like Freshers week I would imagine but without all the social add ons.

So to try and differentiate Code Club from all the other clubs (and there is a lot of competition this term) I have decided to run a competition during the sign up session and to try and link it to the KS2 Computer Science curriculum that will be with us in September.

The following is a bit of a mix of Algorithms and Programs but it will be interesting to see how Code Clubbers get on with this, especially the 9 girls that went to BT Adastral Park and competed in the CoSpace taster day last term.

Following on from the RoboCup CoSpace day I have been tinkering a little bit with robots etc. I have a "work in progress" robot that I hope will eventually mimic much of the functionality of the virtual robots in the CoSpace challenge. As of now it just has motor functions and "edge" detection using a reflective IR sensor.

At the moment it is programmed to detect either a white line or the edge of a table/platform (or black tape for a less risky option) and take evasive action. It works well when approaching at a reasonably steep angle but fails miserably when approaching at a shallow angle (one central sensor is not enough and will be fixed soon).

So the challenge for our KS2 pupils will be to specify what the robot is doing in a single sentence and then reverse engineer the robots actions into an exact algorithm/program.

A Mind Set programmable robot goes to the winner.

For those who are interested the robot chassis is a Sparkfun Magician chassis, the controller is an Arduino Uno with an Arduino Motor shield and the sensor is a Pololu QTR-1RC infra-red reflectance sensor.

Raspberry Pi and Robotsapien and LIRC

Robosapien InfraRed operation from a Raspberry Pi using LIRC.

An old v1 robosapien robot came into my possession which I thought could be good to use as an interesting demonstration of sequential programming in KS2 using either Python or Scratch on a Raspberry Pi. The problem was that I had no remote control with the robot, no idea about the ir codes or protocol and was therefore dependent on searching the web for the required information.

There are a number of projects on the web that “hack” the robosapien. Most dispense with the IR control and add an arduino or similar and directly input data to the robot removing the need to use the IR protocol. See http://playground.arduino.cc//Main/RoboSapienIR as an example.

There is some data available for the IR codes and set-up for the Robotsapien but there also appears to be some disagreement about the exact protocol both in relation to headers and trailing data and the exact timing for pulses and spaces.

Setting up LIRC on the Pi

There are detailed instructions on a number of web pages covering how to do this including http://alexba.in/blog/2013/01/06/setting-up-lirc-on-the-raspberrypi/ - I configured the GPIO out to use pin 25 (simply because it is convenient on the pi cobbler GPIO extension).

For the IR transmitter I use the Sparkfun Max Power IR LED kit https://www.sparkfun.com/products/10732

The LIRC configuration and IR codes for the Robosapien proved to be a little more difficult as there is no consistent agreement on the web about what the setup should be. I used two sources as a starting point:

http://comments.gmane.org/gmane.comp.hardware.lirc/2674

and

http://www.aibohack.com/robosap/ir_codes.htm

They each agree in part but differ over the basic structure of the start and stop encoding and the setting of the Most Significant Bit. There is much discussion on the web about what is correct. I went back to basics and researched the protocol /encoding on sites such as:

http://www.phidgets.com/docs/IR_Remote_Control_Primer

http://www.righto.com/2009/08/multi-protocol-infrared-remote-library.html

and determined that the protocol in use was probably PDM and space driven based on a 1/1200 cycle time and a carrier frequency of 39200. A 0 data bit having a space of 1/1200^th or 833us and a 1 having a space of 4/1200^th or 3333us. The header required a pulse of 6666us followed by a 3333us space and a ptrail pulse of 833us is required to determine the length of the space of the last bit.

I then built a very simple LIRC config file on the Pi consisting of the headers in the first of the config files with the addition of the ptrail pulse along with the RIGHT_ARM_UP and RIGHT_ARM_DOWN codes in order to start to play with it. At this stage testing of IR transmission was very crude and consisted of a smartphone camera to ensure that the IR LED was operating when basic commands were sent using LIRC’s irsend command. The camera showed that the LED was firing at the right times but little else.

I then added the full set of codes and experimented with Robosapien switched on. The initial results with were mixed and very inconsistent. Some codes worked some of the time, whilst some didn’t work at all. This testing proved to be very unhelpful as there appeared to be no apparent pattern to the mode of failure but it did at least show that Robosapien was working.

However, a couple of weeks later, I was fortunate enough to receive an Xmas present from my son which enabled a much more scientific debugging approach to be taken...

The following charts are all produced using a Saleae Logic analyser which enabled a much closer look at the structure and timings of the IR signals being sent to the Robotsapien.

Analysis 1 shows a space encoded signal for Hex 1C which is the STOP command. The header shows that the space signal timing is 3.33ms which is exactly as specified in the headers of the config file.

Analysis 1.

The 833us spaces signify a 0 and the 3333us signify a 1.

The next image, analysis 2, shows measurement of the pulse width of the initial header pulse (logic low) which is required to be at least 6.666ms. Whilst it was defined as that in the LIRC config file, the output as shown below is only 5.634ms.

Analysis 2

Analysis 3 shows the end to end measurement of a pulse that is specified to be 833us but is in fact only 700us in duration. The expanded pulse on this chart also shows the 50% duty cycle giving the width and period duration of each cycle. Some variation in the period can be seen at this level which is measured by variations in the %duty cycle.

Analysis 3

Amendments to the config file so that the header pulse width is set to 8000 and the ptrail, one and zero pulses are set to 1000 has produced a waveform that consistently communicates with the Robotsapien.