- 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.
- 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.
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.
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.
- 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!