During the last two days, we have faced a lot of problems with the sensors of the track. We had two types of interrupts that were causing us problems:-
1. Debouncing Interrupts
2. Fake Interrupts
Problem: We have configured STM32 GPIO ports to Internal Pull-Up. All our sensors cards are powered by the Central Station Card through the CAN bus. We observed that there is some kind of parasitic signal that comes from the booster towards our Central Station which produces a glitch in the power towards the Nodes (Sensors card in this case). Due to this glitch in power, the GPIO ports which were pulled high become low and thus Fake Interrupts are produced. Thanks to Alexis who stayed till 5 in the morning to help us debug the problem.
The first one was solved by making sure that the any interrupts (that is not fake) from the sensors is processed only if there is atleast a gap of 100ms since the last time it was called. For the second one, which is more tricky, we use a simple method (a FreeRTOS task) which checks for glitches. This method was proposed by Samuel and we thank him for assisting with our software.
Right now, we are trying to do all the mapping of Reed Sensors and Lights to the XML Layout of the track. This is required as the central station needs to talk to server giving him with sensor input.
Since Saturday I have been working on Firmware transmission through IrDA and the use of SD Card.
Transmission protocol for firmware:
The firmware is stored on flash memory, so we are transmitting from flash to flash through IrDA.
As we have to write in flash by pages, we also have to transmit our firmware by pages and as pages important in size we cannot send it at once. Thus each firmware will be sent divided by pages which are divided into packets.
At the beginning of a transaction a first packet is sent with the data needed in order to store the firmware such as number of pages, number of packets sent by pages and for security purpose the id of the sender and the interface used. The bloc send an acceptance packet either it is already on transaction or not.
Then a PAGE_BEGIN packet is sent with its position in the firmware.
During page sending all data is stored in a buffer of 32-bits words.
At the end of a page a packet END_OF_PAGE is sent confirming its position and adding its CRC calculated thanks to CRC unit on STM32 and the CRC is checked(Note that in the IrDA task we already check the integrity of each packet). If everything is okay we write the buffer in flash, if not a request is sent to resend the page.
We continue till we arrive at the end of firmware with the packet END_TRANSACTION and the global integrity is checked. In case of success we send a TRANSACTION_OK packet, if not we have to do it again from the beginning.
For SD Card we will use FatFS, a free open source FAT file system module which has an implementation on STM32 thanks to Martin THOMAS. I adapt it to our system. I delayed testing because transmitting a huge amount of data seemed more important, SD card coming in second.
Today, we tried to set the coefficients of our PID algorithm. In order to do this, we used the Ziegler-Nichols method. The first step is to set the integral and the derivative gains to zero. Then, we increase the value of the proportional gain, to obtain the control loop oscillating constantly. Unfortunatly, we didn’t succeed in obtaining the special value of P (proportional gain). It seemed we had still some bugs on the Kalman filter. Samuel and Axel tested again the good working of the Kalman filter (we had to change some coefficients of the Kalman since we put the card on the Copter), and fixed it.
Samuel made a basic program, in order to change easily the PID coefficients, while the Copter is running : we can now observe the effects of the changes in live.
We worked also on some improvements of the code: for the STM32 and for the Kanade algorithm, to prepare the future work & debug. For example, the UART was configured at 1 000 000 bps, so the STM32 had only 72 instructions to perform between each UART interrupt. Since we only send 150 packets/s (~20 bytes), 57600 bps speed would be fine, and more convenient.
Our journey has continued from CAN to LAN passing through DCC in its way. During the last two days, we tried to write the dcc encoder for our card which will act as the central station. In brief, I will try to explain DCC for all those who are not already aware of it. DCC (Digital Command Control) is a standard which permits us to operate model railways by sending modulated pulse wave(amplified with the help of a booster) to the rail tracks. Thereby, we can control any locomotive or accessory (like Traffic lights) if they have the dcc decoder. DCC is standard provided by NMRA.
We have done the following encodings for bit 0 and 1 as per NMRA DCC Standard.
(i) bit ’0′ – 232 microseconds (half high and half low)
(ii) bit ’1′ – 116 microseconds (half cycle is low)
On the implementation part, to generate such type of signal on the STM32 GPIO port, we use PWM module(using Internal Timer of STM32) with 50% duty cycle. This was setup in Output Compare Mode. Through the help of oscilloscope, we verified that we got the expected results. We created a dcc packet simulator(coded as a task of FreeRTOS) and we tried sending Messages to the port as per DCC Communication Packet format.
On the Ethernet part, we have chosen LwIP Stack as the TCP/IP Stack. We have chosen LwIP primarily as it has features like DHCP, UDP, IPv6 which we may need as the project matures further. So, we integrated the LwIP stack with STM32F107(which has in-built MAC Controller) and DP83848P Phy Controller taking help of a similar example provided by ST on their website. We were able to make a telnet connection to our Central Station and correponding exchange messages through telnet.
On the stabilisation of NMRA CAN protocol, we added a watchdog module within all the nodes including the central station. This was required because if the software hangs in one of the nodes, it should have the ability to re-join the network. The timeout of the watchdog module has been kept to 3 seconds(Typically because we want our nodes to rejoin the network as soon as possible and at the same time give Central Station enough time to remove this node from the node table and event table). Also, the command to reset the nodes sent by the network manager at the start of his execution as a broadcast message to all the nodes will have a deeper impact. Instead of doing a cache reset at the nodes, we are now doing an actual software reset to the node. This is just to simulate an actual reset. All these changes done to stabilisation are open for discussions and all remarks/critics/ideas are heartily welcomed.
Today, I finalized the emission of the commands for the motors, from the Gumstix to the STM32 and their reception (check the validity of the packet and if it’s valid, update the commands sent to the motors).
Then, with Samuel, we added 0MQ exchanges on the Gumstix between Kalman and the PID and between the PID and the UART.
On the Gumstix, the program that handles the UART has two threads. One receives data from the sensors from the STM32 and sends it -thanks to 0MQ- to the program computing Kalman. The other one, receives the commands of the motors from the PID and sends them to the STM32.
We also attached the PCBs on the copter:
We configured Kalman with the new axes and the offset of roll and pitch angles.
Finally, we all tested the PID. The algorithm seems okay, however, we’ll have to set each coefficient properly.
We’re trying to control roll and pitch angles with a low thrust (in order to prevent any accident). Then, we’ll add a control on Z thanks to the Sharp sensor.
We’ve been working these last few days on the PCB, to display pictures and to save and load them from flash.
First, we developped a set of functions to erase, write and read the flash memory, using a SPI protocol. After testing it with text strings we displayed on the screen, we tried with pictures. However, the STM32 RAM is not big enough to handle a whole picture : we have at most 20kbytes RAM, and one picture takes 25kbytes (132*132 pixels of 12 bits, 4 for each RGB channel). So we read the flash per 256 bytes blocks that we send to the LCD screen, until transfer completion. Similarly, we write flash per 256 bytes blocks when receiving a picture from the UART connection.
In order to have a simple protocol for writing pictures, we do not allow two pictures to share a same memory sector (smallest erasable area). Since each sector is 4 kbytes wide, we use 7 sectors for each picture : that’s about 3 kbytes too large. However, this allows to store 146 pictures in the flash, which should be enough for our project. We did not work yet on the possibility of storing smaller pictures which could be used to refresh a small screen area. It may be useful for animations.
Finally, we use the screen configuration options to rotate pictures by 90, 180 or 270 degrees, changing the way the screen controller reads the RAM.
Moreover, we wrote a small program which uses OpenCV library (which is already used on the beagleboard for face detection and recognition) and converts a picture (jpeg, png, bmp,…) in a 132*132 12 bits picture and saves it in a file that can be sent to the PCB by UART.
Yesterday we finally observed the first moves of our octocopter. After spending all the day working on the communication with the motors, Samuel and Axel have succeeded in controlling the motors from the STM32, with the help of Jon, passing by. They speak to them in I2C, and they can control the speed of the propellers. The Copter tried to run away, but he was fortunately attached on a table. However, we have to be more careful in the way we will attach it in the future, because it was close to a disaster.
On my side, I tried the RF controller, a Spektrum DX7 transmitter/receiver. I tested it on the STM32 board that we have previously use for the communication challenge, it works as we can expect, thanks to the code of the Heliokter team. We use indeed the code from last year’s project, which seems to fit to our needs. The RF receiver gives us access to different integers, which indicate us the pitch, the roll, the yaw and the thrust, and also some commands. The way the receiver communicates with the PCB is simple : it use the RS232 protocol, with a speed of 115200 kbps. It sends packets of 16 bytes separated by long period with idle line. I have implemented the code for our PCB and for getting the commands on the Gumstix, but I still need to test it.
On his side, Bertrand principally tried to debug some aspect of the STM32 code. When we send data in the both directions and look for the values of the sensors at the same time, some freezes occur. We think it’s maybe because the code needs some optimization, so Bertrand is working on it.
As Samuel noticed that there is not formal description of the algorithm, I will do this now.
First of all, all the messages use the packet structure giving by Cédric here. So, they all have an ID and we know who is the sender. I will start by showing all the messages and then I’ll explain the algorithm.
List of the differents messages
There are a large number of messages and they all have specifics arguments.
For the algorithm, I use « interfaces » which are aliases of UARTs. The UARTs are used by the IrDA while the interfaces are used for the algorithm. For example, interface 0 represents the north (and is in reality UART 2), interface 1 is the east (but in reality it’s UART 5), etc.
All the blocks know :
their own ID (given by the STM32_ID),
their leader ID,
their orientation (which « interface » represents the north)
the number of member in their network
their « nearest » neighbors (who is in front of my UART2,3,4 and 5) : the Interface table.
They have a network table (for each ID, they know the position (i,j) and who was the leader when they had the information) and an election table (for each ID, they know his state in the election) . We will try to replace theses tables by a list in the future.
Every message except PING and PONG is answered by an ACK message. The PONG message contains the PING ID so it is itself a ACK. If there is no ACK, the message is resend.
When starting all of this, the block starts the timer 5 of the STM32 for the synchronization. (see section 4)
Each block sends PING messages in the 4 directions and start a timer for each direction.
When receiving a PING message, a block sends back a PONG message as fast as he can.
When it receives a PONG message, the block knows who is his neighbor and changes his Interface table. Furthermore, the block stops the timer.
If the block is aware that there was a neighbor but there is no answer at the end of the timer, it sends a RESET_NETWORK message (see section 5).
If this interface wasn’t ready before, the block has to check if he knew the neighbor (in order to notice a turn of the other block) or not (in order to start an election.)
Explanation of this check :
When receiving a PONG message from a « new neighbor », the block checks if the « new neighbor » was a neighbor before or not. This is checked by comparing the current interface table and the saved interface table.
If the interfaces tables don’t match, there is an election.
Else, the block sends to the block TURN (myID, rotation). The rotation is the difference of index between the current interfaces and the saved interfaces.
To compare the interfaces, the block waits a little bit for PONG message from all the interfaces.
3. The election
When it’s the first PONG from a new neighbor, an election takes place.
When starting an election, the block starts a timer. If his candidature isn’t refused at the end of the timer, he is elected and he broadcasts the information.
In the election, the blocks send messages for their « network » (all the blocks with the same leader). Here, the « network » can be a network of one block (so the leader ID is his ID).
The block sends a START message to his neighbors not in his « network » (and this is broadcast). All blocks sends a CANDIDATE message with his leaderID and the numbers of members in his network.
The winner of the election is the network with the larger number of blocks in his network. If this isn’t enough to decide , the lower leader ID is declared winner.
When receiving a CANDIDATE message, the block checks if the candidate can win or not. If he can’t, the block broadcasts a REJECTED message. If he cans, the block broadcasts the CANDIDATE message.
When receiving a REJECTED message with his leader ID, the block stops the timer : he can no longer win the election.
At the end of the timer, one network is the winner. It sends the ELECTED message and everyone broadcasts it.
4. After the election
After the election,the leader is in (0,0). If he was part of a network, he sends his information to the others by sending NETWORK messages.
For every NETWORK message received, the block analyzes it : if the leaderID of the NETWORK message isn’t his leaderID, it drops the message. Else, if the message contains a good information, the block changes his network table and transmits it.
Then he sends the POSITION message : [YOUR_POSITION leaderID, myOrientation, yourI, yourJ, myInterface]. The block which receive this calculate his new orientation (with « myOrientation », « myInterface ») and change his position in his network table. Then it calculate the position of his neighbors and sends the message.
The leader sends TIME messages (which are broadcasted if they are « young » enough.. That explains the synchroID) from times to times. In his TIME message, there is his current time (according to the STM32). The block that receive this message update his new « current time » (with a function which take into account the emission time) and then sends his current time to others, etc.
5. If someone leaves
If some block leaves the network, there is no PONG message to the PING message of his former neighbor. The former neighbor notices that and broadcasts a RESET_NETWORK message.
This message is broadcast to all the network and means that every data (leaderID, network table, …) must be restarted; the interface table is saved (for the TURN mechanism). A new election starts soon after. (plus the orientation, network information, synchro…).
The turn mechanism isn’t implemented yet and the ACK mechanism has to be implemented very soon.
Then, there will be messages for the applications (games, firmware upgrade, …).
Yesterday, after several days of debugging, we finally managed to gather data from the gyroscope. We ultimately found out that the freezes we were experiencing were caused by a reset interrupting an I2C cycle in the exact moment a slave was about to write a ’0′ on the SDA line (as an acknowledgement or during a read cycle); when the STM32 woke up and tried to generate a START condition, the slave would immediately force SDA to a low state, thus preventing the microcontroller from reclaiming the bus. We fixed this problem by sending several clock pulses on the SCL line until the IMU-3000 releases SDA; then, we can force a STOP condition and abort the incomplete cycle.
We have also completed a first version of our communication protocol. Under normal operating conditions, the following messages are exchanged on the bus:
Angle from accelerometer, angular velocity from gyroscope
Speed of RoseWheel
Danger (detected by distance sensor)
Command sent to the motor
Remote control (from Bluetooth/UART)
In debug mode, the sensor board sniffs the bus so that it can send it by Bluetooth or serial port. The HI board monitors the exchanges as well to display relevant information on the LCD:
Angle from accelerometer, angular velocity from gyroscope
Voici dans ce post un bilan de la démonstration de Vendredi, ainsi qu’un bref état des lieux des avancées d’aujourd’hui concernant la programmation série en C sous linux.
Démonstration de vendredi
Nous avons Vendredi fait état de nos dernières avancées.
Nous avons débuté la démonstration par la présentation du PCB que nous avions réalisé et qu’Alexis nous avait remis il y a peu. Alain a, comme il l’a montré dans un post précédent, réussi à piloter l’écran LCD et afficher une animation simple comportant des rectangles de couleur et du texte.
Reste maintenant à réaliser l’interface série entre la carte et un ordinateur, puis programmer la mémoire flash embarquée.
Nous avons poursuivi par la démonstration de Thomas qui a piloté par l’intermédiaire de la carte de TP STM32 l’un des servomoteurs que nous allons utiliser. Grâce à son programme, nous sommes capables de piloter ces moteurs en leur fournissant une consigne angulaire.
Reste désormais à piloter le prototype en installant trois servomoteurs dans sa base.
Nous avons ensuite effectué une démonstration logicielle qui rassemblait les « helloworlds » que nous avions réalisés avec les différentes bibliothèques. Nous avons ainsi pu piloter à la voix l’ordinateur, lui demander de faire l’apprentissage de deux visages, puis de passer en mode reconnaissance. Une fois en mode reconnaissance, le moteur de synthèse vocale interfacé pour le moment avec pulseaudio a salué les visages connus en les nommant par leurs prénoms.
Comme Thomas l’a signalé dans son billet, nous avons pour le moment mis de côté le développement de drivers, pour nous concentrer essentiellement sur la mécanique, la programmation du PCB, et le port de nos applications sur la beagleboard.
Afin de préciser notre démarche, nous publierons bientôt sur ce site une liste actualisée de nos PSCC et des responsables associés.
Avancées de la journée : API RS232
De mon côté, je me suis penché sur la programmation du port série en C sous linux. J’ai trouvé à ce sujet une excellente source de documentation, qui m’a permis de comprendre rapidement l’interface posix permettant d’en effectuer la configuration. Vous retrouverez ce guide ici.
J’ai créé une interface de plus haut niveau permettant de lire et d’écrire sur un nombre indéfini de ports série, et de rentre transparente la gestion des lectures et écritures avec tampon.
Il suffit en effet pour utiliser un port série d’en demander l’ouverture en précisant le fichier /dev/tty* associé, et de donner en argument la fonction que l’on souhaite être appelée pour traiter les données.
L’API se charge ensuite d’appeler cette fonction lorsque de nouvelles données sont disponibles, ainsi que d’écrire les données stockées dans des tampons chainés lorsque le matériel est prêt.
L’utilisateur peut donc utiliser des fonctions non bloquantes pour écrire, et utiliser ses propres fonctions pour lire.
Pour finir, bien que cela ne soit pas encore implémenté, il est possible d’ajouter à cette API les sockets en plus des ports série. Cela permettrait de gérer par le biais d’une interface unique toutes les transmissions de la beagleboard, que ce soit par réseau ou avec le PCB.