Proposal for workshopping with Python and Firmata

I have a kind of manifesto document for a specific workshopping technique at http://shrimping.it/blog/wp-content/uploads/demo_sequence.pdf

It outlines why I think it's better to teach novice Arduino programmers using python and firmata rather than for example, the Blink sketch within the Arduino IDE.

I'd love to hear people's thoughts on this, especially if there are better ways, or if people can see big holes in the approach, or just if you disagree strongly (with reasons).

Sorry, but I don't believe that teaching anyone to use Firmata is a good thing. It doesn't appear to be supported. It removes the point of having a microcontroller, with onboard intelligence. If all of your projects are tethered, and driven by intelligence on the PC, I suppose it's a start, but as soon as you want to make something that can stand on its own, you have to learn to program the Arduino, so why not start with that?

@dxw00d I appreciate you taking the time to engage in this debate. Sorry for delay replying, I wanted to respond to each of your points in turn and was under pressure of deadlines at the time - a university submission is partly why the use-of-Firmata rationale was written up as the draft PDF which I linked to.

It's clear you don't agree that Firmata should be used, but I'm not sure I share your assumptions, and your reasons for your strong opinion aren't that clear to me.

I suppose it's a start, but as soon as you want to make something that can stand on its own, you have to learn to program the Arduino, so why not start with that?

This comes to the heart of the debate. Indeed this is specifically for novice programmers, and we detail how we transition from Python to C in the document. The reasons "why not start with that" were outlined in the PDF. I don't know if you found it tl;dr but it's probably better to say it here in the thread.

The main issue is that Arduino programs are monolithic. If you're a programmer it may not be obvious to you that there's a lot of concepts in the Blink sketch. With an interactive shell, using pyfirmata you can tackle language structures one by one, introduce the notion of values, types, expressions, named values (variables), named sequences of values (arrays), steps (statements), named groups of steps (functions) and so on, individually. Each can be introduced and explored step by step until the learner is comfortable with the concept in practice. They can see immediate results from individual steps because the servo moves, the array changes or the LED lights. There's a lot of commonality with work on Senseboard, and the section in http://oro.open.ac.uk/30294/1/cse202-Richards.pdf called "Reducing the obstacle of programming" makes the argument well, although they settled on a 'Scratch' blocks programming language instead.

It doesn't appear to be supported.

I'm confused by this. On the one hand, multiple Firmata sketches are distributed directly with the Arduino IDE under the Example menu, including updated sketches which handle the library compatibility changes since version 1.0 so I don't know what other model of 'support' you have in mind. As an open source project, it's as supported as the people who care about it enough to maintain it, update it and help users with its adoption. If any community is going to step up and do this support, it's the one represented in this forum. In any case if Firmata ain't broke, maybe it doesn't need fixing at all. Perhaps you think it's broke in some way.

It removes the point of having a microcontroller, with onboard intelligence...[unless] all of your projects are tethered, and driven by intelligence on the PC

Microcontrollers are specifically designed to open up the possibility of interfacing with the external world, (as opposed to mere microprocessors which provide the intelligence). An Arduino is something which can be extraordinarily useful when tethered as a slave of a laptop whose microprocessor does not have any general I/O pins. Most projects which I've been involved with are structured in exactly this way, combining PC programs with a bespoke physical-computing peripheral, implemented as an Arduino. One reason for pursuing this direction is that our project was initially all about "shrimping laptops". Of course there are deployment scenarios where tethering doesn't serve the application, but I don't think it's even possible to add GPIO to a PC without using a microcontroller, and Arduino is my board of choice. I was surprised by the implication that standalone use of Arduino is somehow the one true way.

If students are comfortable with all the relevant programming concepts, I believe moving to C is a relatively trivial issue, and for someone who is actively engaged in using Arduino the effort is then justified, just as you say, by the fact you can get your behaviour to run standalone. Starting with C, in my view, is a terrible way to introduce programming concepts for the reasons outlined in the PDF, and will tend to turn people off programming altogether, unless they are of a certain mindset. This project is about reaching out to the other 99%

Hi,
I would tend to agree with dxw00d. A lot of educationlests make the mistake of thinking a gentle introduction and then moving on to ... is a valid way of teaching. I would say it is not, it is an error in line with the mistake made with the ITA, initial teaching alphabet. If the aim is to get then to use C then let them learn C, you do more damage with a moving on strategy. What happens is that when you do move on the kids resent having to dump their previous learning and then they are reluctant to learn new stuff because that will only be dumped later won't it.

Firmatta will not work compleatly on the Mega and it greatly restricts what you can do with an arduino. Why it is almost like downgrading the arduino to the level of a Raspberry Pi. :slight_smile:

I second that. Switching from C to Python is easy. Switching from a memory managed dynamically typed language to C is significantly harder.

I'm confused by this. On the one hand, multiple Firmata sketches are distributed directly with the Arduino IDE under the Example menu, including updated sketches which handle the library compatibility changes since version 1.0 so I don't know what other model of 'support' you have in mind. As an open source project, it's as supported as the people who care about it enough to maintain it, update it and help users with its adoption. If any community is going to step up and do this support, it's the one represented in this forum. In any case if Firmata ain't broke, maybe it doesn't need fixing at all. Perhaps you think it's broke in some way.

The point is though, that it should not be up to this community to support Firmata. It was not written by the Arduino team. The version available to download at firmata.org is not compatible with IDE 1.0+, and hasn't been updated since the beginning of 2011.

The model of support I have in mind is quite simple. If you wrote it and published it, then you support it. There doesn't seem to anywhere on firmata.org to get support. I have never seen anyone that admitted to being from firmata.org offering support here when people have problems with it.

Take a look at the SD library for an example of how I believe it should be be done. You will see @fat16lib on here all the time giving excellent support and guidance to people.

Having said that, we will try and support people with Firmata problems, but we will also try to wean them off it. Even if you are running tethered, it is almost always more flexible and controllable to write a relatively simple sketch to replace Firmata.

using pyfirmata you can tackle language structures one by one, introduce the notion of values, types, expressions, named values (variables), named sequences of values (arrays), steps (statements), named groups of steps (functions) and so on, individually. Each can be introduced and explored step by step until the learner is comfortable with the concept in practice.

If you think that can't be done with C, then you are mistaken. C was one of a few languages that I actually learned in a classroom environment, and it was taught exactly like that.

I was surprised by the implication that standalone use of Arduino is somehow the one true way.

I didn't mean to imply that it was the 'one true way', but it is where a great many of the projects that do excite and inspire people lie, and Firmata does not support these sort of projects. I don't believe that the best way to engage people with the Arduino is to dumb it down, but to show them the possibilities. If they can see something that excites them, they will be more inclined to learn.

I guess the question is what part of the rock face you want to lead them up first.

One of the motivations behind Bitlash (http://bitlash.net) was to provide a learner's language without a lot of the baggage. You can get pretty far teaching basic concepts without having to explain what int and void mean. It might be worth a look for your workshop.

// blink13 example in bitlash
function toggle13 {d13=!d13;}
function startup {pinmode(13,1); run toggle13, 500;}

-br

Loving Bitlash, in that it provides a means of transitioning from interpreted shell to hosted code. Always a little worried about being caught in a cul-de-sac though, even if it's a garden of eden :slight_smile: That's one of the reasons for raising this query to begin with.

dxw00d understand what you're saying on Firmata support. If in practice the community is turning away from it we have to take this into account. We're not using Megas (or Arduinos for that matter), so I'm not too worried on that front. However, I don't believe it's easy to substitute and write your own protocols, at least for the average person.

The I.T.A. parallel from Mike was pivotal to me understanding where I'm coming from. It clarified in my mind what exactly I feel needs to be taught. I think you're right if the aim is to get them to use C, then it's a bit mad to teach them Python. However, the aim is to teach them to be programmers, not C programmers (and importantly NOT computer scientists, this is like the difference between a carpenter and a dendrologist).

I'm hoping to teach the fundamental skills which transcend any language and are a matter of the programmers craft, insights like the concept of a variable, the habits and shortcuts of how and when you structure data into sequences (containers for items without names = list/array) or dictionaries (containers for items with names = struct/object) depending on what you're trying to achieve, sensible approaches for choosing names, how to break complex behaviours down into smaller parts. I believe these aspects are easier to learn in an interpreted, untyped shell language, and especially one which can be used for so many jobs, but in any case, these skills can transfer. In the ideal world, session participants will have developed some of the skills of a pragmatic programmer, concepts which can be used across javascript, java, ruby, php and so on.

If the fishing trip is successful, they bite the worm, and become developers probably C is one of the least useful languages for them when branching out into web programming, audio, graphics. If they were stuck with python, it could be worse - it can be used for almost anything and this is where the parallel with I.T.A. breaks down, which really was a cul-de-sac, and could never be used for real-world tasks.

I have to differ with dxw00d that you can explore individual concepts in C. I thought it was a matter of fact that causing anything to happen through Arduino C demands a complete program compiled to hex, which means you're exposed to void, function defs, function calls, (implicitly) library calls and many other things before you can achieve anything at all. I'm talking from a semi-religious point of view here, as I've been convinced by Constructivism... Constructivism (philosophy of education) - Wikipedia and indeed Constructionism... Constructionism (learning theory) - Wikipedia , which takes things a little further, and more literally. Both of these emphasise being able to act on your world to figure stuff out or else most people just won't figure it out. If you can go pin.write(1) and see the light come on, this meets the challenge. If you have to write the whole of Blink without errors and upload and run it to confirm your comprehension of 10 concepts at once, this is a real problem.

It's no surprise that Papert (the original Constructionist guy) was behind the family of programming tools leading to Scratch. This could go some way to explain your experience of educationalists too, Mike. This atomic, active manipulation is the sort of experience they feel individuals need to have in order to make sense of programming. The geeks amongst us can cope even in the face of complexity. I fear many people other people are left by the wayside because our typical teaching approaches mean they cannot build up incrementally. I'm probably reaching more for the non-geeks here, but as a geek myself I'm badly qualified :frowning:

Has anyone in the thread had success teaching non-programmers with either C or python or anything else? Be good to hear your anecdotes of how key concepts 'dawned on' people. I'm especially wondering if anyone's had success converting people who are not classically interested in computers/logic into using programming for its practical benefits? That's the particular line I'm trying to go down. Happy to teach natural geeks too, but I'm wondering if I can achieve some evangelical programming; on a mission :slight_smile:

The "Scratch for Arduino" project is an interesting development along the same lines to introduce basic programming concepts without having to teach C.

http://seaside.citilab.eu/scratch

I also find this article and set of demos very inspiring to my way of thinking about learning/teaching programming - articulates well some of the issues with the status quo, and offers concrete solutions...
http://worrydream.com/LearnableProgramming/

Interesting page. I disagreed with almost everything there. It seems to be a mixture of how programming should be and how to teach this idealised concept. I am not sure where it gets you. Are you hoping that once educated like this someone will go on to learn proper programming? At the end of the day someone has to create these utopian environments. Is there any point in teaching anyone how to program if there is nothing they can do with it, or is it just entertainment and baby minding that so much of education has become nowerdays.
I don't think there is anything better than trying to get students to think. It is hard to do but once you have done it then they simple educate themselves. Education is not about learning stuff, it is about learning how to learn.

Reading your document, I find it odd that you'd suggest that the "void" in "void main() {" raises a lot of questions at the same time you're prefixing your Python code with "from pyfirmata import Arduino" -- an undoubtedly much more complex topic to explain fully. You're not giving each language equal criticism.

Disclaimer - I know Cefn (and have met Grumpy Mike ).

I'm a primary school technican/HLTA and therefore the concept of learning a simple system before moving onto a "real world" system is the way it is with young children.

I learnt electronics from brick-type kits which I then threw away and built Heathkit type kits and I then I built a Linear Amp from scratch and then I went and had a career as a Transmitter Engineer.

So learning a "mickey-mouse" language is a great benefit at the beginning as it buffers the learner from the "real-world" and allows them to make progress.

I see the concept of first learning about programming an arduino via a higher level language on a PC before switching to its c-like structure as just part of the whole Lego/Mecanno learning concept :slight_smile:

regards
Simon

@Chagrin Sorry for not replying. Posts here don't seem to subscribe you to replies by default and the checkbox is in a hidden menu.

The python 'import' line certainly needs explaining, but I believe I'm being fair. We can contrast the use of void and the use of import quite strongly I believe, and I'm quite surprised to hear your point of view that they are similarly problematic from a comprehension or functionality point of view in an educational setting.

void...

  • does literally nothing
  • is a placeholder to do with the parsing of the language
  • can only be explained by reference to return values, types, function calls, none of which are needed for a simple program, effectively meaning all novice Arduino programmers must mentally begin at http://arduino.cc/en/Reference/FunctionDeclaration rather than (my personal preference) digitalWrite() - Arduino Reference
  • plays a part in a structure which is mandatory (for Arduino programs) but isn't fundamentally required

import

  • is fundamental to the program
  • contains no spurious terms - it "imports" functionality used later with the name "Arduino" from a library (provided by someone else) called "pyfirmata"
  • introduces python as a simple, minimal interpreter which can be used for Arduino, but not only for Arduino (you might choose to import other things), which is a key educational objective. You can do preparatory work with arithmetic and text printout before you introduce Arduino at all.

From a purely practical point of view, I find that the import statement is not only comprehensible to people, but is functional and introduces important and relevant concepts for their learning about an interpreted programming environment, and python in particular.

By contrast I find myself apologising for the void setup() {} void loop() {} boilerplate - a slight embarrassment when saying of Blink 'this is your first, simple program' in workshops. Even an empty program which does nothing is hard to explain. It may be literally their first encounter with code, and for many that moment can determine their expectations for a good while.

We could agree to differ on which is easier to understand, more useful or more meaningful. I think the more important contrast is between the interpreted approach and the compiled approach, with the interpreted code offering much more opportunity for reflective processes of learning and experimentation in atomic chunks. The import statement, once entered, can essentially be forgotten as you simply proceed to make calls to the 'Arduino' object, which have immediate, visible effect in your circuit and can be understood in a standalone fashion, without thinking about flow control, stacks or forms of indirection..

Exposing people to void could easily be avoided if the maintainers of the Arduino program treated top level statements as implicitly within a setup() function, as the makers of Processing do (I believe, though it's a bit buggy from experience). Then you could just write code which turned on and off LEDs directly, while moving towards a setup() and loop() convention after explaining the basics, and only when it's needed.