We have yesterday worked on the control of our circuit from a remote server, and we finally could remotely control all lights on the circuit. We could also run our train in both directions, corresponding to the remote program commands.
As we send information about the car position (sensor information), the remote program controls our circuit continuously.
After that, we were facing the problem that the railroad switches weren’t decoding our DCC commands. So we have reprogrammed them. After that some of the railroad switches. Unless the railroad switches aren’t included in our work specification, we try to control them all in order to make a free circulation of our train. Vaibhav and Theodor are concentrating on this part while I am doing the presentation for tomorrow.
Today we have faced numerous problems. The ethernet module causes a crash in our central station and we still haven’t figured out the solution. We also tried to connect all card’s (6 captor-6 traffic lights cards) to our main station and they failed to join our the network. As Alexis consulted us to do, we lowered the baud rate of the CAN bus so that problem is solved. All cards join the network and CAN baud rate now is configured at 125kbp/s.
Regarding the communication of the server with the train we were able to track the position of the train and send it to the server. Our goal now is to remotely control lights and train, and we are working on it.
Today, we went to the complex, a more spacious room than the one where we used to do our tests. The tests were quite conclusive. We were able to do some « landing » (the copter was caught by Axel near the floor because of turbulences caused by the proximity of this obstacle). With more power to the motors, we made the copter stay longer in the air, about 10/20 seconds (sadly, it wasn’t filmed).
We also used the remote to control the trust and the setpoint of the PID. It will need some software adjustments since it is still to brutal and rather hard to use.
Tomorrow, we’ll restore height control in our PID and see how much the copter drifts. This drift shall be corrected with the remote.
Today, we continued on our recent work : I worked on the algorithm and on the rotation of a block. The rotation works quite well now. The algorithm for this rotation is simple : When a communication between two blocks is stopped (due to the left of someone), the two blocks save their « interfaces » (aliases of the UARTs ). When there is a PING from a block, we check the saved interfaces in order to see if the block was a « friend » of this block. If it’s the case, we just calculate the rotation of the block.
The main problem is that a block can communicate with 4 others blocks at the same time. So, sometimes, we have to wait a little bit when we want to compare the interfaces.
Cédric noticed in the afternoon a bug in the IrDA functions and we fixed this. Now, the IrDA has more reliable and there are few problems in the network.
I still have problems when two networks meet with more than one block each involved in the « deal » but things are going better each day.
Benjamin worked on the launcher task. He thought of a remote block who can control the animation/game that will be played soon after.
Cédric continued the firmware transmission and the protocol is actually functional at good speed. But he is now facing problems with flash writing.
Here is a little video of the synchronization (running on the GLiPs but the MBLed are arriving soon):
Every block knows its i,j and minI, minJ, maxI, maxJ in the network. The block in the north-west shows a M; north-east a B; south-west LE: south-east D. If he is alone, he shows a M too.
That’s why sometimes in the video, there are 2 M : one of the block has encountered problems and reset himself.
For the synchronization, the leader gives the time every 20 PING (approximately every second), when a block receive that, it transmits it to his neighbor and so on.
Today, we added the yaw servomechanism on the Copterix and it responded pretty well, it is now able to fall slowly like a fall leaf. Sorry we don’t have any video this time, but you will soon understand why…
Our octocopter went through a lot of trouble:
When we passed on battery, motors were twice as powerful as on sector, and even though we lowed them a lot, it finally crashed on the ceiling. That was of course not a real test environment (indoor flights are not the exact purpose of a copter), and that is exactly the reason why this accident occurred. It turned out that we just had to change a propeller and our copter was back on tracks.
Since yesterday evening, Copterix tends not to start properly. We thought first it was because of the motors card security, which turns off every motors in case of a brutal startup, but it was late tonight we finally discovered with our teacher that it was just a bad contact between a part of this card and the rest of it on the i2c bus, and we finally fixed it.
Afterwards, we performed a Radio Frequency test and it went really well: we think we will be able to control the thrust, roll and pitch by remote control after a few callibration.
Finally, we started our web site ! We plan to add a lot of content about our project during next week, keep on checking !
Tuesday evening, after nearly two days of fine-tuning our testing procedures and security measures, we finally did the first tests on our own vehicle. In order to make sure we didn’t damage the equipment (nor hurt somebody), we followed a simple and strict protocol:
1. First of all, we checked that we could control manually the motors via our interpreter;
2. Then, we verified that the limitations we applied to the variation of the voltage of each motor were adequate (as mentioned in a previous post, an abrupt increase or decrease on the voltage could severely damage the motors);
3. Finally, we determined a maximum speed that seemed reasonable, so that we could stop the vehicle manually should the worst happen.
After this initial procedure, we could start the actual tests of our system. After some iterations of tuning the coefficients of our controller, we realized that it was actually much easier to equilibrate the vehicle with a human being on top of it than without any load, since:
(i) the person enhances the performance of the control system by balancing his/her weight in a way that maximizes stability;
(ii) the presence of the human being makes the test conditions closer to the physical model we used to compute and simulate the parameters.
After several adjustments, we were able to take our first ride on the RoseWheel -- with basic steering capabilities via the integrated potentiometer implemented as a plus.
Nevertheless, by wednesday morning we had not yet found a way of balancing the RoseWheel alone -- a must for our next major goal, remote control. Then, we realized that the chassis we used had a very interesting property: by tilting it to a specific angle, we could align the center of gravity of the steering bar with the axis of the wheels, reaching a metastable equilibrium. We used this fact to offset the error variable of our PID controller, and that proved to be very effective, since we obtained as a result a pretty good stability. But all this comes at a price: since we now have two different equilibrium positions, we must use the safety button located on the chassis to determine if we are carrying a person or not; nothing too difficult to implement, though.
On the other hand, the PID coefficients may be trickier to master. We are still working on them to solve the issues we are having, notably oscillations and vibrations that sometimes occur. To help us with the debugging, we set up a solution to plot angle, angular velocity, and output voltage command for each one of the motors. Our next actions on this front will be to use all these data to better tune Kp, Ki and Kd, so as to have a more responsive and stable control algorithm.
Meanwhile, we started to move on to our next goals: we began to study the Bluetooth controller, and are already able to compile and run a « hello world » Android application. Next steps include implementing drivers for our distance sensors to implement obstacle detection.
To summarize all our work, we prepared a special video showing some of the most interesting (and/or funny) demos we made so far. Enjoy!
Today Alexis delivered us the whole set of the train light circuit. Initially we tried to add another light card to our current testing configuration. We managed to get 2 light cards configured , so up to this point the central station has been able to control 2 light cards, the train and an ethernet connection in total.
Currently we are working on stabilizing the NMRAnet CAN bus protocol. We encountered problems of what we think mainly concern, a difference between the CAN bus bandwidth and the processing bandwidth of the central station. For example, as we observed, during programming the events of a node, within an environment of multiple CAN packets exhange, the central station missed acknowledgement frames sent by the node after the configuration file. This prevented the central station from successfully programming a node. After inserting a delay between sending the data of the configuration file and the ACK we observed that the node got successfully programmed. This led us to assume a mismatch in processing and CAN bus bandwidth.
In order to face these kind of problems which have appeared, we will adjust the CAN bus bandwidth, use one buffer for event processing and another one for network-management purposes, and additionally install event filters on the fly accordingly for each node.
Today, we have been looking for the simplest way of giving a http control interface to our project. We found that the C library Microhttpd was matching our needs.
It’s a library which will allow us to create a very simple http server on the BeagleBoard. This way a user will be able to get registered into Casper’s « Database ». Eventually, through this interface, he will be able to give his name, a new Lua script or his various logins/passwords to access his mails and so on…
Besides, we made some changes in Casper’s prototype. We made a « box » in wood which contains the motors and supports Casper itself, so it’s easier to move it.
we have started today making some tests on the DCC part. As we have seen the good results with the oscilloscope, we moved to testing on a rail part by placing the train and sending the DCC commands through the rails. In fact we could command our train in both directions in different speeds.
Then, we started to implement a small module that takes Ethernet commands following a simple protocol. This module is translating the Ethernet commands to appropriate DCC and CAN commands in order to command different parts of our train model.
In parallel we still test the stability of our CAN module. Despite the good results there are very rare cases where our cards become unstable. We are making some modifications and we are going tomorrow to test on multiple light cards.
Our next PSSC is the initialization of Ethernet (what is already done) and control of our circuit from an extern program.
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.