Cody's Pre- Control Loop Update

Last week we worked very hard on the report. We wrote most of the document, and so now it's about ready to turn in. Of course, we don't have anything on there about flying yet. We're not there! Other sections are done, however. We have about fifty five pages of documentation for our project, and we feel that more is needed for an accurate representation of what we have done.

As always, all of our documents and code are at code.anzhelka.com for download. The reports are there as well, and we hope you'll take a look at them.

-------------------------------------------------------------------------------------------------------

Over this past two weeks, I've worked approximately seventy hours on this project. It's been a busy time, but we have accomplished much. I'll next start working on the IMU interface code and hopefully get that up and running. Then it's on to working on the assembly code for the main control loop. For that, I've been looking into the BMA debugger for Propeller assembly. I'm (as always) optimistic about what can be accomplished, and I still have hope for flying.

Project Task Schedule

We've been getting lots of questions on when we will be flying, so here is our best guess at the timeline. This is updated live too, so be sure to check back. I thought about adding a "Who to Blame" column, but it wouldn't work anyway... It's clear who is to blame for any and all delays.

GUI Update

Over the last week I have been working on the test stand. I've developed the structure for the Anzhelka GUI as well. This GUI will be used to display real time data about the quadrotor. For this part of the project we will be able to display in real time the RPM, voltage, current, torque, and thrust of the motors as they go through the test stand process. The GUI is particularly necessary for tuning the various runtime parameters during testing. We have about a dozen PID loops that will  need to be dynamically tuned. The GUI will be very useful for tuning without requiring that we change constants in the code (which would require a compilation/download cycle).

I also worked on a poster display board for the thrust/torque test stand. This board is helpful because it provides an introduction to a part of our project. Luke and I presented the board and test stand by tabling at the Parallax Expo in Rocklin last weekend.

This next week I hope to get the GUI code and the test stand code finished.

Week 2

Last week was a very busy week. The IMU is currently in a state of disrepair and we are waiting on a reply from the manufacture to see if it is covered under warranty, or if we need to buy another. We have managed to get all machining done for the Motor Thurst Torque test stand thanks to Gene. 

When we went to the Expo, we learned that there was a design flaw with the stand and that we wouldn't be measuring the force correctly. Cody already knows how he is going to change the stand so that we do achieve proper measurements of the forces.

In the past week I have put in over 50 Hours (excluding driving ~15 Hours). It put a very big toll on my body to be able to dedicate that much time into the project in one week.

Before my next update I want to have the motors tested, graphed and ready to add their coefficients into the stabilization algorithm. I would also like to have the report up to speed on where we are in the project.

Parallax Expo in Review

So I am going to admit that I have never been much of a Parallax guy, not because I didn't like them or anything personal, but because I had never really used their product. I also had never been to company Expo. 

With all that said, I had loads of fun this past weekend. Cody and I set up a booth to show off our Motor Thrust, Torque test stand. It was great to get both feedback and to teach people about the dynamics of flying a quadrotor autonomously. There were many different types of people and companies that attended. It was very cool to talk to the robotics guys from Microsoft, they liked our project so much that they wanted to record our little presentation to show it off to their colleges. Telling people about our project helped me see that people were actually interested in such a project.
One of the best parts of the Expo was getting to see all the great talks given by various people from different backgrounds. Zigbee had sent a guy to the Expo to explained what they were doing with their new products and how to use their products. There was a talk given by an animatronics expert who talked about his projects and movies that he had worked on. Some of the other presenters showed off personal projects from RFID readers to teaching high school students about robotics.
Even though our goal of gaining sponsors for our project was not met, I feel that not all was lost and that people will hopefully spread the word on what we are doing so that interest is gained.

Code Performance Estimation

In the past few weeks we have made a significant amount of progress towards our goal. I've finished up all of the mathematics, and most of the software design architecture. Luke has been working on a different portion of the project, and I'm sure he will post up here soon about that.

For our software, the critical portion is the main control loop that keeps the quadrotor flying at the desired attitude (roll, pitch, yaw) and altitude. It is essential that this control loop operates fast enough to respond to disturbances. From my research into what other quadrotor groups have done I have found that 50Hz to 75Hz is sufficient for flying. So for our project we need to analyze our system and determine if we can achieve the desired rate.

The first component to consider is the inertial measurement unit (IMU). The IMU that we have selected is the CHR-UM6-LT IMU. From the datasheet, it can output at up to 300 Hz. On the output we have the ESCs that control the motors. These expect a control pulse every 20ms, so that is on update rate of 50Hz. Most stock components can run with a slightly faster update rate, and we can select ESCs that are designed for a faster rate. In any case, we have guarenteed support for 50Hz updates with the hardware we have.

Now we need to consider the software control loop. I've broken the math into three blocks: attitude control, altitude control, and motor control. The attitude control block and altitude control block can be done in parallel, and their output fed into the motor control block. Luke and I will be writing the code in Propeller Assembly using the Float32 floating point library.

The Float32 documentation includes timings and space requirements for each of the mathematical functions. If we count the operations required for each block we can then calculate an estimate of running time and space.

First, we have to count up all of the operations so we know how much math we have to do:

	Quantity	+	-	*	/	cos	sin	asin	acos	atan2	sqrt	quat*	Sum
	Moment	1	6	20	11	3	4	0	2	2	0	3	52	ops
	Altitude	3	1	4	1	0	0	0	0	0	0	2	11	ops
	Motor Speed	14	10	18	10	0	0	0	0	0	4	0	56	ops
	Sum	18	17	42	22	3	4	0	2	2	4	5	119	ops

Our control loop has 119 mathematical operations. The number sounds small, but it is slightly misleading. In the next table we see that the time to execute an addition or multiplication is much less than it is to calculate arcsin or arccos. For quaternion multiplication we assume that one multiply has 6 floating point additions, 6 floating point subtractions, and 16 floating point multiplies. This follows from the quaternion multiplication formula. In summary, since we have the number of each operation, we can calculate the total times:

	100 MHz	+	-	*	/	cos	sin	asin	acos	atan2	sqrt	quat*	Sum
	Time (uS)	4	4	8	11	78	75	261	265	117	174	225
	Moment	4	23	168	116	234	298	0	531	234	0	675	2283	uS	438	Hz	2283	uS
	Altitude	11	4	34	11	0	0	0	0	0	0	450	509	uS	1964	Hz		uS
	Motor Speed	53	38	151	106	0	0	0	0	0	694	0	1042	uS	959	Hz	1042	uS
	Sum	68	65	353	232	234	298	0	531	234	694	1125	3835	uS	261	Hz	3326	300	Hz
														w/o Parallel			w/ Parallel

Our estimates show that we can have an inner control loop of 260Hz, and if we parallelize the moment and altitude calculations then we can get about 40Hz faster. Also of interest is that the quadrotor control loop has a response time of 3.3milliseconds. For reference, the average human reaction time is roughly 200milliseconds (source).

Finally, we are interested in code size. The floating point library has a number of required support functions that do things such as convert to and from floating point, compare floats, and so on that require space. We also assume that 4 longs on average are used to setup each operation. This gives us:

	(w/ 4 extra)	+	-	*	/	cos	sin	asin	acos	atan2	sqrt	quat*	Float	Trunc	Cmp	Pack	Upck	Extra
	Size(longs)	24	6	18	19	2	45	36	5	25	28	15	13	17	22	25	42	30		Ops + Support
	Moment	28	30	98	63	14	61	0	49	33	0	27	13	17	22	25	42	30		552
	Altitude	36	10	34	23	0	0	0	0	0	0	23	13	17	22	25	42	30		275
	Motor Speed	80	46	90	59	0	0	0	0	0	44	0	13	17	22	25	42	30		468
	Sum	96	74	186	107	14	61	36	13	33	44	35	13	17	22	25	42	30	848	1295
																			Sum w/o dup.

So, if we were to do each instruction in sequence then it would take approximately 850 longs. Unfortunately, a Propeller cog only has enough memory for 496 longs. If we break it into sections then the altitude and motor calculations will fit into a single cog, but the moment block is too big. Some optimizations will probably be able to reduce the size to fit.

All in all, the code performance estimates are looking very promising. We should be able to achieve 100Hz update rates without too much trouble. The actual programming is unlikely to pose a challenge since we have the equations laid out in the exact order necessary for implementation.

Many have been asking if we are flying yet. No, sorry, we are not. Both Luke and I have been working full time on this, but there are many details to be concerned about. We are getting closer though. In the next week I plan on working on the thrust/torque test stand, and once that is done I'll start programming the control loops and the like.

The current version of the tables in this post can be found at this link.

First Board Populated

So what have we accomplished today... As you can see the board has been fully populated, no real problems or overlooks were found while putting the board together.

One thing that was not ordered was the 73.2K ohm resistors for the current sensing, so for this version of the board we have 100K ohm resistors.

Some changes that will have to come from REV A are

• The spacing between the battery input and ESC1 are way to close together.
• The spacing between R44 and R45 are also to close.
• Better silkscreen to determine which way Capacitors and LEDs are supposed to face.

Here are some more photos of the finished board.