Moving on

The time of C.A.K.E. has passed and it’s time to move on. I started a new blog here that involves dsPIC mini tasks and projects to help me prepare for my upcoming year. Time to say goodbye to this blog, for now anyway.


It’s game over man! IT’S GAME OVER!

First and foremost, I would like to say in behalf of team C.A.K.E.: Congratulations to Frank the tank, good job lads you deserved it! And for all the other teams that might be reading this: good job lads we all did well, it was apparent who was conquering the arena yesterday!

Anyway the tournament is over and C.A.K.E.’s bloodlust has been extinguished. It wasn’t easy but C.A.K.E. rose to the challenge, what a day it was! And again I apologize if I’m only updating now, with the exams coming up and plenty of projects and write-ups to finish it wasn’t easy to look for time to update the blog. The team was happy with how C.A.K.E. performed that day, but it was a long journey to even get him to that table. My story starts three weeks ago: our robot’s circuit had been ready for a good few weeks and we were just waiting on the motors to be mounted and thought to ourselves that we were ahead of schedule as we have all the sensors wired up and soldered and we even had the infra red LED’s and wireless receiver ready to go, we had it working using the comprinter and all it was just a matter of hooking it all up. Bogged down with college work the team forgot that the tournament was looming closer and closer. In the end: the motors that we were meant to be used were scrapped as Paul found out it could not be mounted. A new design had to be made, and using the base of RACE C.A.K.E.; Paul came up with a variation of my old scoop-wedge design. Paul quickly sprung into action and fabricated the body and it was done with a week to spare for the competition.

The team then started to assemble C.A.K.E. about three days before the battle. sensors were mounted and holes were fitted for mounting of the circuit board and for sensors and such. two days before the battle we started tweaking him and by that evening we were programming. A day before the battle we were confident enough with C.A.K.E. being able to make it, that morning we had him on the table not falling off and looking for opponents with a simple code. The team was delighted and spent the rest of the day polishing him up.

Suspense before the big day

As said above C.A.K.E. was functioning well and no problem the day before…..up until around 7pm that day. The night before the battle, one of the sensors decided to give us trouble. It was all working perfectly until Paul turned on the switch and C.A.K.E. just laid there, we waited a few seconds before seeing smoke coming out of him, a telltale sign that it hit the fan. We did a continuity test and saw that the problem was a short in the sensors, it burned through the shroud that Paul used to insulate them, first time I’ve seen it happen as heat-shrinks are usually stable and hard to burn through! Lady luck decided to leave us the night before the big day, I was losing it. Come 8pm me and Paul were still troubleshooting as even with a new sensor plugged in; C.A.K.E. wasn’t acting the same. We feared the worst, “the PIC might have blown, the motor driver chip, maybe it was the battery pack?” these were things going around my brain. We got kicked out of college around 9 that night, with a non-functioning robot. I wasn’t going to give up, not now, and so I got to work that night, checked every track, every wire, every connection of that circuit. Gave the old gearbox a good cleaning and moved stuff around. The back sensor had to be moved to the front to make up for the one that shorted out. I wrote up a simple program that utilizes the two sensors and rangefinder as much as possible and so the program was back from scratch. Finally, at around 6:32 AM on the day of the battle, less than 6 hours before C.A.K.E.’s meant to perform; we were back in the game! He was a different robot, reborn from the ashes of the one that died a few hours ago, he didn’t use state machines as I instructed him myself, he only had two colour sensors but he didn’t care, because the only way he’s going from now on is forward(literally and metaphorically lol). Tested him and put 4 books on the table and within 9 seconds all of them were out of the arena, the sleepless night was worth it. With that done I decided to put my head down to take a nap before the battle, I took another glance at the nightstand; 7:35AM it read, before falling into slumber.

Opened my eyes and it was 10:30AM! I had to hurry and get ready but only got to college at 11:30(due to some driver ramming the back of the taxi that I was on). Met with the teammates to give C.A.K.E. the old makeover, give him an aul paintjob. The team originally decided on a side panel but lacked time because of the trouble encountered the day before, another thing missing was the infra red LEDS, we only had to mount them and that was it, but time was scarce and wouldn’t permit so alas, C.A.K.E. had to go semi naked and mute, better than what he was the night before though.

The battle

The walk from the basement to Gleeson hall felt like a thousand mile trek. Coming in and seeing everyone making finishing touches with their robot was great, there was a lot of tension in the air. We decided to lash our robot in the arena to try the light levels and it was perfect, it also managed to push a few bots and flip one over while doing this. A last minute change of batteries was done before the announcement that it was about to begin. C.A.K.E. was starting at 12th, not too shabby we said, the first target was to get into the top 8. When it was nearly our turn I decided to give C.A.K.E. another trial on a little practice arena, and what happened next I could not believe; he was behaving abnormally again, from the looks of things he was behaving as if there’s always something in front of him and so he was only going forward, that is at least until the sensors see white and then he turns. By the time C.A.K.E. was called for his first battle he was still acting like this, my nerves were shot. After all I did the night before he starts acting up as the battle is about to begin. I was losing hope until I saw with my own very eyes C.A.K.E. winning three times in a row before losing! Wasn’t too shabby for a robot that doesn’t turn! After the loss I grabbed C.A.K.E. for diagnostics and saw the problem! The rangefinder wire got disconnected when we changed the batteries. Next round: we were back, C.A.K.E. won 9 times in a row! Climbing up to third and staying there until the eliminations were done. We were delighted to how he was performing taking the fact that he only had two front sensors and a rangefinder(back sensor ruptured the night before). C.A.K.E. was taking names.

The finals

C.A.K.E finished 3rd in the eliminations and is going to compete for the finals. It was a knockout competition, anything could happen now. On the quarter finals C.A.K.E. managed to beat Palm 5, for the semi finals it was best of 3 with Spongebob. Spongebob put up a good fight but C.A.K.E. took the cake. We came a long way, and it was Frank the tank who was standing in our way, best of 5, C.A.K.E. took the first win with a nice turnaround move, frank took the second knocking C.A.K.E. off the table, this round was more important that we thought it was. C.A.K.E. would not be able to recover as the fall broke our rangefinder off and so C.A.K.E. was blind once more. It was so close! It was there! Frank ended up taking the next two because of this and the final score was 3-1. We lost to a worthy opponent. But Paul said it best: “It was a kick in the balls” when our rangefinder broke that time.

C.A.K.E.’s final program

int x = 0;
void main(void)
{
	setup();
	while(1)
	{
		while(x == 1)
		{
			while(read_analog_channel(0) < 500 && read_analog_channel(2) < 500 && read_analog_channel(4) < 50) 			{ 				sharpright(); 			} 			while(read_analog_channel(0) > 300 && read_analog_channel(4) < 30) 			{ 				sharpright(); 				x = 1; 			} 			while(read_analog_channel(2) > 300 && read_analog_channel(4) < 30) 			{ 				sharpleft(); 				x = 0; 			} 			while(read_analog_channel(4) > 70)
			{
				while(read_analog_channel(2) < 300 && read_analog_channel(0) < 300) 				{ 					forward(); 				} 				if(read_analog_channel(0) > 300 || read_analog_channel(2) > 300)
				{
					Delay10KTCYx(65);		// Delay
					reverse();
				}
			}
		}
		while(x == 0)
		{
			while(read_analog_channel(0) < 500 && read_analog_channel(2) < 500 && read_analog_channel(4) < 30) 			{ 				sharpleft(); 			} 			while(read_analog_channel(0) > 300 && read_analog_channel(4) < 30) 			{ 				sharpright(); 				x = 1; 			} 			while(read_analog_channel(2) > 300 && read_analog_channel(4) < 30) 			{ 				sharpleft(); 				x = 0; 			} 			while(read_analog_channel(4) > 70)
			{
				while(read_analog_channel(2) < 300 && read_analog_channel(0) < 300) 				{ 					forward(); 				} 				if(read_analog_channel(0) > 300 && read_analog_channel(2) > 300)
				{
					Delay10KTCYx(65);		// Delay
					reverse();
				}
			}
		}
	}
}

Stripped down circuit

A lot of changes had to be made, one rangefinder, had to take out two colour sensors, only two motors, and didn’t get to connect up the IR LEDS. C.A.K.E. was incomplete but he did the job. Another thing the team would have added were side covers. The code is very simple as well as there wasn’t much to be played with(two front sensors and a rangefinder). But anyway it’s over. I’m sure going to miss C.A.K.E.

C.A.K.E. in the battlefield

C.A.K.E. VS Senshi

Cake VS Senshi outcome

Shocker trying to get a piece

Upsie daisy! *with Ghost Rider

Upsie daisy – part 2 *with Ghost Rider

Kuwait before introduction to C.A.K.E.

C.A.K.E. says “Hi”

Au revoir!

Squaring up with Spongebob, under them: check

Endurance test – with Spongebob

Playing tag with Palm5

Head to head with big Fred. Bigger doesn’t mean stronger!

The Finalists! Dream match!


Robot Circuitry

I apologize for the lack of updates on this weblog for the past three weeks now. Trying to get C.A.K.E the way we imagined him to be wasn’t as easy as we thought. The team decided to stick with the design I had on the earlier post as this was similar to what the team had in mind in the first place. Anyway, onto the updates. Same as before I took the liberty of taking charge in C.A.K.E.’s circuitry. So far the team has decided to use two Sharp rangefinders, four Fairchild colour sensors, two switches and four motors. A lot of power draw is expected and the plan to overcome that will be part of the next private post. Here’s the schematic of the circuit built:

As seen on the circuit: analog channels 0-4 will be used for the colour sensors and analog channels 5-6 will be the rangefinders. Two motors will be connected in parallel with each other and will act as one motor(our positioning of the wheels makes it so that they’re just all back wheels). Even though the LD293D’s Datasheet only said it can only handle a maximum of an amp per channel it could in reality take up to three, this makes putting the two motors in parallel possible without burning it out. The switches’ functionality will be discussed later on. The transmitter/Reciever part will be edited later on once the infra red receivers have been received(lol). Below is the photo of the actual circuit, at the moment everything has plugs connected to them to give us ease of moving them if ever needed.


Rangefinder Characterisation

Week number X( March 16-23 2012)

Another week into the development of C.A.K.E. has passed and the group is getting there slowly. The main reason why the group hasn’t started building the robot is because the design had to be finalized first. First is the issue of what wheels/motors and other components that the group can afford to get without going over the €50 limit. As said in one of the first week I had planned to actually manufacture the hubs for the wheels and mold my own as this way you get full control on the size and material that the wheel is going to be made of, wheels such as these would have been pretty easy to manufacture if there was a lathe lying around, the group couldn’t afford to spend nearly €15 on just a pair of wheels and so we just stuck to using old meccano wheels. It would’ve also been easier to just buy motors and wheels as a bundle as this way you’ll know that the shaft is compatible with the wheels(a problem that the group encountered), but these cost too much(some ranging as much as 200 euros!), the cheapest we could find was with the website that those wheels on the link above(two motors and two wheels would cost €50.26 without shipping) just for a pair of wheels and motors would’ve cost more than the limit so that’s out of the question. Instead of buying stuff I decided to just ask my cousin to just send me motors from my old tamiya toys and motors from a robot arm and some other materials to see what we could use. Most of the tamiya motors(mabuchi) are fine but 3 out of the 8 motors from the robot arm were broken(We still have to test it out but I feel that one or two of them aren’t running at the same speeds as the other ones). We still have to run some tests and this will determine how many motors we’ll use. With most of the electronic parts covered it was just a matter of deciding what design we’re going for. When the lads saw the rough design I drew up they said that it was fine and we should go for it. This is a basic design and I will look into adding more stuff into it if time permits. And so with that me and the lads just messed around with the motors and wheels last Friday. Our main problem with it was that the output shaft of the motors were too small, the first idea was to manufacture a shaft but with some good luck I think we found out a way to couple the wheel with the output shaft….using a pen. I saw Paul messing around with Chris’ pen and messing around we tried sticking the shaft on the pen and the other end to the wheel; it fitted perfectly and Paul’s working on a way to make the coupling more stable.

Sharp Rangefinder

Last weekend I got to mess around with the sharp rangefinder that we were given. With some tests I was able to obtain the voltage outputs which corresponds to the distance from the rangefinder. I planned to put that onto this post but the plan changed when Ted showed us a way to read from serial ports of the PIC and using this to communicate with it. I connected the circuit as such:

And used the simple program:

void main(void)
{
    // Configure the PIC
    setup();

    // Make the motors go forward and reverse
    while(1)
    {
        printf("Analog Value = %d \n" , read_analog_channel(0));	// Print current value in RA0
        Delay10KTCYx(10000);  									 	// 5s delay
    }
}

And got the following results:

Rangefinder Characteristics

With these results it’s going to be easier to write the rangefinder part of the program. Saves a lot of time trying to convert from voltage to digital units and this way the figures will be almost 100% precise. That’s all for tonight folks. More coming in a while.


Design concepts

It has been a dry week for team C.A.K.E.. The team hasn’t really spent any time on the robot as things are piling up in the other modules. With the lack of updates I decided to post a “filler” post so as to not have any gaps in the timeline of my blog. This post is going to be all about design concepts that I have thought of and think will be useful if implemented on the duel bot. The ideas that I will post today wont necessarily be integrated onto the bot, but this gives the group a few options. The group will have a meeting soon and we will collect all of our design ideas and pick out the ones which we feel will give us the better edge on the bout. This particular post will contain one of the viable designs which I like to call the classic “wedge-scoop”  design in which it both incorporates a scoop and a wedge together in a system.

Solidworks

I decided to spend tonight trying to learn how to use Solidworks as one of the lads from the class uses it a lot and it seems really good for designing stuff. Paul(McCarron) gave me a quick tutorial online and he also walked me into making the chassis prototype. He also taught me other stuff such as showing the exploded view of the model and such(and make a video of this which will be shown later). Using Solidworks is good as you can actually see what you’re making in a 3d perspective and see if there’s any flaws in your design and this way you can troubleshoot it. But the main reason why I really decided to use this program is because I am terrible at hand drawing. Onto the first design!

Wedge-scoop hybrid

The first design is the only one which I have a drawing of at the moment sadly. As I’ve said I only got Solidworks today and so I only had time for one drawing, and believe me you it was hard enough. And as it can be seen on the design; our robot will be made from scratch again. The main concept of the wedge-scoop hybrid design is the same as most of the designs being used by most robo-sumo robots today; and that it tries to take some of the robots pushing power by lifting their wheels off the table. With the wheels off the table the other team’s robots will lose some torque and traction and it will be easier for C.A.K.E. to push them off the table. As seen on the bottom views of the design: the robot is going to made with different parts to be assembled at the end. Here’s a video to show the different bits and pieces that the robot is going to be made of:

As it can be seen in the video; tubes are attached to the chassis by brackets. These tubes will hold the motors inside them and will act as an axle, a hole will be drilled in the middle of the pipe for easy access on the wires to deliver power to the motor. This design can only be implemented if we use motors with planetary gearboxes in them so that they can be mounted as such(directly to the wheels). This is good as most of the weight is going to be applied to the wheels which adds traction. The output shaft of the motor will need an adaptor to connect to the wheels as such:

Smaller wheels are also needed for this design. Smaller than the ones we used for the race anyway. One might think this is bad as bigger wheels means more torque but there’s also a good thing with smaller wheels; and that’s they’ll have lower inertia. I actually thought of molding my own wheels at the start as there are tutorials in the internet which teaches how to do this easily, but it requires manufacturing metal bits and to be honest I’m no good with a lathe.

The scoop

Having a scoop before the wedge makes it easier to get under the other robots first, and a low angled wedge ensures that our robot gets under and with some luck; maybe tilt the other robot over. In addition to that I plan to paint the flat part of the scoop white as to fool the other team that their robot is at the edge of the table already and keep on backing off if the trick is successful. The rest of the robot will be painted matt black to make it less visible to the other sharp rangefinders that the other team might use. Another great thing about having a wedge is that it gives you an angle which bounces off the IR coming from the Sharp sensor in different directions, the robot is angled front and back so this decreases the chances of getting detected again. It’s a simple design but a bit tricky to pull off, first of all the limitations in our dimensions limits us from using a long and wide scoop. This means that the group is forced to use a short scoop, to make up for this I have to make sure that our robot is facing the opponent directly when making contact. And to make sure that happens we’ve got:

Sharp Rangefinder X-Beam

The last image was drawn via Inkscape and not Solidworks. As it can be seen above; the beams are crossed(not a ghostbuster reference) and this gives a wider span of sight. The robot will be instructed to go on “search mode” once it is turned on, it will keep on doing this until one of the rangefinders detects something, if the right one detects something: keep going left, if the left one detects something: go right. This will trap the opponent in the middle waiting to be pushed. I was planning to draw a flow chart of this process but it’s too late in the night now, I’m just going to include it in the next update together with the other flow chart that I was planning; which is the flow chart of the “states” of the robot. And the last thing I was thinking of implementing in the wedge-scoop robot(and every robot I think now that I think about it):

The “Switch”

As the rules state that the robot can’t be changed on the competition we cannot reprogram C.A.K.E. with every battle. And so what I thought of was: maybe we can use a toggle switch to change the behavior of C.A.K.E.. Switch is ON: C.A.K.E. is in aggressive mode, Switch is OFF: C.A.K.E. is in passive/defensive mode. This can of course be expanded into two switches, which will then give up to four “modes” which we can program C.A.K.E. with. That’s all for now folks, another update coming up in the next few days.


Back to the drawing board

Before anything else I would like to apologize to anyone who felt offended by my earlier post. Looking back and reading at it now; which I should have done before posting it, plenty of harsh words were said. I was rash and let my emotions take over, it’s too late to take it down now as pretty much everyone already read it so. Here’s a small token of apology. That photo pretty much sums up what happened. After all, no matter what I say, it won’t change the outcome of the race. And so I hope you all accept my apology. I was a moany bitch and a sore loser.

Fresh start

I missed last Friday’s lab there but Paul kept me up to speed with what’s happening. I shall be posting another log shortly after this one showing images of my interpretation of the “states” that Ted covered Friday morning. At the moment there aren’t really that much progress in the team’s building of the robot. We were all burnt out last week because of the race. The only thing that I managed to do was source some new materials. I asked my cousin to send me down my old toolbox for my toys, as said on an earlier post I used to always play with mini 4wd so if no one messed with my stuff; it should have plenty of materials I can use. I also asked him to take old motors used in my old RC cars back then, if you can’t beat ’em; join them I say. I should also get one of these bad boys, not the exact same model but my cousin told me it was circular in shape. I’m getting them for nothing so we don’t have to worry about being short on motors I think. Anyway the rest of the updates are going to be on the next post as I can’t talk about it too openly. That’s it for now.


The race

Introductory rant

I can’t say that I’m happy with the results of the seeding competition. First of all I would like to say that we have no regrets making our robot from scratch. Sure we could have taken the easy way out and broken an RC car and just stuck its motors to the chip and that’ll work great, any 10 year old child could do it. Those cars are fast, plastic and light and stable and are made for speed. I’m not trying to sound bitter and have a dig at the other teams, but to me that’s just cheap and lazy. The group feels good about making it pure and from scratch. We take pride in our little creation. I’m pretty sure half the teams can’t tell you the exact specifications of their motor, how much torque it produces, or how much it’s geared. We are one of the few teams, if not the only team to know what the characteristics of our system is, we know how it will behave even before we set it on that table. This is one of the main reasons why we got ours going so quickly, and if there ever was any trouble; we solved it straight away. So in the end, even though the payout wasn’t as good as we expected; we gained something more valuable during the course of making our racer car, and that is experience and knowledge of the whole system. We shall retaliate on the battle and slaughter every single one that comes in our way, I say that without hesitation.

Problems encountered

In the end C.A.K.E. only finished 9th 12th(wow my day just keeps getting better) with a time of 1.599 seconds. Pretty decent time overall but not good enough. Now I know what you’re thinking; we’ve had C.A.K.E. up and running for 3 weeks now, how did we not improve him? To be completely honest with you we tried, we improved every aspect of him, we cut the chassis down we played around with the gearing. But the biggest problem eluded me until after the race: our motor. C.A.K.E. had gotten slower within the span of 3 weeks it has been functional. The main thing I forgot was that I decided to go kamikaze on the race. Our motors were only rated for 3 volts, I decided to make a glass cannon and run it at 6V. At 6V it was eating up 2 amps of current, this is why prolonged use of this motor at 6V should not even be tried. As I’ve said it was only rated for 3 volts and so my theory on why it has gotten slower is that the brushes are burnt out or partly burnt out. I shall have a look at this when I get it again to have a look on the inside of the motor and confirm my theory. Our motor degraded in the span of 3 weeks, as seen on the videos posted a few weeks back; it was flying on the table, it even does a little wheelie at the end when it tries to stop as the motors were still undamaged at this time. If we had the race 3 weeks ago I’m pretty sure we could have won, partly because almost all of the other groups only got their robots working this week.

As the weeks progressed the code had to be changed as well, I learned about pulse width modulation at my own time and before Ted even covered it in class. I decided to use this when the group started noticing that C.A.K.E. wouldn’t stop as quick in the end anymore. The night before the race our robot was working perfectly even without PWM. When I came back in college earlier for the race and tried him out; he wouldn’t stop again. I wouldn’t have thought the degradation of the motor was going to be that quick. And so I used PWM to save the day, C.A.K.E. had to compete in the race handicapped.

Another thing that we didn’t think about was the weight of our robot. It was too heavy. I had an idea of making it bounce off the wall to gain a bit more momentum going back and help the motors. If we could redo the race and change one thing; it would be the weight. Being too heavy it would not bounce, the other plastic toys who competed on the race bounced no problem as their chassis is light. I’m not blaming Paul as he did a great great job on making the chassis and if I made the chassis it wouldn’t even be as close to what Paul made. We just didn’t think it would be an issue. In the end we just put a rubber bumper at the front to absorb some of the force but this didn’t even help much with the bouncing. And so what I did in the end was change the code again to make that blow a little softer by going slower when it’s about to hit the wall. Here’s the final code used for the race written by myself.

void setup(void);
unsigned int read_analog_channel(unsigned int);
void fastforward(void);
void modforward(void);
void fastbackward(void);
void modbackward(void);

void main(void)
{
    // Configure the PIC
	int x,y=0;                           		 // X and Y will be used as a flag
	x = 0;
    setup();

    // set motors forward when power is turned on
    while(1)
    {
		while(x == 0)
		{
			while(y==0)
			{
				LATD = 0b00000001;				//Forward full force for a bit
				Delay10KTCYx(1000);				//delay
				y=1;							//breakout
				break;
			}
			modforward();						//Slow down before wall is hit
			if(PORTDbits.RD4 == 1)				//Breaks out of loop when switch is hit
			{
				LATD = 0b00000000;				// Motors stop for a bit
				Delay10KTCYx(1);   				// delay
				x++;
				break;
			}
		}
		while(x == 1)							//Go to this loop when switch is hit
		{
			read_analog_channel(0);      	    //Read back IR sensor
			while(y==1)
			{
				LATD = 0b00000010;				//go backwards full force for a bit
				Delay10KTCYx(650);				//delay
				y=2;							//breakout
				break;
			}
        	modbackward();						//Slow down to be able to stop
			if(read_analog_channel(0) > 900)
			{
					LATD = 0b00000001;			//Motors go forward for a bit
					Delay10KTCYx(50);   		// delay
	        		LATD = 0b00000000;			//Motors stop
					x++;						//Breakout to stop until reset
					break;
			}
		}
    }
}
/* Pulse width modulation(sort of ha ha)*/
void fastforward(void)
{
			/*80% duty cycle*/
			LATD = 0b00000101;					//Motors go forward
			Delay10KTCYx(8);   					// delay
			LATD = 0b00000000;					//Motors go forward
			Delay10KTCYx(2);   					// delay
}
void modforward(void)
{
			/*50% duty cycle*/
			LATD = 0b00000101;					//Motors go forward
			Delay10KTCYx(5);   					// delay
			LATD = 0b00000000;					//Motors off
			Delay10KTCYx(5);   					// delay
}
void fastbackward(void)
{
			/*70% duty cycle*/
			LATD = 0b00001010;					//Motors go backward
			Delay10KTCYx(7);   					// delay
			if(read_analog_channel(0) > 900)
			{
					LATD = 0b00000001;			//Motors go forward for a bit
					Delay10KTCYx(50);   		// delay
	        		LATD = 0b00000000;			//Motors stop
					return(0);
			}
			LATD = 0b00000000;					//Motors off
			Delay10KTCYx(3);   					// delay
}
void modbackward(void)
{
			/*50% duty cycle*/
			LATD = 0b00001010;					//Motors go forward
			Delay10KTCYx(5);   					// delay
			LATD = 0b00000000;					//Motors go forward
			Delay10KTCYx(5);   					// delay
}

The pulse width modulation might not be perfect but that’s my version of it anyway from what I’ve read. In conclusion: C.A.K.E. functioned very well and as we instructed him to, we were always in control and never had any trouble with her. It’s just too bad that the motors had to burn out on us and I didn’t think about it till it was done. As for the other teams: you can’t have your C.A.K.E. and eat it, don’t get too comfortable being up there, we’re just warming up the seat down here for you. We’re coming for you.