In catching up on my reading of the Armadillo Aerospace blog, I noticed a point about their new pressure transducer. It allows them to get data in a simple and reliable way. It might be a good idea to take a look at how we gather data off the test stand and implement a similar approach there.
Similarly, a recent blog post on Masten Space Systems talked about improving the lag time on their controllers and how important it turned out to be to have 12 or 16 bit A/D converters and a direct-drive H-bridge. I had to admit that I no longer remember what our A/D box runs or how it connects. This all needs dusting off. I’ll copy the relevent part of the MSS text after the break.
The ikalogic.com site nas an interesting article on Motor Control.
it’s clear that if we can learn from other’s experience and not repeat known problems we can save both time and money (and maybe member frustration and burnout too).
The article mentions Bergmans Mechatronics, who built the DACS for the Falcon Horizontal Test Stand. Admittedly a LOX/Propane engine is more complicated and requires more data controls than we do, but it’s an interesting panel.
This text is pinched from the bottom of Masten Space Systems’ May 2008 Update:
I ended up getting into a little bit of an argument with John Carmack (who BTW is a great guy, and has been very helpful over the years to what weÃƒÂ¢Ã¢â€šÂ¬Ã¢â€žÂ¢ve been trying to do here at MSS) about whether he would be able to fly their 4-pack MOD design with differential throttling only. During the argument, it came out that John thought his dynamic throttling was reacting much faster than ours was, and he agreed to log some data at some point in the future to prove it. True to his word, he did. What the data showed was that his valves were moving within 5ms of being commanded, and the chamber pressure was starting to rise within 50ms. Within 100ms the throttle change was mostly done. At about the same time as this, I had looked up the KZCO valves John was using, and one of the illustrations showed the actuator driving his valves looked like it is probably the same brush DC gearmotor we are using. Armed with all of this data, we realized that we had probably misunderstood where the valve motion lag was coming from, so we took a couple of days, and hooked up a bunch of data acquisition (with the help of our friend John Bergmans of Bergmans Mechatronics). What we found was that the valve controller boards we were using operated differently from the way I had thought, and had lots of inherent lag in them. When we totalled up all the different lags, we realized that if we had a direct-drive H-bridge type system, that we could probably get similar response times to what John is getting (which shouldnÃƒÂ¢Ã¢â€šÂ¬Ã¢â€žÂ¢t be too surprising as thatÃƒÂ¢Ã¢â€šÂ¬Ã¢â€žÂ¢s more or less what Armadillo does). We decided to do a quick proof of concept test with some off-the-shelf H-bridges. While we were waiting for the H-bridges to arrive, Dave made a first pass at a simulator for the system, just to make sure he had some sort of intuition about what effects mattered. One of the things he found was that with the 8-bit AVR microcontrollers we were using previously, there was no way he could get such a closed loop system to work. The resolution was just so low that you tended to get a lot of overshoot. This was probably part of why we hadnÃƒÂ¢Ã¢â€šÂ¬Ã¢â€žÂ¢t gone with direct H-bridge control when we first investigated the idea over a year ago. Fortunately, at this point, since we were going to a much higher capability A/D setup with our new OFMS computer (all 12 and 16 bit), this was no longer a problem. WeÃƒÂ¢Ã¢â€šÂ¬Ã¢â€žÂ¢ve done a few more integration tests with the OFMS as the code has developed, and weÃƒÂ¢Ã¢â€šÂ¬Ã¢â€žÂ¢re now to the point where we should be able to test position servoing in the next few days. After weÃƒÂ¢Ã¢â€šÂ¬Ã¢â€žÂ¢ve got that debugged, weÃƒÂ¢Ã¢â€šÂ¬Ã¢â€žÂ¢ll have to wait for either the trailer or the vehicle to get far enough along for us to try out a couple of dynamic throttling algorithms in the real world, but we should at least be able to try a few things out on DaveÃƒÂ¢Ã¢â€šÂ¬Ã¢â€žÂ¢s Hardware-in-the-Loop simulator.
In addition to the valve lag, the stepper motor setup we had for the engine hinge was also showing quite a bit of lag. It took enough time for the ÃƒÂ¢Ã¢â€šÂ¬Ã…â€œaccelerationÃƒÂ¢Ã¢â€šÂ¬Ã‚Â circuitry to ramp up to enough force, that we were seeing fairly serious lags in this system too. After a bit of thinking, weÃƒÂ¢Ã¢â€šÂ¬Ã¢â€žÂ¢re also looking at swapping out our Ultramotion Digit actuators for slightly modified Bugs (modified to be the same length as the Digits so we can just swap them out directly). Bugs are Brush DC, so we can drive them with the same H-bridge setup weÃƒÂ¢Ã¢â€šÂ¬Ã¢â€žÂ¢ll be using for the valves. WeÃƒÂ¢Ã¢â€šÂ¬Ã¢â€žÂ¢ll also be able to use the same basic position servoing algorithms that Dave is working on now for the valves. By switching to direct H-bridge control, we may see as much as an order of magnitude lower lag on our hinge actuation, while possibly doubling the slew rate. With less lag and faster slew, it should make controls a lot easier and more linear. With the throttle valve upgrades, weÃƒÂ¢Ã¢â€šÂ¬Ã¢â€žÂ¢re also hoping to see response lags several times faster than what we have right now. Between these two changes, IÃƒÂ¢Ã¢â€šÂ¬Ã¢â€žÂ¢m a lot more confident in us having a robust TVC setup.