The Albert Einstein time travel machine
This year's theme for the annual village feast is "tijdmachine" (time machine). Thinking about the theme, mr Einstein popped up, one of the most important scientist ever lived. He believed that it is possible to travel in time. So the control for this year will have something to do with mr Einstein; let's say a time travel machine. Not as big to hold a whole person, but big enough to let insects, little creatures like a mouse travel in time. Let say the size of a human head.
The story
Visualize the following picture; all nowadays new build machines have a certificate of conformation (CE). This time travel machine is a prototype, build before CE marking existed and a RI&E is never performed... so; this machine is not "save". Ok, we have placed a warning sticker on the machine.... but there is always someone sticking his nose into things.... he could better not do that; while his head is in the machine, there is a big flash and only his head travelled along with the machine to the accidental chosen year and place of  "28.08.2019.WYTGAARD"
So, just a head with some frills and frippery around the neck is there -in the time travel machine- doing funny things...(?!).
The technical design 
The technic i had in mind and partially ready-made and working; hardware consist of an arduino mega2560, a Raspberry PI and a handful of servos, colour leds, and relays. For the control of the head; turning up and down, looking left and right i will use a raspberry PI3b with object detection. Therefore a camery is used to look at the surroundings in front of the travel machine. With the object detection "person is on camera", it is possible to determine the place and head of the person nearest to the machine. With this information it is possible to move the head and do something with the eyes and mouth... maybe it is also a funny detail to let some fluid (sweat) dripping somewhere from the hair line over the face.... ah, ideas enough... 
State of the project week 8 (24 weeks remaning...)
  • RPI3b. Object detection on the RPI3b, is working now with a webcam. The software is now capable of reading 1.4 FPS and is not quick enough for a "smooth" control of the head. I ordered a RPI3 camera and i'am examining some methods to increase the number of FPS. 
  • RPI3b/MEGA. Messages coming from the RPI3b to the MEGA board for the control of the head; the concept is operational.
  • MEGA. Servo control for left/right movement is being designed and partially made
  • MEGA. Servo control for pan/tilt not yet made
  • MEGA. Light effects not yet made
  • MEGA. Sweating effect not yet made
  • MEGA. Sound effects not yet designed and made.
  • Mechanic. Hardware for the head (the head/mask) not yet made
  • Mechanic. Hardware for the time machine not yet made
  • Commissioning. Testing the whole control planned for week 31.

 Next update week 10.


Arduino MEGA2560 vs Arduino DUE
The DUE is the second Arduino type that i've updated for loading the AFSM. As documented some of the differences between the 2560 and the DUE, is the fact that the DUE is a 3.3Vdc board insted of 5Vdc and the DUE is much faster and has much more memory.
Summary Microcontroller ATmega2560
  • Operating Voltage 5V
  • Digital I/O Pins 54 (of which 14 provide PWM output)
  • Analog Input Pins 16
  • Current for 3.3V Pin 50 mA
  • Flash Memory 256 KB of which 8 KB used by bootloader
  • SRAM 8 KB
  • Clock Speed 16 MHz

Summary Microcontroller Atmel SAM3X8E ARM Cortex-M3 CPU (risc processor)

  • 54 digital input/output pins (of which 12 can be used as PWM outputs)
  • 12 analog input
  • 84 MHz clock
  • USB OTG capable connection
  • 2 DAC (digital to analog)
  • 2 TWI
  • 3.3V and compliant with the 1.0 Arduino pinout.
  • 96 KBytes of SRAM.
  • 512 KBytes of Flash memory for code.
  • A DMA controller that can relieve the CPU from doing memory intensive tasks.
When making a serious control -i think- the differences of 3,3Vdc and 5Vdc will surface clearly.
But what are the software changes for making this board work with the AFSM?
At the first build of the board i got:
  • Failure resetting the board from HMI
  • Failure on FreeMemory function
  • The calculation for the size of the FSM state constructor is wrong


Adjustment made for the DUE (blue is new, green is old)

Added new libraries:

#include <malloc.h>
#include <stdio.h>
#include <stdlib.h>


void ResetBoard()
} // End of ResetBoard


void RAM()
  char top;
  int FreeMem;
  HMISendString("@VAL," + ValidationId);
  FreeMem = &top - reinterpret_cast<char*>(sbrk(0));
  HMISendString("@RAM," + String(FreeMem));
} // End of RAM


void InitFSMStates ()
  int StateNo = 0;
  FSMStateType* FSMStateLaatste;
  Serial.println ( F("Setup FSM States"));
  NoFSMStates = sizeof(PossibleFSMStates) / 12;
while (StateNo < NoFSMStates)

There is a great difference between the speed of similair controls. First test gave a serious reduction of the cycle time; for the DUE 0,18 mS and the similair MEGA2560 control has a cycle time of 0,87 mS. Notice also the difference in free memory.









Timer stopwatch 347x300
Timers, timers and timers...
Things can be made more reliable, simpler. Side effects are there to be minimized.
I got an email with some questions about the timers. In the previous version of the standard, there was a side effect with the timer structure. The main problem was that all actions performed on the timer queue are processed when the timer functions are called within the states of the machine. In the new version this is changed, together with some improvements. The main changes:
  • After a timer expires and the function Timer is called, it will be true for one cycle (one-shot). The difference with the previous version, is the removal of the timer entry from the timer list. This is now done at the end of the cycle and not by the function Timer.
  • There is a new function called DelayTimer. DelayTimer will result in false when not expired and true when it is. The timer entry remains in the system as long as it is not excplicited removed from the timer queue with the CancelTimer function.
  • There is a new function called RestartDelayTimer. When called, the timer entry is initialzed. 
  • The CancelTimer function is unchanged.

See the pages, describing the functions; menu/standard functions. 


LAdownload Download page


Announcement of AFSM 2.0, the new version of 2018
When using the classic version, the definition of the I/O was not flexibel. The number of pins for a certain I/O type and the pin number to start with, had to be given in the UserConfiguration.h file. All pins of a given I/O type had to be succesive pins. In the new version of the Visual studio 2017 solution, an extra project is added called the Configurator. With use of the Configurator, new Tags can be configurated for the sketch and pins can be draged and dropped onto it. It is possible to read the old configuration and to write the updated configuration. The UserConfiguration.h file is generated by the Configurator. The pins are dragged from the available pins of the MEGA2560 and can only be dropped on the right I/O types. See the introduction videos below. After the definition of tags/pins, rebuild and upload the sketch to the board. Control modules are now available for the given tags and already available in the HMI application. When you start the HMI application you can already perform an I/O-test. All functionality, like dynamic update, masking, forcing, trending are available.
This video presents the new Configurator for AFSM 2.0. 

help 1280 
Failure serial communication between a Raspberry Pi3b and MEGA2560 boards; workaround
What the f*!! When trying another raspberry pi3b, together with a Mega board, suddently* the communication between the board and the raspberry stopt working. The connection is made up by an apc220, TTL to USB converter. I tried several different MEGA boards with the same result. Another raspberry is working correct, and is not showing this behaviour (working correct). The software on the Pi's is exactly the same. So, it must be something in the hardware... 
So when this problem occured, i build additional logging in the python script. Conclusion: after some time, the normal received ascii characters by the raspberry are replaced by corrupted bit strings like 'b/x00/x00 types. The python script is not accepting these information and the HMI screen is stalled. Information is still received but cannot be processed by the raspberry to fill the beautiful HMI screen.
The procedure for receiving and processign the data on the raspberry:
  • a special thread is receiving data from the USB port as long as there is data available. The thread is looking for special terminator characters and then strings (MEGA2560 messages) are put into a queue, to be processed by the main thread for the HMI screen.
  • the main thread is looking at the queue and is processing the queue messages when there are message available. After reading from the queue, the HMI screen is updated or whatever action is required
  • I analyzed from the logging after the moment the communication seems to be currupted, that i got an error reading the message queue; the qsize seems to be greater than 0, while reading from the queue results in an error; queue.empty is true!

I know, it's a work around... but after the error, reading the queue, the serial communication channel is now closed and opened again; everything is working again, but some messages must be lost between closing and opening the connection.... The new software release is available in the first week of october 2018 on the download page.


"Suddently" is not so random, it seems to be a fixed time of 90 seconds (the same time at different baudrates of 9600 and 115200)... if someone has the answer to this communication problem, help!