My ambition is to send APM aloft to the edge of space on the end of a balloon, and since it gets a little cold up there, I decided to take a look at what I would need to keep things running well.
NASA have kindly given the world a mathematical atmospheric model which shows that if I can meet the challenge at -56°C, I should be OK at any altitude. Here is the temperature of the atmosphere according to NASA:
So, having established a boundary condition, I fired up APM and measured the current draw at various voltages. My measurements showed me that APM will chew anywhere between 1.3W and 2.3W, from 5V through to the 7.2V that I will probably run it on using a 2S LiPo battery.
I then constructed a small EPS enclosure model in SolidWorks and ran a simple thermal study with a boundary temeprature of -56°C and an internal heat power source of varying levels (see above). The EPS enclosure I modelled is a 10mm thick box and just large enough to fit a fully assembled APM1 with no accessories - obviously I will have to have some cable penetrations and a few other compromises in the final design, however the model suggests I can keep it comfortably above freezing with only 3.5W of power, 2.3W of which APM will generate of its own accord
.
To make this work, I will probably use a heater resistor powered by the relay that I can PWM to top-up the heat as necessary with a closed-loop controller using the on-board temperature sensor data for feedback. Obviously I will lose the OAT measurement, which will have to be subsituted by an externally mounted NTC thermistor.
So, now I have a first-pass heater power value for my mission power budgeting. I will refine and optimise this as I progress with the design of the electronics installation on HDwing.
Onward and upward (eventually!)
Comments
Earl
Good suggestions. Hopefully we haven't hijacked the tread too badly. I'm probably limited to the current state data on APM since I'm running out of time to utilize the A-D's. I was thinking to borrow one of the current logs and fit within the existing number and structure of bytes to stay compatible with planner. Andrew is on the right track with the simulation, but there’s a bunch of code and algorithms that are bypassed in the HIL configuration. Hopefully the combination of HIL and test like these will help point out the risks for APM HW/SW performance for “the next step”.
I’m hoping to get ambient pressure and temperature into a log + combine other parameters from several logs (part of your list). Still struggling a bit and it would be good to know what I need to do to have the temperature variable available in “log.pde ”. I think temp/press are computed at the bottom of “void AP_Baro_BMP085::Calculate()”. Obviously I’m not a C++ guy. Bet this is a trivial thing for someone on this forum.
The other thing is that APM comes up in FBWA mode in my configuration and is not trying to get to WP1. This isn’t an issue with my rcvr connected since Ch 8 set’s mode, I’m using Ch 7 to mission restart, and failsafe behavior supports staying in Auto. I can connect and change, but when I disconnect we reset and go back to FBWA. Again, I bet this is simple, but could use a pointer. Setting this up will allow visibility into some of the guidance output.
Past this flight it would be good to get sample code for A-D sampling and scaling, control of external devices on APM2 or relay functions on APM1. Sensor choices so that we can get some of the other things on your list, or control heaters, cut-away devices, instruments…
I’m also interested in how Earl is approaching the SW and test.
KA5HND-1; T is Albuquerque eclipse maximum – 1.5 hours (TBR).
We are launching ours on Tue 5/15/12 from Edgewood/Moriarty area at 8 am.
Earl
HAB-APM payload for next week's launch. These are basically the harnesses from my ill fated P-51. The root cause of that is a different discussion but setup and not APM related (in order: go fever, aft cg, control throws, weight, very fast servos. All logs nominal.).
This payload is going up during the anular eclipse next Sunday from Albuquerque so that pretty much says when. This should be trackable at Tracking.
APM is oriented as my HAB test would be. The plane nose is pointed down, GPS antenna is out the sidI'e. This acquires OK in the house so I'm assuming free flight should be better. Point is to acquire some log data. Todo is modify logging to get 2 hours of log data for important stuff. Of course pictures of dual APM launch, eclipse, real time video, Remzibi OSD data, tracking and recovery proceedures shakeout, launch proceedures shakeout, preflight proceedures shakeout, EPP foam materials ride along, are objectives.
Question for the group: What data is important? I'm thinking: phi, theta, PSI, heading, temp, pressure (expect this algorithm to fail), GPS data, APM hacks to waypoint (RTL or WP1?), ?. I'm open for suggestions, especially example code that produces data that's viewable in planner, way to get APM into proper mode to produce that data after init.
I have an earlier post where I've solved the 60k navigation issue. There are a few receivers that will work. I'm using a Venus GPS running 5 Hz NMEA data. My surrogate A/F is stock APM2 and the flight A/F will be APM2 minus GPS + Venus GPS. See post for integration. I'm also using a BigRedBee APRS with a Lassen IQ. I understand that the Lassen has a lower update rate, but have not verified or checked to see if the rate can be changed.
Andrew,
Great stuff above and sounds like you're making good progress. I also noticed the X-Plane issue with using TAS. Great to know that this has been fixed. IAS is directly related to QBAR and much more useful for scaling autopilot gains. Typically gains are scheduled with both Mach and QBAR. The former is true because XCP and control effectiveness vary significantly with Mach above 0.75 ‘ish. That's not to say that there might not be issues with local compressibility affecting both the aero and maybe IAS depending on the airframe.
I initially thought that I wanted to attempt to capture the A/F at low Qbar and work the gain scheduling problem pretty hard. However, I've decided to head off in a different direction utilizing a very stable airframe and drogue (commanded dual release system). I still don’t fully understand what APM is doing with scaling and you’ve provided the spot to look in the code. I think there’s also a forum thread on this topic by Doug. Another potential advantage of not turning on APM outputs before the A/F is "flying" could be a potential to saturate the sensors due to rates. Of course you have to think hard to find the forcing function.
I'll attach a handy spreadsheet that does a few flight envelope calculations, computes Mach number, desired turning radius, and has a few A/P and guidance design notes. This is very simple “motherhood” aero stuff, but helpful to understand what it takes to keep the A/F at an IAS where it wants to fly. The aero loading is obviously related to QBAR and we’re trying to keep that fairly constant (unless scheduled for guidance reasons). I’m like you and worried about dynamic divergence of wings and surfaces. I may balance the control surfaces. Flight Envelope
I'm working in X-Plane 9 as well and I'm also having stability issues above 40k ft or so for representative IAS. I don’t know if this is X-Plane or APM related. I could be both. X-Plane does have issues with small models though there is a frame rate setting that helps a little. In any event, the gain scaling problem needs to be solved.
I'm doing drops with a handy X-Plane plug-in that allows reset of the state vector. This might help speed things up a bit for simulation. Position Aircraft
Regards,
Larry
John,
I'm not trying to catch a jet stream, but it will play a big influence on the return-to-launch. It will go downwind during the ascent and it will need to go upwind during the descent, so in effect it will be fighting the jetstream. If it can reposition itself upstream during the high altitude sector, then it has a good chance of returning to the launch site.
Andrew, if you're up to catch a JetStream, why are you aiming for 120k feet, instead of 50k? I did also a check on your link on x-plane simulation, but missed the pressure data on the screen - you should double check there's a standard ISA atmosphere model implemented.
As for GPS restrictions - uBlox5/6 and SIRF-III (EM-406,407) are ok to use, but I wouldn't go for SIRF - they're bit more expensive, and 30% of them come with faulty antenna connections (at least those sold by sparkfun).
More regarding the COCOM GPS altitude limits. I found out here that the uBlox 6-based chipsets are rated to 50km and are available here relatively cheaply. I'd buy one from DIYDrones Store if someone there would kindly integrate this module into APM! (hint hint...)
BTW, the Mediatek 3329 that I have will not function over 18km according to the datasheet - this is the 10Hz one on offer at the DIYDrones Store. An earlier uBlox 5 that I have, may work, according to that previous link, however it is only 4Hz.
Monroe - more info coming soon, I promise!
-
1
-
2
-
3
-
4
of 4 Next