Category Archives: Aggregated

New Product Friday: Circuit Stickers

via SparkFun Electronics Blog Posts

Hello everyone, I’m back to talk to you all about the new stuff we have for this week. We have a new type of product this week, so let’s dive right in and talk about what circuit stickers are.

Chibitronics Circuit Stickers - Starter Kit

DEV-13289
$ 24.95

The Chibitronics Circuit Stickers are exactly what they sound like. Well, the circuit sticker part anyways. They are stickers that can be used in conjunction with copper tape to create working circuits. Inside each Circuit Stickers Starter Kit is everything you need to set up simple LEDs, Switches, and Sensors with only a bit of knowledge on how electricity works and a little ingenuity! With this starter kit no soldering or sewing is required, simply peel each LED sticker and place them in specific areas designated in the included guide sketchbook and watch your creation glow. Check them out in action:

Chibitronics Circuit Stickers - LED Effects Add-On Kit

DEV-13292
$ 14.95

In addition to the starter kit, there are also add-on kits. The LED Effects Add-On Kit provides you with five unique stickers to make your LEDs blink, twinkle, and generally effect the way you experience them. Each kit features one twinkle, heartbeat, blink, and fade circuit sticker and adds their respective effect to your paper circuit project. Like the LED stickers you won’t need to worry about any soldering, sewing, or coding. Just peel, stick, and you’ll add some awesome effects to your LEDs in no time!

Chibitronics Circuit Stickers - LED Effects Add-On Kit

DEV-13292
$ 14.95

The Color LED Add-On Kit is a set of 24 individual red, yellow, and blue LEDs that offers a conductive adhesive backing that can be attached to just about any surface and powered by a simple coin cell battery. That’s right, no soldering, no sewing, and no coding. Just peel, stick, and you’ll have a set of glowing white LEDs in no time!

Chibitronics Circuit Stickers - White LED Add-On Kit

DEV-13290
$ 14.95

Lastly, the White LED Add-On Kit includes 24 white LEDs if you don’t need the colored pack above. Be sure to check out the Chibitronics Learn Page for tutorials, videos, and multiple projects.

That’s all we have for this week. We have lots of new products in the works, so be sure to check back next week, we’ll have something new for you. The next month or two will prove to be pretty cool for new stuff, so be sure to check back. Thanks for reading!

comments | comment feed

Amazonian rainforest simulation

via Raspberry Pi

Mike “Recantha” Horne mailed me yesterday saying he’d found something that was (and I quote) “ALL KINDS OF COOL”. He also taught me a new word. This project is a paludarium: a created environment that mimics a complete terrestrial and aquatic biome, full of plants and animals that live in water and on land. A bit like a terrarium, but with an aquatic element as well (or a bit like an aquarium with a greenhouse on top).

Paludarium

The paludarium in question, created by a team called Poopi and Piter (it seems Piter built the paludarium and Poopi built the system that creates the weather and time-of-day effects), simulates an Amazonian rainforest, with fog, rainfall, thunderstorms and wind; as well as a complete diurnal cycle. The Raspberry Pi is responsible for running:

  • 6 independent sections of halogen lights
  • 27 independently controlled 1W LEDs for various effects
  • 3 independent 3W RGB LEDs for ambient color effects
  • 3 independent 3W LEDs for lightning and moon simulation
  • 3 independent 10W LEDs for Aquarium lighting
  • 2 independent FANs for wind simulation
  • 3 fog generators
  • 2 independent solenoids for rain control
  • Temperature monitoring

This is one of the most beautiful projects we’ve ever featured here. It’s a compelling watch: enjoy the video.

State Machines: blink.ino learns to snooze

via SparkFun Electronics Blog Posts

I’m a big fan of state machines. Almost every Arduino sketch usually ends up with at least one intentional state machine and a bunch of non-intentional state machines as well. Here, I’ll introduce the concept of state machines, and apply a state machine to a microcontroller’s “Hello world!” blink routine. After that I’ll explore some more complicated state machines, such as an alarm clock.

What is a state machine

A ‘state’ is the condition of a thing at a specific time. Something that can accomplish tasks and that utilizes states at its core is a state machine. They are also known as Finite State Machines (FSM), meaning that we know all possible states of the thing. The key to the state machine is the concept of time and history. The state of the machine is evaluated periodically. Each time it is evaluated, a new state is chosen (which could be the same state again), and the output is presented.

Our newly released servo trigger https://www.sparkfun.com/products/13118 is a good example of a state machine, and was developed with a similar technique. It’s a switch case statement under the hood, but with accurate timing added in.

A generic state machine:

alt text

A diagram of a generic state machine. The memory element contains the current state known as the state variable. When the state machine is serviced, the state variable is updated with the value of the next state. Here, the next state is a function of both the current state and some input. The cloud of logic is some system that decides what the next stat is to be, or the next state logic.

A simple state machine: The counter

A classic example of a state machine is a counter. For example, a ‘for loop’ or a 74x4040 logic IC both work as a state machine. Each time the machine is poked, either by the clock line or looping behavior, the state of the memory changes to a new state equaling the old state plus one. The finite set of states it can have is the numbers it can count.

alt text

A basic counter expressed as a state machine

Parts of the counter state machine:

  • The current state is the value that has been counted.
  • The output is the current state.
  • The next state logic is whatever the current state is plus 1.
  • There are no inputs. In a more advanced diagram, an enable line or reset counter function would be drawn as an input.

The state machine advances at whatever rate it is serviced.

Moore and Mealy state machines.

Digital logic professors love to ask test questions about Moore vs. Mealy and so I have to talk about them. I don’t think the distinction makes too much sense while writing state machines in C; it’s more of a “how to make logic hardware” distinction. For us, the lesson from Moore and Mealy is that people existed who thought about this stuff and invented ways of notating it. While they targeted logic hardware, we’ll target c software.

Moore State Machine

Edward Moore wrote a paper in 1956 (Gedanken-experiments on Sequential Machines) and thus the style of machine is named after him. He says the output is dependent only on the state, and the next state is dependent on the current state (or output), and the input.

alt text

Our previous diagram

You can see that no matter what the input state is, the output only depends of the current state contained within the memory element.

Mealy State Machine

Another guy, George Mealy, wrote a paper one year earlier than Moore, entitled A Method for Synthesizing Sequential Circuits, in which he goes into great depths about creating state machines from mathematical functions, and describes those state machine’s outputs in terms of their inputs.

To diagram the Mealy machine, the output is made to depend on both the current state and the input. Here, the cloud of next-state logic contains the output logic as well:

alt text

One way of drawing a Mealy machine

It could also be drawn by seperating the cloud into next-state logic and output logic:

alt text

Another way of drawing a Mealy machine

Abstract State Diagrams

So far, we’ve seen that a state machine has some memory that stores the current state, that it must have come from some state, and that it will go to the next state. Our current diagram doesn’t show how it moves through states though. The goal should be to draw a map of the movement between states so we can write code that emulates our design. This is called a state diagram.

This is how I diagram the states of a state machine, using ideas from Moore and Mealy.

alt text

An abstract state diagram

Parts of the diagram:

  • The circle is the state

  • The colloquial name of the state is given in the top half of the circle

  • The output of the state is given in the bottom half of the circle. Sometimes this is explicit, like “X=1,” and the state behaves like a Moore, though sometimes it could be “OUTPUT = INPUT” where during that state, make the output equal whatever the input was. In this sense, the machine is very Mealy. I lump the two together for writing C state machines because it doesn’t really matter to the C construction of the machine.

  • The arrow is the state transition path.

  • The Xs, above the line, are the conditions for that state transition to occur. If the conditions are met, that will be the transition path.

  • The Ys, below the line, are things that happen during the transition. This concept deviates from the strictly digital logic world of Moore and Mealy and stems from the consecutive execution nature of C. While running a program, it’s easy for me to check for the transition conditions and do some one-time action while changing the states, so I put the actions under the conditions.

Always keep in mind that these are abstract representations of code and are a tool for creating higher levels of operation. Put as much detail as you need into the diagramming.

Consider a basic state that can move to a new state.

alt text

Simple state with incomplete set of state transitions

What happens if the exit condition is not met? I’ve cheated with my diagram and haven’t defined all possible actions of the state. Often I won’t quite know the full solution of my program until after the diagrams are made, and I embellish them as I go. With this diagram, I assume that if the conditions are not met, the state will go back to itself.

alt text

Fully specified state

Here, all possible state transitions are defined.

State diagram of the counter

Check out the behavior of the counter as drawn with a state diagram.

alt text

State diagram of a simple counter

Here, all possible states are represented with a single circle. The action of the state is to add one. To determine the next state, it’s easy to see that we only have one option, which is to go back to the state we were in.

The blink.ino Sketch

blink_fsm.ino

Let’s get out of the theoretic world by re-writing the familiar blink.ino sketch with the behavior and syntax of a state machine, using a switch-case. The example is to light the LED for 1 second, turn it off for 1 second, and repeat. Here there are two states, LED_ON and LED_OFF.

alt text

A basic LED toggler

In each state, the LED value is shown under the line. The arrows are each labeled TRUE because no matter what, we’ll move to the next state. This state machine doesn’t have any inputs. Every second, we’ll evaluate the state machine. If the state is 1, the output is 1 and move to the state 0. Here’s the C implementation:

Full source file (github): blink_fsm.ino

To make the state machine in C, create a variable that holds the current value of the state, define words for each numeric value that the state can be, and write a switch-case to evaluate the next state.

Defining the states:

//Define the states of the machine
#define LED_OFF 0
#define LED_ON 1

Creating the (global) state variable:

uint8_t fsm_state = LED_OFF;

So far, the state can be one of two options, so the smalles size data type is selected.

The state machine is built in the loop():

void loop(){
  //state machine
  switch (fsm_state)
  {
    case LED_OFF:  //Statements to execute every time LED_OFF is reached
      digitalWrite(13, LOW);
      fsm_state = LED_ON;
      break;
    case LED_ON:   //Statements to execute every time LED_ON is reached
      digitalWrite(13, HIGH);
      fsm_state = LED_OFF;
      break;
    default:
      break;
  }

  delay(1000);              // wait for a second
}

Every time the loop is executed, the state machine is evaluated. The state variable (fsm_state) is global, so it retains the state.

You may notice that every second we wait 1 second and evaluate the state machine. The extra code associated with the processing of the state machine will cause the cycle time to be greater than a second! It will run a little slow. This could be interrupt driven for better accuracy.

blink_fsm_ms.ino

I don’t want to have to wait for a whole second. I could be accomplishing other things during that time! I would rather process the state machine at some faster interval, like 1 ms, and stay in a single state 1000 times in order to delay.

alt text

A basic toggler that is clocked faster than the toggle speed.

With this design, I won’t leave the state unless the msCounts reaches 1000. The loop is delayed for 1ms instead of 1000ms. When the condition is true for a state transition to occur, the LED state is written and the counter is reset.

Full source file (github): blink_fsm_ms.ino

As before, the same states and state variable is used. The state machine is expanded to provide functionality if and only if the state transition is to occur.

switch (fsm_state)
{
  case LED_OFF:
    //Statements to execute every time LED_OFF is reached
    //Statements to execute when it's time to move to the next state
    if(msCounts >= 1000)
    {
      digitalWrite(13, HIGH);  //Process the next state's function
      fsm_state = LED_ON;
      msCounts = 0;
    }
    break;
  case LED_ON:
    //Statements to execute every time LED_ON is reached
    //Statements to execute when it's time to move to the next state
    if(msCounts >= 1000)
    {
      digitalWrite(13, LOW);  //Process the next state's function
      fsm_state = LED_OFF;
      msCounts = 0;
    }
    break;
  default:
    break;
}

Now, each state only moves if the state transition logic is true, using an “if” statement. Here’s where it’s obvious how easy it is to add 1-time tasks to the action of transitioning states. They’re just added to the “if” statement, and will be executed only when the state moves.

The state machine works but I’m not terribly happy about how it came out. Notice that the LED state is set LOW during the LED_ON state and HIGH during the LED_OFF state. It’s easy to run one-time code leaving a state, but not during the entrance of the state. It’s counter-intuitive to me and I think it can be made clearer by adding two more states, each that only wait.

blink_fsm_final

alt text

A toggler that uses an additional state to wait for the counter.

Here, the states LED_ON and LED_OFF write to the LED, clear the counter, and move on.

Timing and accuracy side note: The counter has been modified to 999 to account for the extra state, but it doesn’t help much. We’re getting farther off the faster we run the clock. This is because the time it takes to evaluate the state machine is starting to approach the total time to execute loop() INCLUDING the delay(1); statement.

Full source file (github): blink_fsm_final.ino

First, the extra two states are added to the list of #defines.

//Define the states of the machine
#define LED_OFF 0
#define LED_ON_WAIT 1
#define LED_ON 2
#define LED_OFF_WAIT 3

The state variable is the same so we’ll move on to the actual state machine implementation.

//state machine
switch (fsm_state)
{
  case LED_OFF:
    //Statements to execute every time LED_OFF is reached
    digitalWrite(13, LOW);
    fsm_state = LED_ON_WAIT;
    break;
  case LED_ON_WAIT:
    //Statements to execute every time LED_OFF_WAIT is reached
    if(msCounts >= 1000)
    {
      fsm_state = LED_ON;
      msCounts = 0;
    }
    break;
  case LED_ON:
    //Statements to execute every time LED_ON is reached
    digitalWrite(13, HIGH);
    fsm_state = LED_OFF_WAIT;
    break;
  case LED_OFF_WAIT:
    //Statements to execute every time LED_ON_WAIT is reached
    if(msCounts >= 1000)
    {
      fsm_state = LED_OFF;
      msCounts = 0;
    }
    break;
  default:
    break;
}

We see that the extra states have become extra cases in the switch statement. States that always move on simply assign the next state to the state variable. The delay states check the counts before assigning a new state, thus retaining the state they were in.

More timing side notes: Run the msCounts incrementer with a 1 ms timer Interrupt Service Routine (ISR) instead. Meanwhile, loop the FSM as fast as possible. This will correct timing. Keep in mind that if the code execution time between ISR calls (the state machine processing time) is longer than the ISR call interval, the program will most likely lock up.

“Yeah, so what? The LED was blinking to begin with!”

Please consider an alarm clock’s alarming functions. What would its behavioral model look like? The alarm clock has several states it can exist in and has a couple of inputs that can be used to control it.

States

  • Pleasantly keeping time
  • Vengeful alarm execution
  • Eagerly awaiting the end of the snooze cycle so it can wake you up again

Inputs

  • Arm switch
  • Snooze button

There are a few more, like time set and alarm set inputs, but this example is limited to just the alarm operations.

Described as a state machine:

alt text

The alarm functions of the alarm clock.

Try mentally walking through the operation of the state machine. I see that I can’t get from ‘idle’ to ‘ringing’ if the alarm clock is not armed. Also I can’t get back to ‘idle’ by pressing the snooze button, I have to disarm the alarm. This meets my internal definition of how an alarm clock acts, so I proceed.

There isn’t a way of actually tracking time yet, even if just for the experiment. Rather than keeping track of days, hours, etc. I want to only keep track of seconds. So I’ll need to count seconds. Well, the LED toggling state machine does that already! I’ll just change it to keep track and add the whole darn state machine in.

alt text

Re-using the blink state machine to count seconds.

As a benefit, I can block the blinking of the LED unless the alarm is going off, and use that as the debug output.

Here’s the full source file (github): alarm_clock.ino

Hardware connections:

  • Connect a normally open button between pin 7 and ground of an Arduino. This will serve as “SNOOZE.”
  • Connect a SPST switch between pin 9 and ground. This will serve as “ARM.”

The code is very similar to the previous examples, but has two state machines built up in it.

First, the timer state machine states and variables:

//Timer FSM numbers
uint16_t msCounts = 0;
uint16_t sCounts = 0;

#define LED_OFF 0
#define LED_ON_WAIT 1
#define LED_ON 2
#define LED_OFF_WAIT 3
uint8_t timer_fsm_state = LED_OFF;

Next, the alarm state machine states and variables. The alarm time is set to 15 seconds from reboot (actually about 20 with error), and the snooze cycle is set for 5 seconds.

//Alarm FSM numbers
#define ALARM_SECONDS 15
#define SNOOZE_SECONDS 5
uint8_t alarmActive = 0;
uint16_t nextAlarmTime = 65535;

#define ALARM_IDLE 0
#define ALARM_RINGING 1
#define ALARM_SNOOZING 2
uint8_t alarm_fsm_state = ALARM_IDLE;

Loop() evaluates both state machines each time it runs.

//timer state machine
switch (timer_fsm_state)
{
  case LED_OFF:
    //Statements to execute every time LED_OFF is reached
    digitalWrite(13, LOW);
    timer_fsm_state = LED_ON_WAIT;
    break;
  case LED_ON_WAIT:
    //Statements to execute every time LED_OFF_WAIT is reached
    if(msCounts >= 1000)
    {
      timer_fsm_state = LED_ON;
      msCounts = 0;
    }
    break;
  case LED_ON:
    //Statements to execute every time LED_ON is reached
    if(alarmActive == 1)
    {
      digitalWrite(13, HIGH);
    }
    timer_fsm_state = LED_OFF_WAIT;
    break;
  case LED_OFF_WAIT:
    //Statements to execute every time LED_ON_WAIT is reached
    if(msCounts >= 1000)
    {
      timer_fsm_state = LED_OFF;
      msCounts = 0;
      if( sCounts < 0xFFFF )
      {
        sCounts++;
      }
    }
    break;
  default:
    break;
}

uint8_t buttonValue = digitalRead(7);
uint8_t switchValue = digitalRead(9);

//alarm state machine
switch (alarm_fsm_state)
{
  case ALARM_IDLE:
    if((sCounts >= nextAlarmTime)&&(switchValue == 0))
    {
      //Goto next state
      alarm_fsm_state = ALARM_RINGING;
      alarmActive = 1;
    }
    break;
  case ALARM_RINGING:
    if(buttonValue == 0)
    {
      nextAlarmTime = sCounts + SNOOZE_SECONDS;

      alarm_fsm_state = ALARM_SNOOZING;
      alarmActive = 0;
    }
    if(digitalRead(9) == 1)//If switch went off, goto idle instead
    {
      alarm_fsm_state = ALARM_IDLE;  // this overwrites the snooze button option
      alarmActive = 0;
    }
    break;
  case ALARM_SNOOZING:
    if(sCounts >= nextAlarmTime)
    {
      //Goto next state
      alarm_fsm_state = ALARM_RINGING;
      alarmActive = 1;
    }
    if(switchValue == 0)
    {
      //Goto alarm idle
      alarm_fsm_state = ALARM_IDLE;
    }
    break;
  default:
    break;
}

To operate, close the “ARM” switch and load the program.

Conclusion

In my experience, any coder who can diagram a program before writing it will succeed at the program. I’ve written one too many programs that ended up as a wad of nested ‘if’ statements because I didn’t plan ahead. Inevitably, I needed to add one little thing that horribly broke the program and I was forced to re-evaluate my life choices. Using tools like state machine diagrams, flowcharts, class diagrams and unit tests have allowed me to write more complex yet maintainable code (while staying relatively sane). The state machine is just another idea to have in the toolbox and I hope that it will help you in the future!

comments | comment feed

Arduino web architecture, back to the future

via Arduino Blog

post

The last couple of months have been the most exciting of my entire career. Here at Arduino we are doing a big shift in terms of technology, user experience, and web improvements.

A new Arduino web ecosystem is arising, and the first hint of this new approach is visible in the Arduino Day website. This single-page website was the perfect fit to start experimenting with some new technologies we wanted to put in production. The Arduino Day website was a testbed for some new features of the new architecture we want to achieve.

Goals

  1. Website online and running 99.98% of the time
  2. Fast on every device
  3. Easy way to push updates online
  4. New theme with a single page app
  5. Clear division between presentation and functionalities (client/server architecture)
  6. Https whenever is possible
  7. Microservices

People

How did we achieve these results? It has been a challenge but, from November on, we started building a new Web team with a good mix of junior and more experienced developers. Putting together the team has been key, but we also needed to change some aspects of the way we work.

The team has been always under a tight schedule, at first we started fixing legacy bugs all around, many are still in progress, but we also started experimenting with new things. We started following the agile development methods, including a daily standup meeting to better coordinate our team of designers and developers, we create dedicated topic channel in our chat system to better tackle issues and follow the improvements roadmap, and we created clear todo lists organized by priority.

Continue reading

Raspberry Pi Powered Minion Fart Gun Machine

via Raspberry Pi

The Raspberry Pi Powered Minion Fart Gun Machine. It’s got LEGO. It’s got an ultrasonic proximity sensor. It’s got farts. We loved it.

Paul Weeks‘ kids are the proud owners of a Minion Fart Gun. It’s a toy reproduction of a despicable gadget from the movie Despicable Me 2.

minions

fartgun

(You can buy your own Fart Blaster on Amazon – but this project will work with any toy that has a trigger mechanism.)

Paul had an ultrasonic sensor kicking around from some other Raspberry Pi projects he’d worked on with his kids (the Scratch Ultrasonic Elephant Cheese-Puff Game is a thing of beauty, and we commend it to you). He also had a box full of LEGO Technic. He brought everything together with his kids to make beautiful music fart noises when someone approaches the setup.

Paul has created a thorough writeup, complete with code. It’s a fun project; you’ll learn about controlling motors, how ultrasonic sensors work, and how best to annoy family members going to the loo in the dark in the middle of the night. Thanks Paul; we salute you! (Please don’t come near us with that thing.)

SparkFun and the Future of Arduino

via SparkFun Electronics Blog Posts

Much has been made about the on-going (and seemingly far from over) Arduino v. Arduino SLR saga.

alt text

Arduino vs Arduino

On one side is Arduino, which was founded by Massimo Banzi, David Cuartielles, David Mellis, Tom Igoe and Gianluca Martino back in 2009. This is the Arduino where you have probably gone to participate in forums, download the Arduino IDE and more.

On the other side of the battle is the manufacturing side of the project founded by Gianluca Martino, known as Arduino SLR. This outfit used to be called “Smart Projects” but changed their name to Arduino SRL in November 2014. From early on, they’ve been a large manufacturer of Arduino boards. Recently, they popped up under the domain Arduino.org.

We could hash out the specifics of the argument, but that’s been done ad nauseam in many places. If you want to get caught up, Hackaday did a nice job summarizing the story in this article. So which side of the dispute does SparkFun Electronics stand on? Well, as with many legal disputes, it’s not cut and dry.

SparkFun’s number one priority is, and always has been, our customers. Besides the very obvious fact that it’s your purchases that keep the doors open and the lights on, the truth is, many of us in this building exist in the very same stratosphere as you guys and gals. We’re DIY hobbyists, and engineers, and wearable-enthusiasts, and high-altitude balloon pilots. So, at the end of the day, we want to have the coolest, best, and most reliable products available for our customers to build the projects they (and we!) want.

So with that in mind, we’re kind of stuck between a rock and a hard place. Right now, we are actively buying (and will continue buying for the time being) Arduino Uno’s from Arduino SRL. Are we siding with them? Not necessarily – but currently this is the only source we have for the Arduino Uno, a board that you, our customers, love. The alternative is to not stock this board, which isn’t much of an alternative at all.

We are just as worried about where this is heading as you are. Is Arduino going to be around in a year? We believe the community will never die but we’re nervous about the hardware. Hardware is hard and spinning up contract manufacturers takes considerable effort and time.

SparkFun RedBoard - Programmed with Arduino

DEV-12757
$ 19.95
33

Above you’ll see the SparkFun RedBoard. We created this board in 2012 because our Inventor’s Kit, which used the Arduino Uno, was becoming more and more popular. Around that time Arduino came out with the Uno R3 revision that caused, overnight, all our documentation to become obsolete. It was decided then that we needed to be in control of our supply chain for our most popular products. So we made the RedBoard, which takes some of our favorite features from various Arduino boards (like the Optiboot bootloader and the stability of the FTDI from the old Duemilanove). Needless to say we are thankful the SIK and the RedBoard are shielded from the current Arduino events.

alt text

The RedBoard hooked up to our PIR Motion Sensor

Since its inception we’ve offered to pay royalties on the RedBoard. We’ve been building and will continue to build hundreds of thousands of the official Arduino Pro, Pro Mini, Fio, and LilyPad. The royalties will continue to go to Arduino.cc, the folks we license the US trademark from. Recently we’ve offered to license and manufacture the other official Arduino boards: Zero, Uno, Mega, Due.

We are here to support the community as much as possible. We don’t want mom and dad to fight – it’s bad for the community but it happens. We will continue to buy the boards we don’t internally produce from whatever source necessary so that our customers can get what they need and, ultimately, vote with their dollars.

So that’s it. Is that a non-stance, stance? Sort of. But, ultimately, our “side” isn’t with Arduino or Arduino SRL – it’s with our customers. We will continue to do our best to bring you the products you want and need to make your electronics projects possible.

comments | comment feed

Python in Education – free e-book from O’Reilly

via Raspberry Pi

This week PyCon is going on in Montreal – it’s the big worldwide Python conference – and for the occasion, O’Reilly asked our friend Nicholas Tollervey to write a free short book on Python in Education.

python-in-education

Click to download the book for free

The book tells the story of Python, why Python is a good language for learning, how its community gives great support, and covers Raspberry Pi as a case study.

You’ve probably heard about the computing revolution in schools, and perhaps you’ve even heard of the Raspberry Pi. The Python programming language is at the center of these fundamental changes in computing education. Whether you’re a programmer, teacher, student, or parent, this report arms you with the facts and information you need to understand where Python sits within this context.

Author Nicholas Tollervey takes you through the features that make Python appropriate for education, and explains how an active Python community supports educational outreach. You’ll also learn how Raspberry Pi is inspiring a new generation of programmers – with Python’s help.

Nicholas visited Pi Towers in February to speak to Carrie Anne, Eben and me about why we think Python is suited to education. He asked Eben how the idea for the Raspberry Pi hardware came about and why there was a need for an affordable hackable device. He asked us about the Python libraries those in the community provided (particularly RPi.GPIO and picamera) that we consider part of our infrastructure for education and hobbyist users alike; and about the sorts of projects that engage, empower and inspire young learners – and of course the way they learn and progress. We discussed Minecraft Pi, hardware projects, Astro Pi, PyPy, teacher training and more.

Read more on teaching with Python from Nicholas and download the book for free from O’Reilly.

Let’s make robots exploring lake depths

via Arduino Blog

searendering

Sea Renderings is a water robot made by Geir Andersen in 2010 with the aim of measuring water depths in lakes and running on Arduino Duemilanove:

The purpose of this robot is to have it log water depths along a predefined set of waypoints. It stores its data on memory sticks or on SD cards. The estimated runtime is about 24 hours and with a top speed of 3km/h it will travel roughly 72km. With a log entry for every 10m this would give us over 700 depth measurements with full GPS reference.

searendering02

Geir’s project page is hosted at Let’s Make Robots,  a free and volunteer based initiative produced and maintained by members of the robot building  community. You can have a look at the documentation and some of the illustrations showing the output of the measurements done at Lake Riskedalsvatnet in Norway.

searenderings03

 

SparkFun Fast Company Feature

via SparkFun Electronics Blog Posts

SparkFun is Radioshack for the Maker Crowd

Thus reads the headline for Fast Company writer Rob Walker’s recent piece about SparkFun. We were first put in touch with Rob back in October, when he contacted us with an interest in doing a piece about SparkFun.

alt text

Photo via Benjamin Rasmussen, Fast Company

Rob interviewed several people from SparkFun – most notably our CEO Nate Seidle (pictured above working on a SparkFun Inventor’s Kit) and our Creative Technologist Nick Poole (of product demo fame).

We weren’t entirely sure what the article Rob was working on would say – like any good journalist, Rob plays his cards close to his chest and we really had no idea in what direction the article would ultimately head.

alt text

So yesterday, we finally saw the article that had been months in the making – it’s a really cool piece and it’s awesome to see SparkFun in a publication like Fast Company.

So what do you think about the comparison? Is SparkFun the RadioShack for Makers (hopefully without all that messy bankruptcy business?

We certainly want to be the go-to source for the stuff you need to complete your projects. We work hard to keep our finger on the pulse of the DIY community and get the coolest products around. Maybe SparkFun is the RadioShack for Makers…just hopefully the RadioShack from circa 1982 and not the current one with a -$350 million dollar operating income.

Thanks to Rob for the awesome writeup!

comments | comment feed

Launching Picademy@Google Leeds

via Raspberry Pi

We love introducing educators to the Raspberry Pi; that’s why the education team are always on the road, at conferences, shows and events, sharing the Pi’s learning potential. Last year, we started a teacher training programme, and invited educators from all over the world to our headquarters for some fun hands-on learning. We called it Picademy. It’s been hugely popular, and so far we’ve trained around 200 teachers through seven events in our own unique way. The feedback has blown us away. Of those who completed our feedback questionnaire:

  • 97.5% stated that they were now likely or very likely to use Raspberry Pi in their classroom, and 
  • 98.8% stated that they were likely or very likely to share the training received with other teachers.

So we have a problem. We want to train thousands of educators – no – hundreds of thousands of educators, and that’s not possible for our tiny education team, even though it’s made up of a cracking bunch of superstars. Picademy is always oversubscribed.

We have huge ambitions for education. Thanks to the generosity and support of Google, we think we are heading in the right direction. Today we are excited to announce our new Picademy@Google programme for educators, kicking off in Leeds, UK. This is another opportunity for primary, secondary and post-16 teachers to attend Raspberry Pi-flavoured computing and science training, but this time at a Google Digital Garage near where you live. The Digital Garages are a group of pop-up spaces – this first one located in Leeds Docks – which will help 200,000 British businesses learn crucial skills for the digital age, and use the power of the internet to reach more customers and grow faster.

Here is trustee Pete Lomas with Lauren Hyams (Code Club Pro) and Roger Davies (Computing at School) who will also be offering teacher training opportunities at the Digital Garage

Here is Raspberry Pi Foundation trustee Pete Lomas with representatives from Code Club Pro and Computing at School (who will also be offering teacher training opportunities at the Digital Garage) at the launch event in March.

The Picademy@Google courses will be run by hand-picked community members and educators, and will be a a mix of hands-on making, project-based learning and general hacking (think Picademy meets Raspberry Jam!) They will run alongside our definitive Picademy course and are, as always, completely free to attend for teachers.

We will be launching Picademy@Google in other UK cities as Google Digital Garages open over the next few months – to be informed about when one opens up near you, please sign up to our education newsletter.

The Leeds Digital Garage will be open between now and November, and we’ll be running a number of Picademy@Google courses there, so start spreading the news: sign-ups for teachers are open!

 

Old Fluorescent Fixtures Turned Into Fill Lights

via Hackaday » hardware

The Tymkrs are hard at work setting up their home studio, and since they’ll be shooting a few videos, they need some lights. The lights themselves aren’t very special; for YouTube videos, anything bright enough will work. The real challenge is making a mount and putting them in the right place, With a shop full of tools, making some video lights isn’t that hard and easily translates into a neat video project.

The lights began their lives as large fluorescent fixtures, the kind that would normally house long fluorescent tubes. The Tymkrs cut he metal reflector of this fixture in half, capped the ends with wood, and installed normal incandescent sockets in one end.

The inside of this reflector was coated with a reflective material, and a beautiful rice paper diffuser was glued on. The Tymkrs attached a metal bracket to these lights and screwed the bracket to the ceiling. There’s enough friction to keep the lights in one spot, but there’s also enough play in the joints to position them at just the right angle.


Filed under: hardware