I got an idea, and it was hopefully at the right time. If you turn an egg carton upsidedown you can see five deep holes and I figured tht if I could fill those holes with light it would look rather nice. And indeed it did. I must be some kind of an average genious (did I spell that right?).

So what I did was to fit one rgb blinking led in each top (or bottom) of the egg carton egg divider sphere, soldered them to some wires, added a battery and woila, it looks pretty from the sides, it is in fact a litle to bright when you watch it straight on, but not as bright as in the videos . My phone camera have an isue with led lights.

Kine made a yellow dog, a black monkey and a white flower. arent they pretty?

Having two apprentices when you are just a master student sound like a great deal of responsibility, and I, the mighty master student, can agree on that. In fact it is almost to much responsibility, but luckily for me they are for the most part obedient, at least if it is not on a day where a horde of web comics are released, if that is the case Kyrre is lost in the depth of the all-knowing interwebz.

The master plan of the research lords are to provide the general public with a programing language that the simplest peasant can program as if he was the king of programmers. This new glorious programming language are called ThingML and is supposed to be able to
program
all the things
One of the visions the research lords have is that everything that is programmed should be able to access the all-knowing interwebz, and since the interwebz is in fact all-knowing all things that are interlaced with the interwebz could also be all-knowing. Imagine the wast amount of things that would know everything. Your toaster could know what the weather is, your fridge could know today’s quests, your electric toothbrush could know your kill count and the TV schedule and your computer could know how often you brush your teeth, how often you open your fridge and how often opening the fridge results in  a toast.

This is a vision well shared with the mighty master student, and a vision that I, the mighty master student, are trying to push down on my apprentices.

To get my apprentices to fully grasp this great heaven like  idea I must train them like only a mighty master student can do, and I believe that the best way to train is to head out to life threatening programing quests that could fail miserably or bring home gold and fortune to your fellow programmers.

This day I sent my young students on a very dangerous quest, and I must admit that I was not expecting either of them to complete this task by the end of this day, but in fact they both manage to shine through and prove them self very special. The quest the mighty master student gave them on this glorious day was to make a potentiometer of doom to control the timer interrupts of great descending and ultimately control the rate of which a mystical LED is blinking. This was not a trivial quest, one might thing so, but only if one have yet to try out the magnificent language of ThingML. It is a state machine oriented language that requires you to program the potentiometer of doom in one realm and the mystical LED in a whole another realm. This I did not know in my youth and had to learn the hard way, by trial and error and then directly from the research lords. My apprentices on the other hand got this knowledge as a hint in the quest description.

You might also wonder how the apprentices solved this quest, and I will tell you that great tale. They used the simplest of logic, they avoided all bloathiness by dodging all dangerous obstacles through learning and exploring of all great things in the land of ThingML. They traversed files and found hidden messages that could travel through enchanted ports and trigger old mythological states to act on newly discovered input from the potentiometer of doom. They did well and earned them self a great loot of XP and wisdom.

In fact they did better then their almigty teacher and earned more xp then I did on that spesific quest in my youth. Not only did the both manage to finnish the quest with a lower linecount, but also by using fewer enchanted ports and hidden messages.

But in order to show you, the reader of this tale, that I am not a noob, but still better then my two young padawans, my code had the great ability to cancel out any timer events on the LED and restart it when needed, theirs code could not.

Here you can see Kyrres code

import "../../hardware/bricks/led.thingml"
import "../../hardware/io/analog_input.thingml"

thing portRGB includes TimerMsgs, LedMsgs, AnalogInputMsgs {

   property temp : UInt16 = 100

   required port timer {

       receives timer_timeout
       sends timer_start, timer_cancel
       }

   required port led {

       sends led_on, led_off, led_toggle

       }

       required port input {
           receives analog_input_value
           sends read_analog_input
           }

       statechart portRGBImpl init green {

           state Led {

               on entry do
                  timer!timer_start (temp)
               end

               transition->Led
               event timer?timer_timeout

           }
           region potMeter init pot {

             state pot {

                      on entry do
                      input!read_analog_input ()
                      end

                      transition->pot
                      event m: input?analog_input_value
                      action do
                         if(m.value > 1) do
                             temp = m.value
                          end
                      end

           }
       }
    }
}

And here comes the code that I, the almighty master student, wrote in my youth:

import "../../hardware/io/analog_input.thingml"
import "../../hardware/bricks/led.thingml"

thing AnalogReadBlink includes AnalogInputMsgs, TimerMsgs, LedMsgs{

    property freq : UInt16 = 0

    required port TimerPot
    {
        sends timer_start
        receives timer_timeout
    }
    required port TimerLed
    {
        sends timer_start
        sends timer_cancel
        receives timer_timeout
    }

    required port Led
    {
        sends led_toggle
    }

    required port AnalogInput
    {
        sends read_analog_input
        receives analog_input_value
    }

    message update();

    provided port ReceiveUpdate
    {
        receives update
    }
    required port SendsUpdate
    {
        sends update
    }    

    statechart AnalogReadBlinkImpl init ReadPot
    {
        property delay : UInt16 = 100

        state ReadPot
        {
            on entry do
                AnalogInput!read_analog_input()
                TimerPot!timer_start(20)
            end

            internal event m : AnalogInput?analog_input_value
            action do
                if( not (delay == m.value)) do
                    if( not (m.value == 0)) do
                        if (m.value < delay - 3 or m.value > delay + 3) do
                        delay = m.value
                        SendsUpdate!update()
                        'Serial.println('& m.value &');'
                        end
                    end 

                end
            end

            transition -> ReadPot
            event TimerPot?timer_timeout

        }

        region Led init Blink
        {
         state Blink
         {
             on entry  do
                Led!led_toggle()
                TimerLed!timer_start(delay)
             end

             transition ->Blink
             event TimerLed?timer_timeout

             transition -> Blink
             event ReceiveUpdate?update
             action TimerLed!timer_cancel()
         }
    }
}

Okay, lets start of with the pin declaration:

int sekData = 11, minData = 8, hourData = 5;
int sekClock = 12, minClock = 9, hourClock = 6;
int sekLatch = 13, minLatch = 10, hourLatch = 7;

As you can see, I use nine pins, three for each shift register. Then I also have to define them as output pins in the Arduino enviroment.

  pinMode(sekData, OUTPUT);
  pinMode(sekClock, OUTPUT );
  pinMode(sekLatch, OUTPUT);

  pinMode(minData, OUTPUT);
  pinMode(minClock, OUTPUT );
  pinMode(minLatch, OUTPUT);

  pinMode(hourData, OUTPUT);
  pinMode(hourClock, OUTPUT );
  pinMode(hourLatch, OUTPUT);

Then I must assign a variable to store the time in minutes and hours, notice that I don’t do anything about the seconds, this is because I don’t feel that I need the functionality to set the seconds.

  int i = 13;
  int j = 43;

i is for hours and j is for minutes.

Then the first thing I want to do in the setup method after making the pinMode statements is to flush all the shift registers to avoid having old data in them. This is done by calling three methods I have written. Also I’m attaching two interrupts, and we have code that looks like this:

  //Flasher sekund ledsa
  updateSek(0);
  //Flusher min og time registeret
  updateMin(j);
  updateHour(i);
  //Setter interrup handlere
  attachInterrupt(0, setMin, RISING);
  attachInterrupt(1, setTime, RISING);

As you might see the two interrupts are calling on two methods called setMin and setTime, which basically means set minute and set hour. Don’t mind my Norwegian coding style ;) It is mainly to confuse myself ;)
But anyways, these two methods are defined like this:

void setMin(){
  j++;
  if(j == 60)
  {
    j = 0;
  }
  digitalWrite(minLatch, LOW);
  shiftOut(minData, minClock, MSBFIRST, j);
  digitalWrite(minLatch, HIGH);
}

void setTime(){
  i++;
  if(i == 24){
    i = 0;
  }
  digitalWrite(hourLatch, LOW);
  shiftOut(hourData, hourClock, MSBFIRST, i);
  digitalWrite(hourLatch, HIGH);
}

Ok, now it is time to start up the clock with the loop method, and this method is really simple, it waits one second, and updates the seconds counter, and if necessary, the minutes and hours as well. And it all looks like this:

void loop(){

  //løper gjennom alle sekundene
    for(int k = 0; k < 61; k++){
       if(k == 60){
        k = 0;
        j++;
         if(j == 60){
          j = 0;
          i++;
          if(i == 24){
            i = 0;
          }
         }
       }
      // Serial.print(k);
      // Serial.print("-");
      // Serial.print(j);
      // Serial.print("-");
      // Serial.println(i);
       updateSek(k);
       updateMin(j);
       updateHour(i);
       delay(1000);
    }
}

And then, at last the three methods that updates the shift register

void updateSek(int value){
  digitalWrite(sekLatch, LOW);
  shiftOut(sekData, sekClock, MSBFIRST, value);
  digitalWrite(sekLatch, HIGH);
}

void updateMin(int value){
  digitalWrite(minLatch, LOW);
  shiftOut(minData, minClock, MSBFIRST, value);
  digitalWrite(minLatch, HIGH);
}

void updateHour(int value){
  digitalWrite(hourLatch, LOW);
  shiftOut(hourData, hourClock, MSBFIRST, value);
  digitalWrite(hourLatch, HIGH);
}

And now, at last I will put all this code together for you to enjoy in case you didn’t manage to put it together in the right fashion yourself

//Setter pins på shift registerne
int sekData = 11, minData = 8, hourData = 5;
int sekClock = 12, minClock = 9, hourClock = 6;
int sekLatch = 13, minLatch = 10, hourLatch = 7;

//Setter bare litt tilfeldig starttid på klokka
  int i = 13;
  int j = 43; 

void setup(){

  //PinMode på alle shiftregisterne
 pinMode(sekData, OUTPUT);
 pinMode(sekClock, OUTPUT );
  pinMode(sekLatch, OUTPUT);

 pinMode(minData, OUTPUT);
 pinMode(minClock, OUTPUT );
  pinMode(minLatch, OUTPUT);

 pinMode(hourData, OUTPUT);
 pinMode(hourClock, OUTPUT );
  pinMode(hourLatch, OUTPUT);
  Serial.begin(9600);
  //Flasher sekund ledsa
  updateSek(0);
    //Flusher min og time registeret
  updateMin(j);
  updateHour(i);
  //Setter interrup handlere
  attachInterrupt(0, setMin, RISING);
  attachInterrupt(1, setTime, RISING);

}
//To metoder for stillig av klokka
void setMin(){
  j++;
  if(j == 60)
  {
    j = 0;
  }
  digitalWrite(minLatch, LOW);
  shiftOut(minData, minClock, MSBFIRST, j);
  digitalWrite(minLatch, HIGH);
}

void setTime(){
  i++;
  if(i == 24){
    i = 0;
  }
  digitalWrite(hourLatch, LOW);
  shiftOut(hourData, hourClock, MSBFIRST, i);
  digitalWrite(hourLatch, HIGH);
}

void loop(){

  //løper gjennom alle sekundene
    for(int k = 0; k < 61; k++){
       if(k == 60){
        k = 0;
        j++;
         if(j == 60){
          j = 0;
          i++;
          if(i == 24){
            i = 0;
          }
         }
       }
     //  Serial.print(k);
      // Serial.print("-");
      // Serial.print(j);
      // Serial.print("-");
      // Serial.println(i);
       updateSek(k);
        updateMin(j);
        updateHour(i);
       delay(1000);
    }
}

//The f do u think?
void updateSek(int value){
  digitalWrite(sekLatch, LOW);
  shiftOut(sekData, sekClock, MSBFIRST, value);
  digitalWrite(sekLatch, HIGH);
}

void updateMin(int value){
  digitalWrite(minLatch, LOW);
  shiftOut(minData, minClock, MSBFIRST, value);
  digitalWrite(minLatch, HIGH);
}

void updateHour(int value){
  digitalWrite(hourLatch, LOW);
  shiftOut(hourData, hourClock, MSBFIRST, value);
  digitalWrite(hourLatch, HIGH);
}

Happy thrill.

These days I’m writing an article on how to improve transitions written in ThingML and showing of the great results I get, but writing an article is a little different from writing the master thesis, for starters, there is no front page, and it have to be in two columns. Needless to say I didn’t know how to do that, so I googled, I found, I wrote. Here I will put my article template for further reference.

\documentclass[11pt,twocolumn]{article}

\begin{document}

\title{Something about ThingML Transitions}
\author{
    Jan Ole Skotterud\\
    Institute for Informatics\\
    University in Oslo\\
    janoleos@ifi.uio.no
}

\maketitle

\begin{abstract}
The abstract text goes here.
\end{abstract}

\section{Introduction}
Here is the text of your introduction.

\subsection{Subsection Heading Here}
Write your subsection text here.

\section{Conclusion}
Write your conclusion here.

\end{document}

This will provide the foundation to write great articles that can be approved and cherished in scientific circles.

I also figured that my supervisor also might wan’t to have his name on the top of the first page and that required me to do some more googleing, the result that came back was the little but efficient TeX command \and, and there I could add more authors. Like this:

\author{
    Jan Ole Skotterud\\
    Institute for Informatics\\
    University in Oslo\\
    janoleos@ifi.uio.no
  \and
    First Last\\
    Institute\\
    Uni\\
    Mail
}

And just like that I have made my first reference blog post for LaTeX.
Jippi Kay Yey Article Writer

Hehe, I also wanted a LaTeX related image for the header, so I googled latex, not a clever idea…..

Through the day a lot of people came by to congratulate me, I even got some sweet gifts. Some of the gifts I got was cola, bamsemums, cola, Kinderegg, cola, a thsirt with linux. cola, cola, a origami bird ++.

After a while Kine came by with food and cake, and the timing was great. It had been just enough time since lunch so most people managed to eat some more cake. You can never eat enough cake.

After most people had went home, I got some time alone at school to actually get some work done and after half an hour Frode called and we went to his place and took a couple of beers. Life was good.

Then it was time to get home and spend the last hour of the day with Kine. From her I got two expansion packs to Dominion. I got Cornucopia and Alchemy. We played a couple of rounds and then the last sms ticked in. And guess what, I had become an uncle again.

Ulrik came to the world 17.01.12 22:34. Weight 2440g and was 49 cm long.

Sooooo, little nephew. I guess we will have to come to an agreement on the newly acquired birthday issue……..

Starship troopers is a great movie that I have seen many times since it first came out in 1997, it have great animations, super effects and superduper hidden messages about the American society although most people think that it is references to the Nazis.

So back to movie two and three in the series, as the first one had a budget of 100 000 00 dollars, and number two and three had a budget of approximately 9 000 000 and 7 000 000 dollars they were doomed to not keep the standard of the first one. (ref imdb.com)

I have always heard a lot of crap about those movies, and therefore I have never watched them before now, and now I wish that I could use four hours to unsee them. It was bad, really bad.

The second movie was the best of those two, it had the same great animations from the first movie, I figure that they just reused it, fair enough.  But they changed the complete cast,  what is that all about? No more Neil Patric Harris and Carmen Electra. What have the world come two? According to the movie it had come to be a worse place….

Damn, I don’t want to write more about those crappy movies, but here comes some more. The third movie was a fuck up without any equal. The animations were badder, much badder. It’s like they hired two 10 year old kids to re animate everything. The guy who played John Ricco in the first movie was back, but unfortunately he was not allowed to do any acting in the movie, they just filmed him saying emotionless uninspired lines and sometimes he shoot at things. They also included Christianity and faith in the movie as one of the main things. And they even tried to display it as it was faith in god who ultimately saved the human race. What a bunch of bullshit.

If i ever but these movies, it must be so I can break them and throw them away.

I give them a solid 1 in total even though Starship troopers 2 was slightly better.

So, as you can see everybody (at least all ten of them) voted on me, and my though was that if they wanted me to make them cake, I sure would make them some great cake.

The next step of my cake plan was to get some inspiration and I googled terms like “cool cake” and “awesome cake”. I don’t remember which term that guided me towards the great idea, but I found a rainbow cake with a lot of colors inside, it looked fantastic. It just had to be that cake. Now I needed a lot of things, mostly regular cake baking things like flour, sugar, eggs and so on, but also real good and vibrant food coloring stuff. Kine told me about this great store called Cacas, I googled it and found that they had everything cake related that you can ever need so I went there and bought eight colors and some pens that can draw on cakes.

After i came home again I consulted with Kines mother about the cake bottoms and the marzipan. She know her cakes and you can see some of them here if the album is public http://www.facebook.com/#!/media/set/?set=a.1474505429696.2064173.1445499252&type=3.

Then it was time to start stacking the cake layer for layer. I started off with one cake bottom, soaked it a little with a little saft (yes that is a norwegian word). Then I added raspberry jam and a new cake layer. From here on out I used whipped cream and vanilla cream for every other layer and stacked all the colored layers on top of each other.

Then I covered the rest of the cake in cream an put marzipan on top of the whole cake. The I decorated it with different drawings with references to games, programing, Ifi, cartoons and the Internet. Everything was something that meant something to someone in our group.

Here some pictures from the baking process and the eating process will follow:

Also thanks to Lill for this cool comment:

State machines are a really old concept and is used in computer science a lot. It is most widespread in the world of software modeling and robotics (I do believe, but can not base that statement on facts because I don’t care to google it right nao). The reason for me to suddenly have a interest in state machines, when I merely have used them in one course before, is that they turned up to be an important part of my thesis and therefore I must obtain some interest and knowledge about them. While  playing around with a newly developed language called ThingML I found that the way transitions were defined may not be the best and most effective way to write them. It sure wasn’t the most intuitive way to write them. This is one transition definition in ThingML:

transition -> NameOfNextState
event Port?Message
guard ( CONDITION )

Here we say that we are going to have a transition which will lead us from the current state to NameOfNextState. This will happen if we get a message through the port and that message meat the guard condition. Easy, right? Yes indeed.

So what is the problem then? you might ask. Well, the transition definition you can see above is supposed to be written inside a state, and each state that have a transition that can lead to another transition need one of these transition definitions. So given that we have three states as seen in the next diagram, here we have three transitions one from S1 to S2, one from S2 to S3 and one from S3 to S1.

In this scenario there is really no need to change anything, there is perfectly alright to write each of the three transition statements in their corresponding state. But if we infer that every state should be able to transact into any of the other states when a specific event occurs, then the diagram will look like this:

In this example we actually have to write all the transition definitions twice, this is because both S3 and S1 leads to S2 and therefore the same transition declaration have to be written both places. This results in us writing six transition definitions instead of three. That is double the amount. Now if we add one state and let the same rules apply we will end up writing twelve transition definitions instead of four. This starts to seem like a lot of work, right? Now imagine a sophisticated robot which have eight different states and that no mater which state it is in, it can jump to any of the other states directly. This means a lot of transition definitions and remember when you look at the picture you have to write one for each line…. That is 56 to be rather precise for once. And we can abstract the rule n*n-1 = number of transitions where n = number of states. and all states leads to all other states.

In all of the above examples there is a small detail that I have neglected and that is the fact that a state can also transact to itself. This will add n to the equation and the rule will look like this n+(n*n-1) = number of transitions. Which can be shortened into n*n = number of transitions.

My solution

So as you already might have understood I want to eliminate the redundancy that occurs when you write the same declarations several times, but to be able to do this I must create a new way of declaring transitions and take into account all the special cases that might occur. It is important to say that what I am about to propose as a great change to the ThingML language is only a great change in the cases where several states can lead to a number of other states and that most of the transitions leading to one state are triggered by the same message no mater which state the state machine are in at the current time. If this is not the case then the old way of writing transition declarations are still a good alternative. The first example I wish to offer is a visual one, you have seen a state machine with eight states where each state have a transitionto every other state. This is how I wish for four states to be symbolized. The arrows comes from an outlying event queue

My first suggestion on how to write the transition definitions looks like this:

transitions m : Light.value {
    (m.value < 40) -> State2
    (m.value >= 40) -> State3
}

This code block is to be placed outside the statechart, but inside the thing scope(these are ThingML components, to learn more about them go to thingml.org).  The transitions scope are intended to contain all transitions that are to trigger depending on a given message from a given port, in this example the value message from the Light port (Light.value). Then each transition are defined with one line, the first part of the line is the guard condition, this part is essential since without a guard the first transition would be triggered every time. The guard condition should also be a logical expression with the received message as one of the attributes. The last part of the line is the State that the transition are  leading to. In this part there is also an optional part which is the name of the transition, this one is only good to have if you are to make a model of your code, then the transition on the model will receive the name you have given it. The name are written between the guard condition and the arrow. like this:

 (m.value < 40) TransitionName -> State2

This way of writing transitions might at first glance seem like a good way of doing it, at least it did for me. But when you stop to think about it there are several things that isn’t covered and could cause problems. But I will try to solve them one by one from here on out. The first thing I need to do now is to create a real “functional” example that makes sense that we can use forward in this post. I found a example online using the popular robot Bender, that example was showing one implementation that are quite ok, but it is still a couple of things there that I don’t agree with. Anyhow, they display two State machine diagrams, the first one shows what Bender should be able to do, the other one is an optimization, but I believe that it takes away states and are not as good in showing of what bender should be able to do. You can see them here:

In the optimalizated version the stopped state seems to be missing, or it could be included in TurnedOn. But I feel that Bender should be awesome enough to go directly from one activity to another without going back to the turned on state first (ref figure one) and I think that Bender should be able to go from a activity to the turned off state without going through the turned on state first (ref figure two). Therefore to illustrate this I drew my own state machine diagram, it looks really complex and messy, but that is what we get from having the possibility to go from a state to almost any other state.

To bad there ain’t a bidirectional arrow…. Anyhow, When the Bender program is started he is in TurnedOff mode, consider this the initialization of Bender, After this he can move into turnedOn mode from here Bender can turn into every state in the diagram. In the activity states, Walking, running, raising arms, stopped and so on he can switch to any other state EXCEPT from TurnOn, this is because the obvious fact that Bender have to be turned on in order to perform any activities except from actually turning himself on. So what is Benders setup? I want to imagine that he have a knock sensor in his head and if this sensor register that he is hit in the head he is supposed to chant out a negative comment in a fashion that fits Bender. Also he have a distance sensor in his eyes that makes him run if he is more then 5 meters away from anything, he walks if he is closer then 5 meters and if he is about 10 centimeters away from any object he stops.  At this point you might shout out that I am stupid and that if he is chasing anything and gets closer he will first be running, then walking an then when he gets close enough he will be stopping. Therefore you might argue that he always have to walk before he stops. But I say that a meteor might fall in front of him while he runs forcing him to stop, therefore he must be able to come to a full stop while running. Bender also have functional ears and can hear chanting and will react to positive chanting like “Go Bender” and “You Rock”, if he hears those frases he will raise his hands and if he hears negative frases like “you suck” or “Fry is better then you” he will be depressed and lower his arms. Bender is a persistent robot and will not consider turning off unless he runs out of alcohol, which means that he will turn off until he receives a message about low alcohol levels.

The outline of the program will look like this:

import "legs.thingml"
import "arms.thingml"
import "head.thingml"
import "ears.thingml"
import "power.thingml"
import "alcohol.thingml"
import "../../thingml.thingml"

thing Bender includes LegsMsgs, ArmsMsgs, HeadMsgs, EarsMsgs, PowerMsgs, AlcoholMsgs{

    property booted : UInt16 = 0

    required port Ears{
        receives positive
        receives negative
    }
    required port Arms{
        sends rise
        sends lower
    }
    required port Legs{
        sends run
        sends walk
        sends stop
    }
    required port Head{
        receives knock
        receives distance
    }
    required port Power{
        recieves powerOn
        recieves powerOff
    }
    required port Alcohol{
        receives low
    }
    statechart BenderImpl init PowerOff{

        state PowerOff{
            on entry do
                Legs!stop()
                booted  = 0
            end
        }
        state PowerOn{
            on entry do
                //Code that boots system goes here
                booted = 1
            end
        }
        state Running{
            on entry do
                Legs!run()
            end
        }
        state Walking{
            on entry do
                Legs!walk()
            end
        }
        state Stopped{
            on entry do
                Legs!stop()
            end
        }
        state RaiseArms{
            on entry do
                Arms!rise()
            end
        }
        state LowerArms{
            on entry do
                Arms!lower()
            end
        }
        state Talking{
            on entry do
                Arms!rise()
            end
        }
    }
}

It is assumed that all ports are connected to a actual working part of a Bender robot on the other side of the interface. At this point the ThingML program is written so that it is functional with the current way of writing transitions and the way that i want to propose transitions to be written. As you can see there are seven messages that bender can receive and interact on, this means that we have to write seven transition statements in the thing scope. This is a great improvement compared to how it is done in the current version where you have to write seven transition statements in almost every state. The states are written so that they will trigger an action when the state are entered, there is no way to do some clean up and stop the walking procedure while bender is supposed to rise his arms for example since bender is capable of multitasking. Firstly lets compare one of the current style transition to my suggestion. The transition from any state to running would look like this:

transition -> Running
event m : Head?distance
guard booted == 1 and m.distance > 5000

My suggestion looks like this:

transitions m : Head?distance {
    (booted == 1 and m.distance > 5000) -> Running
}

At this point we can start to see the advantage of my proposed way of writing transitions, because we will also need to define transitions on the events of the distance being less then 5000 cm and less then 10 cm in order to decide on the correct behavior. In the current implementation this would mean two more transitions, two more event listeners and two more guards, resulting in six more lines of code, in every state, which sums up to 21 lines of code. So the benefits are great in writing it as this:

transitions m : Head?distance {
    (booted == 1 and m.distance > 5000) -> Running
    (booted == 1 and m.distance < 5000 and m.distance > 10) -> Walking
    (booted == 1 and m.distance > 10) -> Stopped
}

Problems

This way of writing the transitions gives us some problems though, in this example one of the problems is solved by the booted == 1 check. This does so that we can never go directly from the TurnedOff state to an activity state. Instead of using control variables like this there should be a construct in the transition declaration where the programmer can exclude states that will not allow these transitions to take place. One solution to this might be to add a comma separated list behind the transition that the are not to happen from a specific state, like this:

(m.distance > 5000) -> Running, PowerOff

This symbolize that the transition that goes to the Running state is not available from the PowerOff state. More states can be added with commas between. In this example neither of the three transitions are to be accessible from the PowerOff state and in the spirit that surrounds this article writing things several times is a abomination. Therefore I suggest that it shall be possible to write a comma separated list of states that will not trigger these transitions behind the closing curly brace, like this:

transitions m : Head?distance {
    (m.distance > 5000) -> Running
    (m.distance < 5000 and m.distance > 10) -> Walking
    (m.distance < 10) -> Stopped
} PowerOff

Another problem that occurs with this way of writing transitions is how to handle transition to the same state as the program currently are in. In some programs it don’t matter if a transition goes from a state to itself and thereby running the on exit and the on entry clausula again, but in other programs it might be crucial that it does not loop in a specific state. This problem I want to solve by introducing a new keyword: notself. This is to be placed at the end of the transition declaration, after a eventually comma separated list of excluded states. Here is an example that show that if bender is in the Running state he can not loop into the Running state again, if he is walking he can not start to walk, but if he is stopped he can still stop one more time. No mater how illogical that seems. Remember that Bender is from Futurama and dosn’t need to be logical.

transitions m : Head?distance {
    (m.distance > 5000) -> Running, notself
    (m.distance < 5000 and m.distance > 10) -> Walking, notself
    (m.distance < 10) -> Stopped
} PowerOff

Lets move on to the third problem that needs to be solved. Unfortunately this problem does not fit into the Bender example, at least not right now, so I will explain it in a more generic way. Say that we have a state machine with four states S1 to S4 these have all one transition to each of the other three states and are triggered by the same messages, as we have seen in the previous examples. But lets say that S4 is a little different, instead of transiting to S2 on a specific condition as the rest of the states, S4 wants to transit to S3 instead on that specific condition. To solve this problem I propose that it should still be aloved to write transitions inside the states as it is currently done in ThingML. This will allow the compiler to first check the global transitions and thereafter check if there is a local transition inside the state, and if it is give that local transition precedence over the global transition. To show this in the Bender example lets add a rule, for example that Bender is not allowed to rise his arms while Running because this will be to dangerous to his surroundings. So as a safety measure we will instead go into the LowerArms state, since we actually dosn’t know if his arms are pointing upwards or downwards. The code will look like this:

transitions m : Ears?positive {
    -> RiseArms
} PowerOff
...
statechart BenderImpl init PowerOff{
...
    state Running{
        on entry do
            Legs!run()
       end

        transition -> LowerArms
        event Ears?positive
    }
...

Now it is time to make a quick comparison between the Bender program written in my proposed way to the way it should be written in the current version of ThingML. Here you can see my implementation:

import "legs.thingml"
import "arms.thingml"
import "head.thingml"
import "ears.thingml"
import "power.thingml"
import "alcohol.thingml"
import "../../thingml.thingml"

thing Bender includes LegsMsgs, ArmsMsgs, HeadMsgs, EarsMsgs, PowerMsgs, AlcoholMsgs{

    required port Ears{
        receives positive
        receives negative
    }
    required port Arms{
        sends rise
        sends lower
    }
    required port Legs{
        sends run
        sends walk
        sends stop
    }
    required port Head{
        receives knock
        receives distance
        sends chantMessage
    }
    required port Power{
        recieves powerOn
        recieves powerOff
    }
    required port Alcohol{
        receives low
    }

    transitions m : Head?distance {
        (m.distance > 5000) -> Running
        (m.distance < 5000 and m.distance > 10) -> Walking
        (m.distance < 10) -> Stopped
    } PowerOff

    transitions m : Ears?positive {
        -> RiseArms, PowerOff
    }
    transitions m : Ears?negative {
        -> LowerArms, PowerOff
    }
    transitions m : Head?knock {
        -> Talking, PowerOff
    }
    transitions m : Alcohol?low {
        -> PowerOff
    }

    statechart BenderImpl init PowerOff{

        state PowerOff{
            on entry do
                Legs!stop()
                Arms!lower()
                //Code to shut down goes here
            end
        }
        state PowerOn{
            on entry do
                //Code that boots system goes here
            end
        }
        state Running{
            on entry do
                Legs!run()
            end
            transition -> LowerArms
            event Ears?positive
        }
        state Walking{
            on entry do
                Legs!walk()
            end
        }
        state Stopped{
            on entry do
                Legs!stop()
            end
        }
        state RaiseArms{
            on entry do
                Arms!rise()
            end
        }
        state LowerArms{
            on entry do
                Arms!lower()
            end
        }
        state Talking{
            on entry do
                Head!chantMessage()
            end
        }
    }
}

Here I managed to implement Bender in a smashing 103 lines long program, we do of course look away from the interfaces and actual implementation of the electronics that goes into Bender since it is not important to the scope of this article. By doing it the traditional ThingML I got astonishing 254 lines of code, that is more then twice the amount of code.  The file is available here :Download.  Now imagine that you have discovered that one of your transactions are subject to change, that means that you have to traverse through the code and find everywhere that the transition is written and change it accordingly. This is time consuming work that can be avoided by implementing my proposed way of defining transitions in ThingML. Another argument for implementing my proposed changes into the language is that Internet of Thing (IoT) is something that is becoming more and more common and we need better languages to program our things. I feel that ThingML is a step in the right direction of bringing stuff online and I feel that we will see a lot more autonomous things in the future.  These things, who often are robots, are relying on getting sensory data in order to navigate and interact with their surroundings. Therefore it is often important for them to be able to react to every kind of input no matter what state they are currently in. My proposed changes makes this easier to accomplish and I believe that this will allow us to create better robots which can operate more smoothly in every kind of environment. I hope you can see the benefits from it as well and will give ThingML a try.

If you have any thought on this topic or any other things that might be relevant, donæt by shy to drop a line.

During my lazy Saturday an Idea came to mind and I ran all the three meters to my electronic stash, lifted it down and found everything that I needed to make my Vimbot rather cool. It wasn’t much stuff I needed, only two 3mm red LEDS,  one 3mm blue LED, three 330ohm resistors, one 9v battery plug and one 9v battery. The tools I needed was a knife, a soldering iron, glue, a 3mm drill bit and a 5mm drill bit.

I don’t have any work in process pictures since this is a easy to do modification and I think that if anyone who sees this and wan’t to replicate it in some way is able to do it without me holding their hands.

On the front I have drilled two 3mm holes for the red LEDs to go in, they have to be put in from the back side because of the rim on the bottom og the LED.

In the back I have drilled two 5mm holes and pushed the two red LEDs into the eye holes. I also cut away some material on the bottom and put the blue LED inside pointing upwards, then glued it in place. Then I soldered the resistors in place, one on each positive LED pin. and then soldered the leads from the three resistors to each other. Then I soldered the battery plug to both the positive and the negative leads.

This is how it looks plugged in standing on top of a speaker on my shelf.

If you wan’t to buy your own Vimbot or other kind of cool vinyl figure, Kyrre is selling all his figures here: http://www.finn.no/finn/torget/tilsalgs/annonse?finnkode=32544523