Definition of insanity: Doing the same thing over and over and expecting different results.
Clearly we don't think we are doping the same thing, but the results are really similar....
Drive 4 hours, camp, setup test, fly abort, break the vehicle, driver home 4 hours, fix vehicle, lather rinse repeat.
We should have the vehicle back together tonight. We have fabricated a new version of the the part in the gimbal mount we broke, but we still need to fabricate a brace so it won't break again.
We failed to record data on the last flight, so almost no useful information from the test.
(The error was a tired operator error, not a fundamental problem)
I've spent the morning changing software so data will be recorded automagically without any operator intervention, in 3 places, on the ground station PC, on the telemetry box, on an SD card in the vehicle, just to be redundant.
Looking at what data I do have, several things are clear.... proportionally it looks like the gimbal system needs a lot more differential correction than the vanes did.
The system seems to be a lot more sensitive to every thing being level to start with, the vane system just plain ignores tilts of up to 15 degrees, does not even cause a noticeable start up transient. This gimbal vehicle seems to want to start out with a large transient.
On a spherical vehicle its actually really hard to be sure that everything is lined up level.
The IMU is level, the motor is dead level vertically, but I'm sure I have a center of mass offset for the partially full fuel tank. Again the vanes vehicle just ignored the center of mass offset when flying with the permanganate tank.
I'm not a big believer in software only simulations, I like to build real world analogs and test those, this may change my mind. For a long time my todo list has had a hardware in the loop simulator on the list, ie simulate IMU and GPS inputs to the computer, measure the actual valve and motor positions and use these to run the simulation. This will probably be my winter project.
10 comments:
I agree totally with having hardware in the software testing cycle.
Perhaps you can find someone who can give your control code a second set of eyes / sanity check. It always helps! Even if that means spoon-feeding someone your code functiom by function - how many times does doing that actually force you to review your own code and by doing so you find the problem and the other person is just a witness?
At work we call that wooden Indian debugging....
OK, so sometimes YOU get the flash of insight via "Wooden Indian debugging" but also sometimes the Wooden Indian sees what you have not been able to see. Forest and trees. Big pow-wow makem good wampum. (I'm part AmerInd so don't PC me).
In my experience, Debugging code is an art. You get a feel for the code and often intuition helps isolate the area that is the cause.
Obviously, your control code is very dynamic hence its more complex than the average business application code. Building a simulator my just be the ticket though time is running out for this season.
For the moment, explaining it to someone (your son?) might just might make aspects jump out and become obvious point for further investigation.
Good luck.
I've been looking to get some practical experience with controls software. I primarily develop CFD simulations, but if you'll allow me to be your wooden indian, I may be able to help you develop your hardware in the loop simulator. If I can be of any assistance, please let me know.
Don't go insane, don't give up, hang in there. You are the future...if I was your age again I would try to make these things fly. I could only make them fly in the movies.
Could the issue be force rather than control? I.e. better than assumed propulsion playing havoc with otherwise correct control code?
The gimballed engine is basically starting over from scratch. So you've gone from 4 engines to a vaned engine to a gimballed engine, mostly starting over each time.
You can see in some of our flight videos that on any given day every flight will take off in the same direction. That's an offset from the initial engine position.
Half a degree of offset will make the vehicle lift off in a noticeably not-straight-up direction.
The gimbal mounted engine will have a lot more rotational inertia than the jet vanes, so that rotating it one way will rotate the vehicle the other way even with zero thrust. Does that matter to your control code? (A torque term proportional to 'acceleration' of gimbal setting in addition to the thrust * moment term.)
Post a Comment