Below the current statistics of the downloads. By far the ZIP file for the libraries is most downloaded.
Just for information.
AFSM 2.6 Available.
The new software for the AFSM is now availble! The main changes are in the new Configurator. The software is also available under the Software part of the website. Find the description of the Configurator under Menu/Declaration part or click here.
- 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
- EEPROM 4 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.
But what are the software changes for making this board work with the AFSM?
- 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:
RSTC->RSTC_CR = RSTC_CR_KEY(0xA5) | RSTC_CR_PERRST | RSTC_CR_PROCRST;
} // End of ResetBoard
HMISendString("@VAL," + ValidationId);
FreeMem = &top - reinterpret_cast<char*>(sbrk(0));
HMISendString("@RAM," + String(FreeMem));
} // End of RAM
void InitFSMStates ()
int StateNo = 0;
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.
- Received the Pi camera last week. FPS with this camera is higher then the USB cam. FPS is now around the 1.6. The Python program is slightly changed (made more readable). Development is going slow at the moment because of some new priorities.
- The RPI3b python program was not stable. "Segmentation failure", "Invalid instruction", hanging... I could not find any lead on the internet. It had to be the hardware of the RPI3b. So, i've changed the Raspberry hardware. The new Raspberry is stable, was working over night. I've only changed the hardware, i'm still using the same software/SD card. Now i'am still searching for increasing the FPS. Attention for overheating the raspberry; without forced ventilation the cpu easily reaches 80 degrees while running Python3/Tensorflow object detection. With a ventilator the temperature sticks at 50 degrees.
- The moving of the head (left to right), is now going smooth. When no objects arround for 20 sec (no person in front of the camera), the head is going to the neutral position and the head is resting on the "chest". Thanks to the multitask FSM the actions for going to the neutral position and bending the head to the chest, are seprate sequences and running in parallel; sometimes the neutral postion is earlier reached as the bending of the head or visaversa (nice...). Also when starting the actions, the head is simultaneous turning and looking up.
- First pan and tilt actions implemented (servo no. 2 is active)
- RPI3b. Object detection on the RPI3b
Working now with a webcam. The software is now capable of reading 1.3 FPS and that 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. After the detection of a person on screen, python sends the middle of the detected box to the Mega board. Later on, an estimate for the persons head in front of the camera will be implemented. The smaller the box, the higher the estimate for the person head. The Mega calculates the right angle for moving the head and controls the Left/Rigth servo.
- MEGA. Pan and Tilt actions
- 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.
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.