There’s been a bit of a hiatus in the blogging, what with CDIO, flight tests, and Spring Break. Getting back up to speed…

The sensor package – complete with a custom IMU for accelerations and angular rates, a horizon sensor for absolute roll and pitch angles, an EagleTree system for RC pilot input/airspeed/temperature, a flow meter for fuel consumption, and of course the CUPIC for GPS and deployment control – was completed on time for a flight test scheduled for March 15.

After some 6 weeks of wrestling with the PCB design of the deployment control boards, Matt and Michael finally nailed it down and got a big discount from Advanced Circuits on the printing costs. All 4 boards were populated, tested, and integrated with the rest of the sensor package and CDH system in a continuous 25-hour work session that spanned from the morning of Saturday the 14th to the flight test at 7am on Sunday the 15th. Deployment was given a “go” for the flight test, as the deployment system and its manual override control system were successful in testing.

Bad weather cancelled the flight test. Life is tough.

Everyone continued on into the week without taking a moment to stop to rest. The CDIO folks were in town all week, and MADS showcased the project along with the other teams.

Given that the sensor package and the deployment system were “go” for in-flight deployment, Travis scheduled up another flight test on Wednesday the 18th, just 3 days after the previous one was cancelled. Late-night CDH tests, however, were proving difficult. For a then-unknown reason, the Ground Station was dropping 95% of the packets coming from the SV and PV CUPICs. Despite the problems, deployment was again given a “go.”

The team hunkered down and got out to the airfield. Upon startup of the CDH systems, Michael discovered the problem to the packet dropping: A dynamic memory allocation process was eating up the CPU’s power and resources. The problem was fixed within minutes and <1% packet dropping was achieved. All 4 SVs were loaded, the sensor package was calibrated, and the pilot was itching to fly. At about 10:30am, after a few “warm-up” flights, the all four SVs were loaded onto the PV. With wind gusts upwards of 15mph, the pilot took the system to the nominal deployment ground speed of about 15 m/s and the command was sent to deploy the first SV…

Results were mixed. Across multiple flight tests, there were 2 SUCCESSFUL deployments and 2 FAILED deployments. The failed deployments were traced back to damaged actuators, as the CDH system telemetry confirmed that the commands were sent and received correctly, and that the polarity control of the actuators was active. However, the two nominal mechanisms behaved exactly as expected, and the proof of in-flight deployment was demonstrated. Four major important pieces of information were learned from this flight test:

1.) Perhaps most importantly, despite the high airspeeds and possible high angles of attack during deployment, the SVs deployed and behaved as close to the predictions from the drop model as we could tell. They dropped straight away, nose down, and crashed as “dummies” into the ground (~50m down). PV strike is low-risk.
2.) All data collection was successful except for the flow meter, which is experiencing noise issues. Furthermore, the post-flight CUPIC data analysis procedure was given a 7500% percent time improvement… the lesson: Don’t use MATLAB’s “xlsread” routine in a script running from a flashdrive. 10-minute flights that previously took 1.5 hours to process now take about 1 minute to process.
3.) The CDH and telemetry system were working with complete success, despite the damaged actuators.
4.) The system is controllable by the pilot with moderate control input, as the PowerFLOW modeling predicted.

Moving ahead, MADS has several big milestones. First and foremost is an attempt to either obtain new actuators or to redesign the deployment mechanism. The former option is not desirable because the system has already gone through more than six or seven of these actuators without improved results; team discussions led to the conclusion that the rushed decision to go with these actuators last semester was not well thought out. The latter option is also not desirable given the small two-week time span between the beginning of the final stretch of class and Spring Final Review. Reliability of the deployment system is indeed the project goal, and it appears there is the possibility of failure on this front.

The other major components that may seen changes are the software design elements. A stretch goal for MADS was to stream all SV CUPIC data packets through the PV CUPIC, and this appears to be quite easy and possible. However, the lack of time is a killer, as usual. It is unlikely that this system data flow will be implemented. There is also a “secondary” SV flight control system that has been tested and prepared for flight, but it also may suffer the consequences of lack of time. Finally, the damage to the deployment mechanisms has caused a lack of potentiometer data, which is used to activate the autonomous deployment sequence for the CUPIC-controlled SV. The deployments mentioned above were achieved with a “force” deploy sequence specially written as a safety precaution for failed potentiometers. The “autonomous” or “safe” deploy command sequences have seen successful ground testing but have yet to be tested in flight.

Again, Spring Final Review is coming along. The results and data analysis are mostly complete, but the team is lacking a coherent collection of it all. The Spring Final Report is in the same situation as SFR – the stuff to put together is all there, but it just isn’t together at the moment. The AIAA paper is also in the works and should be done with plenty of time to spare before the due date this coming Friday, April 3.

The weather is looking good for next weekend, and MADS plans several early-morning flights to retest and recollect data.

Posted by Matt Lenda