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.
While Loïc and Bertrand were working on Friday’s presentation slides, Samuel and myself spent the whole day testing our copter’s PID.
We finally found two majors bugs in our code (a motor offset unbalancing the system and a Integral term too often cleared). After that we were able for the first time to get a real flight while only acting on the thrust using remote control. We now have to add yaw PID and altitude PID and we may have something really nice to show on Friday.
During the week end, we welded the MB Leds with Alexis. It was quite long but eventually we have our own blocks.
Benjamin created the remote functionality; It works quite well. If a block turns of 180°, it will be the remote to change the program.
I fixed some problems in the algorithm with the MB Leds and I will continue until the presentation.
After firmware transmission Cédric tried the firmware upgrade already implemented on TP PCB by Benjamin but failed to implement it on MB Led blocks in due time and eventually stopped his work : In fact, we have few time left and we prefer to focus on the presentation. Now, he will work on an animations.
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.
These last two days we mainly worked on tuning the PID coefficients to improve the stability. In this way, we tried to find the best set of PID coefficients so that RoseWheel could raise from an almost horizontal position and recover stability as soon as possible and then maintain this stability over time, even under hard external perturbation. We also worked on improving the coefficients we found for the human driving mode to make the right compromise between smooth-driving and responsiveness.
During this test and improve phase, Alexis advised us to plot the curve of the different values critical for our system. Thus, we plotted over time the value of the angle and the angle rate before and after the kalman filtering and also the command sent to the motor calculated by our PID algorithm.
It made us find 2 problems in our software that explains why at the beginning RoseWheel was so unstable:
The Kalman filter wasn’t configured correctly. We first configured it for the testbench but we forgot to change the time step that was indeed ten times smaller than the correct value. That led to latency and incorrectness in the output of the Kalman filtering. Changing this parameter to its correct value made the system become really more stable.
Even after the Kalman filtering, we noticed that the angular rate was still a lot noisy. This noise caused our gyropod to vibrate a lot when increasing the derivative coefficient Kd in the PID. That is a problem because increasing the derivative coefficient is the only way we have to lower the amplitudes of the oscillations induced by a big proportionnal term Kp in the PID. Thus, we decided to smooth the angular rate value by using a low-pass filter after the Kalman filtering. It’s really a simple filter as it’s only made of 2 coefficients, but according to the plots, it made its work correctly and the angular rate seems to be really smoother than before. But while testing, increasing the derivative coefficient still leads to oscillations and vibrations, so we still have to work on it.
As we obtained satisfying results at making RoseWheel maintain its equilibrium, we started working on other features :
We implemented the safety switch and elaborated a protocol to avoid as much dangerous situations as possible :
At the very beginning, when one presses the power on button, RoseWheel is in self-driving-mode by default. That means it will try to reach its equilibrium position as soon as possible and then remain in this position. We assume that the user isn’t too silly and, for instance, will not try to power on RoseWheel in an almost horizontal position whereas he is facing it. Then, as soon as the safety switch that is located on the base is pressed, that means that someone has its foot on RoseWheel and wants to ride it : RoseWheel switches to its human-drive mode. If suddenly the safety switch is released, RoseWheel checks the angle. If it’s almost 0°, that means that RoseWheel’s speed is almost 0 and the person maybe wants to get out, then calmly RoseWheel switches to its self-driven mode (we still need to implement it). If the angle is under 75°, that could means two things: the person has felt down or the person has temporarily raised its foot. Thus, if the safety switch isn’t pressed within 1 second, RoseWheel makes a special noise, then, if it’s still not switched on within another second, RoseWheel switch to its self-driven mode. Finally, if the angle is greater than 75°, that means that the person has felt down and RoseWheel could represent a menace for people around, motors are disabled.
2) Concerning the obstacle detection, we almost finished to implement the sharps and sonar drivers. As these detectors are really sensitive to the external conditions, we still have to test them and see how they react in the different environnements RoseWheel will evolve in.
3) Concerning the remote control, we almost finished to implement the drivers for the Bluetooth, we made some tests yesderday, but we still need to continue them today and we will talk more about it in the next article.
We can now control the attitude of our copter with the RF remote control. We have also implemented the possibility of turning on/off the motors directly with the RF remote control. Bertrand has made a script for running all the control tasks at boot. We can thus take control of our Copter as soon as the gumstix has started and is running Linux, without using any SSH connexion.
Then, we took the Copter outside for a first flight in real conditions. We succeed in taking off, but I wasn’t very comfortable with it. Then, we had a big crash: Bertrand accidentally put the thrust too high at the takeoff. The Copter overturned and damaged/broke some propellers. Fortunately, we put a protection onto the motors’ boards yesterday. They thus don’t seem to have suffered damages. Here are some photos after the crash. (Photos are from Samuel Tardieu)
the broken propeller... what a shame.
Crash of the 22th April, 2011
Tomorrow, we’ll try to improve our PID algorithm for pitch, yaw and roll, and then we’ll probably work on the Kanade algorithm, for X and Y control loop.
As we we have foccussed on stabilizing our CAN protocol. We have tested glowing lights through CAN
with the central station and four light cards.
We have finished the ethernet part that takes bytes from a remote computer and translates them to DCC commands.
We have written a program for the sensor card.
Then we started moving some cables and old cards from our train circuit. We are now testing the controlling of six light cards.
After finilizing our software, what should take with testing two days, we will solder our sensors on our sensor cards and fix all cards on the train circuit.
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!