标签: avionics

When it came time to select my senior design project it seemed fitting to do something along the lines of avionics since I had been working as a software engineer at an avionics manufacturer for four years. So I chose to design a rocket avionics card that would monitor flight characteristics, deploy two parachutes at the proper time, and help you find the rocket once it returned to the ground. Once the design was done and made it through the standard review process design by my professor, it was time to build and test the system. Due to the usual issues associated with supply chains I was already well behind schedule by the time the parts arrived and I began assembling the hardware. It basically came down to having 48 hours to assemble the circuit, test the software that I had mostly completed but never tested, and package the system into a payload bay for a high powered rocket launch. Since the launch event was coordinated with a local amateur rocketry club and the next event was well after my project due date, I could not miss the deadline or I would not be graduating that year. Needless to say, the phrase "failure is not an option" was forefront in my mind over that 48 hour period! Once I had the circuit assembled and had the USB communication link between it and my computer, I thought the rest was going to be smooth sailing. Any engineer reading this is probably laughing hysterically at this point since "smooth sailing" prior to an upcoming deadline is a fantasy held only by overly optimistic junior engineers. With only a day left, I began working the bugs out of my code and got the various features of the device working. After a short time I could save data from the pressure sensor and accelerometer to the EEPROM and dump that data over the USB port to the PC and I could manually force the electrical outputs that were designed to ignite the parachute deployment charges to cycle on and off. Everything seemed to be working great so off I went to the university's physics department to use the pressure chamber to test my system. Upon arriving at the pressure chamber I learned that it had broken the day before and it was the only chamber on campus. I now had no way to test if my algorithms to convert the sensor data through the ADC inputs were correct. If they were wrong then the parachute charges would be ignited at the wrong time which would present a serious safety threat to launch attendees. If I could not find a way to test the system then I would not be able to launch it and graduate the following month. So I did what any smart engineer would do at this point; ask an even smarter engineer for their advice. In this specific case, I drove over to my parents' house and consulted with my dad who was designing circuits long before I was even born. We needed to find or create a pressure chamber of some sort that would fit my circuit card and test it from ground level up to at least 20,000 feet ASL (which, in Central Florida, also happens to be 20,000 feet AGL). While we were sitting at the table brainstorming ideas my mom was working on canning (i.e. jarring) tomatoes from the recent harvest of their garden. Tomatoes... Jarring... Glass Jars... Eureka! With only 10 hours left before I had to be at the launch event we began hacking together a pressure chamber using two glass masonry jars, a few valves, and an automotive vacuum pump. One jar was the reservoir and the other held the avionics card. A little bit of physics and math determined the algorithm used to find the pressure needed in the reservoir to equalize with the other jar that represented a specific altitude. Thus, using the pump and valve system, we were able to simulate a rocket's accent and decent by creating a vacuum in the jar with the circuit card and then equalizing it with the normal atmospheric air around it. Using this hacked together pressure chamber I found a few bugs in my algorithm and was able to fix them prior to the launch event. After a successful flight and a few weeks of documentation writing, I presented my design along with the masonry jar pressure chamber to the senior design judges at the university's showcase event. A few of the judges were actual rocket scientists from NASA and they really enjoyed the story behind the pressure chamber. In the end, my project won the Best in Show award in the Computer Engineering category and it was all thanks to a jar full of tomatoes. - Terry Reinert Terry Reinert is a software engineer, karate instructor, and amateur photographer residing in Central Florida.

Many years ago, I was able to snag a win in the regional Science Fair with a project designed to automatically drive a car. In retrospect it was a ludicrously incapable system, but the judges were kind. Computers weren't available to high school students, so my design used hundreds of RTL ICs spread over many vector boards to handle the control requirements. It never really worked well even in the simulated tests I ran, but was a lot of fun to build. Over forty years on and now Google and others want to populate our roads, the air, and the sea with self-driving vehicles. Be afraid. But first, I do think that eventually we will come up with incredibly reliable autonomous vehicles of all sorts. My concern is the transition period, that time when smart cars have to deal with zany human drivers. And the time when the systems' bugs are still being worked out. While it's pretty hard to imagine a computer performing worse than those tailgating, texting psychopaths who now do everything in their power to make the roads as dangerous as possible, humans are wonderfully capable at dealing with the unexpected. Computer systems, however, are notoriously fragile. In fact, they are fragile in a way never before seen. Most engineered structures bend before they fail, or can be made robust by the addition of margin. Software fails suddenly and unexpectedly. The good news is that there's a lot of work being done to understand and mitigate software's weaknesses. But the evidence suggests that unless there's a very concerted effort made – at great expense – failure will be the norm. Consider avionics. Avionics failures are managed via triply-redundant systems. How much will that drive up the cost of a car? Then there's the engineering costs. Agonizing development approaches mediated by regulatory requirements help create systems that work as expected. DO-178B (now C) for software and DO-254 for hardware have been brilliantly successful. But to my knowledge Google et al don't make use of these standards. One wonders what assurances they can offer that their designs will be correct and reliable. Companies are petitioning the FAA to open the airspace to drones. Drones don't have passengers, so generally don't get the engineering attention lavished on commercial airliners. But they do share the air with those hurtling tubes full of warm bodies, and we on the ground are probably not thrilled with the idea of absorbing some of a drone's kinetic energy if the software – and the aircraft – crashes. I think the same standards used in commercial aviation should be applied to unattended aircraft. The irony of a self-driving automobile is that they will probably be required to obey traffic laws. Will shoppers cough up for a car that can only do 55 in a 55 MPH zone? Or will the dashboard have a control that varies behavior from "grandma going to church" to "sociopath on PCP?"