Okay folks, new here to the forum. We are developing a full-scale aircraft, but are currently constructing a 1:6 scale proof of concept prototype to validate some predictions under dynamic scale conditions. What we want to do is add instrumentation to capture flight data, and it looks as if a flight controller-based system might be the answer.
We want to capture the following data:
-Roll-Pitch-Yaw attitude & movement rates
-Airspeed and Pressure Altitude (Temperature would be a bonus)
-Yaw & Pitch sensing (for angle of attack/sideslip during critical maneuvers)
-Flight Control Surface Position
-GPS Position
-Power Demand (ie voltage or RPM, whichever is easier to do)
-Possible Video Camera tie-in
With respect to the model, there is nothing out of the ordinary about it; 1x canard elevator, 2x ailerons, 2x rudders, 1x throttle, 1x nosewheel steering. Fixed landing gear, no flaps, borderline large scale.
We must reiterate that we do not need control assist or augmentation…just data capture, but would be open to augmentation investigations later. Additionally, we do not require any real-time video or data downlink. All we are trying to do is capture data from specific dynamically-scaled flight conditions in order to validate predictions & inform engineering decisions for the full-scale design.
So the big starting questions are the following:
Does a data acquisition solution that does not break the bank exist here?
If so, how do we go about this?
What kind of hardware do we need?
We have done RC models before, but our radio system is not telemetry-capable…does it necessarily need to be? With respect to telemetry, we do not necessarily have a need for real-time monitoring…
The ESC we have on hand to use for this aircraft is a Castle Creations Talon 90…is this compatible with any Flight Controller-type system?
Can Flight Review be used offline, and can it be used to lay all this data out for reduction & analysis… a la IADS, Octave, Excel or MatLab? If not, are there any other applications that can be used?
So far, researching the whole flight controller/ArduPilot world, we have not gotten the same answer twice (or an informed/mature answer for that matter), and as such, are no further along the path of instrumentation than when we started.
Any informed feedback is highly desired. Thank you all in advance, and we look forward to hearing from you all!
But one important thing up-front: All technology intended for hobby use - as in PX4 and Ardupilot - is created for UN-manned aircraft use only. Whilst I understand you just want to record relevant data, it is up to you to implement & use such data in a responsible and professional way which doesn’t result in causing harm to lives in a full scale application.
To your questions:
What do you consider
?
There are real low cost solutions available as in less than $200.- but the quality of data may not be in line with your expectations. Some better options here:
You buy the various parts & sensors and install as per instructions available online.
→ If you get stuck you can ask one of us more experienced operators for help.
See link provided under point 1. Basic guide: Flight-Controller + Power Monitor + GPS
Don’t need telemetry. Just activate FC (Flight-Controller) and all data will be recorded to SD card. (provided you use correct settings and a FC with integrated SD)
Any ESC which uses standard RC PWM signal is suitable.
Yes,yes and yes. In fact there is so much data available your head will spin trying to get to learn and know about everything.
Here is an example of a flight log analyses system online you can try to get some insights (use Sample provided) UAV Log Viewer
Thank you much for the reply. We should have placed that disclaimer of yours up front on the OP as well…thanks!
With respect to the cost question, the previous forum in which we solicited proposed outrageous solutions in the thousands of dollars, so it is good to know that there are practical alternatives. Looking at that Holybro site, it looks like it possesses the data collection answers we seek…thank you!
Dumb question; with respect to the ESC question, looking at Castle Creations site, we cannot see anything mentioning PWM…we assume you are simply referring to the signal it receives from the receiver?
We are certain we will ask more as we get close to test. Better yet, we’ll post any & all lessons learned on our end, so that others may learn!
Yes, in this particular instance I am referring to the signal provided by the receiver.
Note on the side: PWM is a broad term in regards to type of signal being used. In fact there are various industrial applications where such signal is being used. However, people from a non-technical background can be misled and assume it all is the same whilst this is in fact not the case. The hobby RC signal is one particular type of PWM and as such not compatible with that found in industrial equipment.
Awesome…just wanted to make sure we were on the same sheet of music.
Next dumb question; we have an opportunity to locally acquire a Pixhawk 4, but just found out that Holybro has discontinued it…but is still supported. We are liking to think that if we went ahead and got it, that we still should be good to go for what we are doing, especially if it is still supported… true statement?
Also, has anyone in this community tried doing a pitch & yaw sensing solution that you know of? We know there are some mini rotary potentiometers out there ( 3382.pdf (922.6 KB)
; (this attachment is one of many mini’s out there) printing out some mounts & vanes will not be much of an issue…but we are genuinely curious of others have tried it. It would be awesome to co-locate these on the airspeed probe to have a fully-functional “mini-YAPS”; we’re even validating a potential shape of it against the aircraft in the CFD environment… minimal distruption, given the aircraft configuration and relatively low Re environment.
Again, thank you so much for your help so far; this is seemingly not anywhere near as complex as we were initially led to believe…just small details at this point!
Yes, often certain Flight-Controllers become outdated but can still be used after. - As long as you don’t use one that’s outdated by many years as you will struggle to find anyone who is willing to help you with certain issues that may arise.
You don’t need any additional sensing solutions. - Yaw,pitch,roll, air-pressure (height) is all taken care of by one FC.
However, in regards to speed and fixed wing aircraft you have to decide if you want to use GPS, Pitot-Tube or both.
That’s why it is unlikely anyone would bother with additional sensors like you propose as those don’t readily integrate with FC-system and add more complexity to build.
We fully understand the module provides spatial 3-axis information, angular acceleration data, baro altitude, etc, all of which all holds super-high value for us, and airspeed & GPS data is an absolute must. However, knowing angle of attack & angle of sideslip in specific regimes are both important in the world of aeromechanics, so yes, capturing these two parameters is highly, highly desired. Yes, we know what this model should do, but the whole idea is to validate predictions and assess flying qualities under dynamically scaled conditions.
On a previous similar subscale project some years ago, we used an old-school video camera-tuft-reference point technique that worked good enough to get an informed idea of angle of attack/sideslip, so we could do this if the Pixhawk simply does not have this capability. We had to ask…
What are the default sampling rates of the GPS, Airspeed sensor, Barometric Altimeter and Spatial sensors? Can the sampling rates be adjusted if need be? Knowing this and airspeed at any given moment, should give us a fairly decent AoA/AoS answer!
Just because it is not readily available as a data logging option doesn’t mean you can’t use those additional sensors. Various people done all sort of things in special builds/applications.
But that may involve custom made firmware for flight controller, or perhaps a companion computer to record extra data and combine it with Mavlink messages from FC.
Also this is where telemetry comes in handy as you can all or some data to a ground-station and record it there.
Here is an example of someone trying to do such thing:
Another example:
Sampling rates can be checked in the specs of your particular FC you intend to use.
(Lookup sensor chips used and then google for the specs of each chip)
In regards to GPS it depends if you use a low cost GPS which may provide only a 5Hz update rate or a quality GPS providing at least 20Hz update rate.
You can adjust sampling rates down I believe, but not up as this could cause a FC CPU overload.
Idea: If you don’t require voltage & current data from your battery you could simply use a potentiometer as you’ve suggested and wire it as part of a voltage divider. Then that voltage can be connected to the battery sensing ports. All you need to do is create some reference values before so you know which voltage represents which angle.
Or some FC’s have already analog sensing inputs which can be used to record that voltage.
In all above mentioned cases you have to ensure you stay below 5V or in some cases 3.3V for those sensing applications. - Best thing: No additional equipment required. (I.e. companion computer, telemetry,…)
We were thinking the same thing! Turns out one of the kids working at a local hobby shop is a Arduino / ArduPilot wizard and mentioned the exact same thing!
In any case, it is really good to know we have plenty of data capture options on the table; the more we read into this equipment, the more impressed we are. Our test pilot found a technical paper that chronicled a project where a Pixhawk controller was used to gather data…on a full-scale aircraft! We could not use something like this on our full-scale design- way too many parameters than a Pixhawk can handle, but impressive nonetheless.
