The program has been modified to speed up the disc collection process. This means that the robot spends less time stopping for discs, and so will allow us to arrive at the construction zone earlier.
Wednesday 25 March 2009
Saturday 21 March 2009
New Sponsors
Also this week, after a few weeks in planning, we can officially welcome our sponsors, Phoenix Dynamics.
"Established in 1994, Phoenix Dynamics is a leading supplier of interconnection solutions to the Defence, Automotive, Rail, Nuclear and Control System Industries."
Check out the website, www.phoenixdynamics.com for more information on the company.
"Established in 1994, Phoenix Dynamics is a leading supplier of interconnection solutions to the Defence, Automotive, Rail, Nuclear and Control System Industries."
Check out the website, www.phoenixdynamics.com for more information on the company.
Problem solved!
We finally fixed the intermittent problem with the odometry system. It seems that the fluctuations in the encoder readings were somehow caused by the latest version of the PicAxe software. We didn't see the fluctuations during the bench test on Thursday night because we were using a different laptop with the older version of the software!
The team is realising now how much time even the simplest change like that can set you back. The only reason we changed the software was because of the problem with the 'new' chips not working, but this week has emphasised how wise the words are: "If it aint broke, don't fix it!"
It's been a very trying week this week, particularly after the huge progress last week. It's such a relief to see it working again, we can now carry on developing the obstacle avoidance system, and doing some odd jobs making the robot look more presentable for the competition.
The team is realising now how much time even the simplest change like that can set you back. The only reason we changed the software was because of the problem with the 'new' chips not working, but this week has emphasised how wise the words are: "If it aint broke, don't fix it!"
It's been a very trying week this week, particularly after the huge progress last week. It's such a relief to see it working again, we can now carry on developing the obstacle avoidance system, and doing some odd jobs making the robot look more presentable for the competition.
Friday 20 March 2009
Strange day
Despite thinking we'd solved the problem with the drive system, the robot was still doing different things on the table yesterday. We only have access to the practice table until 4.30 on a thursday, and went home at this time to carry out some tests.
We ran the sertexd command again to read the encoder values, and there are NO fluctuations in the readings what so ever now! However, we examined the last readings taken when the robot has finished each routine, and they vary considerably from the trigger values that we use to leave the subroutines. The largest deviation is 23 encoder counts, which is 1/3 of a wheel rotation! It's becoming a little clearer now what's causeing the variations in performance. The program is running too slowly to keep up with the readings from the encoders.
The options now are:
Try and speed up the program;
Use a larger, faster microcontroller for the main board;
Or, use slower reading, but less accurate encoders.
Today we need to make a decision on which route to take, and stick to it, as we don't have much time until the UK finals on May 1.
We ran the sertexd command again to read the encoder values, and there are NO fluctuations in the readings what so ever now! However, we examined the last readings taken when the robot has finished each routine, and they vary considerably from the trigger values that we use to leave the subroutines. The largest deviation is 23 encoder counts, which is 1/3 of a wheel rotation! It's becoming a little clearer now what's causeing the variations in performance. The program is running too slowly to keep up with the readings from the encoders.
The options now are:
Try and speed up the program;
Use a larger, faster microcontroller for the main board;
Or, use slower reading, but less accurate encoders.
Today we need to make a decision on which route to take, and stick to it, as we don't have much time until the UK finals on May 1.
Thursday 19 March 2009
Problems, problems, problems
The last 5 days have been quite trying for the MMTA team. The on Friday, the bot developed a strange symptom that we still can't properly explain.
Firstly, during testing, every now and then the robot would start skipping a routine in its program. Carrying out a 'hard reset' on the Picaxe 28 main board seemed to temporarily solve this, and we put it down to 2 things: either noise from the DC motor driving the vertical lift, or an old, tired 28x1 chip. Noise suppression capacitors were fitted to the motor, and we atempted to change a chip over on the PicAxe 28 main board.
This was when the first major problem reared its head. Fitting any 28x1 chip other than the old one meant the robot refused to move! We eliminated all hardware problems, trying a spare board, about 5 or 6 spare chips, download cable and even a different laptop to put download the program! All to no avail! Eventually, the problem was traced to the communication between the board that operates the vertical lift and the main board. As the robot is traveling around the table, the board for the vertical lift is monitoring for when a disc passes beneath a downward-facing IR sensor. When it sees a disc, it waits for the disc to pass past the sensor and then tells the main board to stop the motors while the claw picks up the disc.
It was this communication that was broken, so the program on the main board jumped into the routine that stopped the motors straight away, hence it not moving. This problem was, eventually traced to the fact that the two boards are on different circuits, a pull-up resistor was fitted in the line, and it now works fine. Why this worked with the old chip, we aren't entirely sure. Perhaps the old chip was faulty in some way that conveniently made it work, or perhaps there has been a slight change in design in the internals for that particular chip. (if anyone has any suggestions, please leave a comment!).
Once we had it moving again things still weren't right. The robot was very rarely following the routines it was supposed to and would randomly spin on the spot, drive for too far, and generally mess up. By running a 'sertxd' command on the main board we were able to monitor the readings that we were getting from the encoders. We found that there were random fluctuations in the readings, where they would increase to over 65000, before returning to normal. An extra algorithm was added to the program to ignore these, but they were so frequent that it meant the robot would still not behave correctly. Eventually, yesterday, by eliminating everything else that we could have changed, we discovered that it was the noise suppression capacitors we fitted on friday that were actually generating noise and interfering with the communications between the main board and motor driver. Removing these capacitors, there are still the odd fluctuation, but nowhere near as bad as they were before.
We will look into other forms of sheilding to try and get rid of these, but for now, the robot is performing consistent enough to get it scoring points again.
Firstly, during testing, every now and then the robot would start skipping a routine in its program. Carrying out a 'hard reset' on the Picaxe 28 main board seemed to temporarily solve this, and we put it down to 2 things: either noise from the DC motor driving the vertical lift, or an old, tired 28x1 chip. Noise suppression capacitors were fitted to the motor, and we atempted to change a chip over on the PicAxe 28 main board.
This was when the first major problem reared its head. Fitting any 28x1 chip other than the old one meant the robot refused to move! We eliminated all hardware problems, trying a spare board, about 5 or 6 spare chips, download cable and even a different laptop to put download the program! All to no avail! Eventually, the problem was traced to the communication between the board that operates the vertical lift and the main board. As the robot is traveling around the table, the board for the vertical lift is monitoring for when a disc passes beneath a downward-facing IR sensor. When it sees a disc, it waits for the disc to pass past the sensor and then tells the main board to stop the motors while the claw picks up the disc.
It was this communication that was broken, so the program on the main board jumped into the routine that stopped the motors straight away, hence it not moving. This problem was, eventually traced to the fact that the two boards are on different circuits, a pull-up resistor was fitted in the line, and it now works fine. Why this worked with the old chip, we aren't entirely sure. Perhaps the old chip was faulty in some way that conveniently made it work, or perhaps there has been a slight change in design in the internals for that particular chip. (if anyone has any suggestions, please leave a comment!).
Once we had it moving again things still weren't right. The robot was very rarely following the routines it was supposed to and would randomly spin on the spot, drive for too far, and generally mess up. By running a 'sertxd' command on the main board we were able to monitor the readings that we were getting from the encoders. We found that there were random fluctuations in the readings, where they would increase to over 65000, before returning to normal. An extra algorithm was added to the program to ignore these, but they were so frequent that it meant the robot would still not behave correctly. Eventually, yesterday, by eliminating everything else that we could have changed, we discovered that it was the noise suppression capacitors we fitted on friday that were actually generating noise and interfering with the communications between the main board and motor driver. Removing these capacitors, there are still the odd fluctuation, but nowhere near as bad as they were before.
We will look into other forms of sheilding to try and get rid of these, but for now, the robot is performing consistent enough to get it scoring points again.
Wednesday 11 March 2009
First Temple!
The robot successfully builds its first temple on the centre stacking point. This will achieve 29 points during a Eurobot match! The program still needs some work speeding up the timing and accuracy. As it stands, the program will successfully build the same temple for 4 out of the 10 random disc arrangements.
Monday 2 March 2009
Stacking Program Test
The first successful test of the stacking program was conducted on the playing table. The robot splits the 4 pre-collected column elements into 2 towers. Note the new rubber-lined plastic tube gripper, and the rubber wheel covers (made from balloons!) for extra grip on the table. These are far from being a long-term solution.
Subscribe to:
Posts (Atom)
Posts
