Lesson 4
Date: 02/06 2014
Duration of activity: 09.15 - 15.45
Group members participating: Pætur Askildsen, Christian Hansen, Søren Gregersen, Søren Ditlev and Alexander Rasmussen
Goal
Plan
Adjust the code so that the balancing robot only uses the gyro readings and not the tacho counter (we have a hypothesis that the tacho counter is only necessary when the robot, in the LegWay, needs to balance on the floor). Tacho counter may not be needed since we want to make less subtle movements, in order to react on the tubes movements. The PID parameters should also be tuned.
We want to get the remote controller to communicate with the car inside the tube using Bluetooth. Hopefully the remote controller can be finished today.
The steps should be prioritized as follows, so we start out simple:
Make the car balance on top of the tube by itself.
Adjust PID (maybe do this through bluetooth to ease adjustment overhead)
Try removing tacho counter and rely solely on gyro.
When this works, add the remotely controlled car inside the tube to also be in to the setup.
Fine tune the speed of the car inside the tube (the faster it can drive, the more difficult we presume it will be for the TubeBalancingCar to keep balance on top of the tube).
Results
Tube Balancing Robot
The NXC program for the HTWay [1] (HiTechnics legway) does not use a PID controller. They instead use 4 variables to control the two motor powers of the HTWay, which in our example only will be one motor power, since we only have one motor. With their own words:
“To calculate the power these variables are multiplied by respective constants in a four term linear equation, the result being the power needed for the robot to stay balanced. The trick to making this all work, is finding the right constants.” [2].
The 4 variables the NXC program uses to balance the LegWay can be seen here, though translated into Java:
Last time we fed the result of this linear equation into a PID controller. Today we will take one step back, and use this variable directly to control the motor power, instead of, as the variable names says, inputToPID. We want to check that a PID really is necessary for a tube-balancing robot. We will also look at if all 4 parameters are needed.
Fine tuning the four parameters, the non-PID way
First test
We change the parameter tAV, the paramter controlling the influence of the angle velocity, gyroAngleVelocity, from 0,475 to 0,7.
Result: The car still does not react and drive fast enough, not enough motor power, when the car is far around on the tube. This points in the direction that we might need a PID, or at least the Integral term, so the longer the car falls off the tube in one direction, the more speeds it gets. But we try on without a PID.
Second test
As we needed more power, we try out multiplying the power by 2:
int power= (int) inputToPID * 2;
Result: The car drives faster, but this also makes the tube roll faster. The car can still not get up on the tube again when about to fall off.
Third test
We give the car bigger wheels, from the small ones we started with to the big ones with white inside of wheel.
Result: The same as in the second test. The car can still not get up on the tube again when about to fall off. We also notice and discuss, that since the LegWay uses the tacho counter, it starts driving even when the car seems to be perfectly balanced on top of the tube, or just on the ground and give it a push, and the car drives off. This leads us to our fourth test:
Fourth test
We try to remove the two parameters, motor speed deg/sec and tachocount to only use the gyro. To do this the
private float tPW = 0.042f;
private float tSW = 0.05f
are set to 0 so only the gyroAngle and gyroAngularVelocity are used to calculate the motor power.
After further reading on the HTWay, they also say they use the motorSpeed and motorPosition to keep the robot in place:
So what about the two motor terms? Well if the robot is perfectly upright and not falling but the robot is 100 degrees further forward than desired, in that case motorPos will be 100. [...] The motorSpeed term works in sort of the the same way as motorPos. [2]
Therefore it was good that we removed those terms, as keeping the robot in place is not the highest priority for our robot. The highest priority is for the robot to stay on the tube. Possible future work could be to determine the feasibility of using a behaviour-based architecture for keeping the robot in place while staying on the tube [3].
Result: The car still drives off, and starts to drive faster and faster when placed on the floor. We conclude therefore that it is not the motor parameters but the gyro sensor which drifts from the initial offset, which makes the car drive off. We need to make up for that either in the build of the robot or the code to deal with gyro drift.
Fifth test - Gyro drift due to motor interruptions?
Søren found from a forum, that if the HiTechnic gyro sensor offset is calibrated when the motor is off, when the motor is turned on the electromagnetic field of the now turned on motor will cause the gyro sensor to drift [4]. To try to fix this, we increase the height of the placement of the gyro sensor on the car, so it hopefully will not get affected by the motor.
Figure 8: The car with the gyro sensor mounted higher.
Another finding on this forum is that when the gyro sensor gets hot it will get different readings and thus drift. We found that turning on the gyro over time it would drift, presumably because it gets hot, but then when it was hot we reset the program thus recalibrating the gyro sensor and then it didn’t start driving when placed on a flat surface, the floor (gyro sensor drifting).
That the motors affect the gyro sensor was already thought of in the code we made last time, as the motor are activated by calling Car.stop() right before the calibration of the gyro sensor:
// Ensure that the motor controller is active since this affects the gyro values.
Car.stop();
However it seems that using Car.stop(); alone does not prevent drift.
Result: Now with the higher placed gyro sensor, finally the car doesn’t run off so immediately when placed on the ground with the same code as when the gyro sensor was placed lower. After a talk with Ole we realized that this however could also just be because we stabilized the gyro sensor more in the LEGO attachment construction than it is the height difference making the gyro sensor more stable. However, when given a push, the car does slowly crawl in one direction, but not as fast and accelerating as before. A conclusion is therefore that the placement of the gyro sensor more stable results in a not so drifting gyro. Some anti-drifting still needs to be implemented though. It is however much better now.
A finding is also that Car.stop() is not a good way to ensure that the motors are active before calibrating the gyro sensor, or that this approach does not fix the gyro drift problem.
The results from this, that we need to conquer gyro drift, is also to take a step back and do some experiments with the gyro sensor. Søren G and Alex were put on this task 11.41.
Now that the tube balancing car does not drive off when placed on the ground, we try again to test it on top of the tube. It however still falls off when the tube starts rolling and accelerating. The car needs to accelerate more.
Sixth test - Fine tuning tAV and tAN and gyro drift
Since the gyro sensor drifts significantly less, while Alex and Søren works on reducing gyro drift Søren and Christian will finetune the two parameters tAV and tAN respectively controlling the influence of the angular velocity and the gyro angle on the power to the motors.
We however, end up with going back to a PID because the car needs much power to avoid falling off the tube but this also happens fast, so the car reacts violently just using a linear equation to power the motors.
We first started out with only a P-controller, and found from (2.0 → 1.0 → 0.5) that kP= 0.5f worked well: the car did not oscillate violently. We then tried to make PI- controller with kP = 0.5f and kI = 0.5f. This made the car drive back and forth quick. We then reduced kI to 0.05f. This was better, but the gyro still drifts.
After writing to the LCD display both the angular velocity and the angle we found that the angle kept increasing.
Remote controller
The remote controller uses the tacho counter and this value from the tacho counter is mapped to speed using the code in figure 9. The spam of the speed is between -100 and 100 which means power of 100% backwards and 100% forwards respectively.
Figure 9: Code snippet of tacho counter mapped to speed
The calculated speed is sent to the car inside the tube using bluetooth communication and today we managed to get the bluetooth communication to work. Even though the spam of the speed was between -100 and 100, and the bluetooth communication worked, the car could only drive forwards even though it was supposed to drive backwards.
The reason why the car only drove forwards could be that the speed was converted from float values to integer values. We tried change the speed value to integer values, so that it never is a float value. This task bigger than expected and it was revoked. Unfortunately something went wrong, the NXT started ticking and the program would not start. This resulted in a little tension and we have to fix it as the first thing next session.
When we tested the remote controller and the remote controlled car inside the tube, we saw that the car would drive until it turned upside down and then it could not move, even assumingly was built to drive upside down. A video of the test can be seen here [5].
The reason that the car does not drive up side down is that it is two-wheel driven.
Conclusion
We have carried out a series of tests to make the robot balance on top of the tube. In this process we discovered a phenomenon called ” gyroscopic drift”. We played a bit around with different things that might affect the gyro drift and made a few configurations to accommodate gyro measurement inaccuracies. Furthermore the remote controller is nearly fully functional, except that it at the moment only drives in one direction.
Plan for next session(s)
Work on reducing gyro drift.
Fix the remote controller and figure out why the remote controlled car only drives forwards and fix this as well.
Rebuild the remote controlled car, so that it is four-wheel driven and can drive upside down.
Figure 1: Code snippet of if-statement in RCCMain.
Figure 2: Code snippet of fixed code in RCCMain.
Figure 3: The gearing to make the remote controlled car four wheel driven.
Figure 4: The rebuilt remote controller.
