September 8, 2004

• Next Flight
  • Date: Backup:
    • Actuator is installed
    • Plan to test gimbal and camera sweeping
  • Civil Air Patrol will be involved, we'll demo to them. Sort of a "workflow" demo; even though the ADP isn't there, they'll get an idea of how things move, quick turnaround times, processing. Also, a good exercise for us to try and do it all manually.

• Meetings remain at existing times
  • WASP team meetings will remain at Wednesday 1pm
  • Leica telecons will remain at Wed 2pm

• ADP should have its first objects on the 'net by the weekend
  • Dan will be contributing a short doc explaining his experience with using the Leica code
  • Jason will start making decisions with control and other s/w mechanisms soon (already started on the wiki).
  • Harvey expects Jason to assemble test plan of some kind.

• 9am Tuesday: ADP workshop
  • review interfaces, data movement through system
  • who delivers what and when

• Boresight
  • Overall, seems acceptable
  • Worry: If we're flipping values and they "come close", that may be okay, but Don's concerned about why we have to flip the parameters.

August 11, 2004

• Controlled burn flights
  • Early September, maybe?
  • Going to "play it by ear"

• Boresight analysis
  • Don Light received from Dan the 3 IR models, still need the VIS
  • The current model is progressing well but definitely not "final"
  • Work continues... (good progress)

• Actuator is back
  • On campus "somewhere"
  • Receiving can't tell us where; not in the bin, not on the truck

• Dan's giving a talk on the work he's been doing
  • 9:30am at CIMS
  • Undergraduate research symposium

• ADP
  • Jerry has the Leica parts building correctly now (is now a simple "download and build)
  • Jerry and Dan will start integrating it into Dan's test harness

July 7, 2004

• Stuff to review:
  • Fire detection algorithm
  • Applanix server
  • Boresight

• Camera Alignment (Don Light)
  • Cameras need a setback of 16 feet, focused to infinity
  • Resulting Field of View: SWIR 8x10.6, MWIR 6.5x5.1, LWIR 10x8 feet
  • GSD SWIR 2mm, MWIR 5mm, LWIR 5mm
  • 5mm is a pretty good sized string to heat up!
  • Harvey wondered about the 2→5 step-up in size. Cameras have roughly the same field of view, so this is odd.

• Fire Algorithm (Sam)
  • Two versions of the program are running, verified against Ying Li's results
    • Except for the image boundary
  • Code is based on float calculations
  • Incorporates the use of templates to act on different types of data, such as short
  • Harvey requested some rough timing measurements
  • Overall, things are coming along prety well
  • Bob will send Sam information so he can upload his code to a page on the wiki

• I stepped out of the room, missed one conversation here. I think it was boresighting.

• Discussion about Applanix server query object thingy.
  • Bob got the initial design information out in WaspApplanixObject.
  • Scott has enough information to start working on it.
  • Next week, Scott should be parsing the Applanix data stream, handling occasional partial data records. CORBA work is deferred until after this.
  • Major feedback on design so far: Jason points out that IMU data, and maybe location data, is per sensor. I had assumed it was common to the plane, but that's naïve.

• Data inputs to Leica
  • Anything pending still? Doesn't sound like it.
  • "Unified" DEM. That is, a single DEM that covers everything we might fly over. Well understood problem, easy to generate.
  • We hand it to Leica in memory, not as a file.

July 1, 2004

• Sam is ready to start implementation of the fire detection algorithm.
  • Input is three pointers to image arrays.
  • Output is an array of reals, indicating some kind of fire probabilities.
  • Algorithm will not do memory management.
  • Algo will work in floats, not scaled integers. We'll worry about performance later.
    • Bob is worried that the conversion of u16→double of three frames every time is going to be slow.
    • Bob advocates scaled integer math, avoiding reals when possible.
    • Harvey notes that scaled math is more difficult than plan math with reals.
    • Sam says he expects to write about a couple hundred lines of code. This is small enough that we can do floats "now", and scaled integers "later".
    • Harvey points out that Sam could inline cast the expressions.
    • Bob warns that casting sometimes has adverse effects if you aren't careful.
  • Performance evaluation and code review comes later; the priority right now should be on the accuracy and correctness of the floating point version of the algorithm.

• Applanix discussion.
  • Goal is to extract information from Applanix stream (Ω Φ Κ, location, and time), manage it internally, and make it available to the rest of the system.
  • Ω Φ and Κ are not the same as plane roll, pitch, and yaw. Bob recalls it's a difference in the reference frame, but doesn't remember enough to convert. Don Light probably knows this.
  • Bob will ask Leica if they've defined EOParams and such yet, even though IRSM and friends aren't done yet.
  • Version 0: Doesn't interpolate or do any special computations at all. Plane will appear to move discretely, not continuously. Just maintains previous information until next update from Applanix. Info products are time, orientation, and location.
  • Version 1: Comes later, when someone wants to attack the problem and derive intermediate IMU and GPS data.

June 28, 2004

• DonMcKeown says we'll be trying another WASP flight tonight or tomorrow night. Previous flight was cancelled because it would have flown too low and violated airport noise abatement regulations.

• Actuator was sent out for repair.

• JasonFaulring notes that one of the existing WASP disk drives is starting to fail. Causes boot time failures intermittently. Going to replace.

• Conversation with Joel Hutton re: boresighting. Applanix will get us a proposal to do the analysis, performing a full end-to-end procedure as well as a "how they did it" so we can do it next time. Estimated about US$5000.

• DonLight^? presented an approach to correcting the thermal IR camera's possible internal alignment problems. Basically, it's a method to verify the calibrations we purchase from Pictometry. Notes were distributed. The goal is something simple and repeatable; even if it doesn't yield perfect accuracy, if it's stable from flight to flight, then we can use it to look for changes between flights.

• Sam was wondering about the development environment on vulcan.

• Bob promised that an initial rev of the design of the ADP should be completed this week. Implementation starts late this week; the goal isn't to build the final system, but to create the framework to host the Leica software.

• Leica telecon moves this week to 1pm Thursday. Software meeting moves to Thursday 11am.

• Don said that Applanix will have realtime POSPAC software at the end of the year, but nothing beforehand. We'll not wait for them, but Harvey wonders if we should plan on dropping in their program later in ADP; but we shouldn't go to great lengths.

• Bob needs to see JimBodie to make sure that palin, booth, and cleveland get JumpStarted^?.

June 23, 2004

• DonMcKeown wants JasonFaulring and BobKrzaczek to maintain a diagram that indicates hardware relationships (network, serial, whatever) between components in WASP. Jason thinks he can kick this off with a Visio drawing that Bob Kremens had a while back.

• HarveyRhody wants JasonFaulring and BobKrzaczek to start developing a Applanix design/architecture/framework to support development of the algorithms to process its data stream. We believe, at this point, we'll go forward with a query server in WASP.

• JasonFaulring presented his new understanding of how the Applanix processes and presents its data.
  • Generates data samples at 50Hz; can be turned up to 200Hz (but would probably bury whatever data channel is in use).
  • Can write to a serial (RS-485) or network stream, but not both. Network stream is implemented as a TCP server, supporting only a single client at a time.
  • Group 1 records are generated at the sampling rate (50Hz)
  • Group 4 records are generated between the Group 1 records, providing data from accelerometers. Their timing is not exact but "sprinkled in" among the Group 1 records.
  • External (triggered) events are timestamped exactly by the Applanix, but their record might not appear immediately in the data stream. Jason thinks one second is a safe upper limit to the skew.
  • We would need, either to write or use Applanix s/w, to do some rudimentary interpolation or curve-fitting on the IMU data. Adapt this to a realtime system.

• DonMcKeown will ask Applanix if they have a realtime POSPAC software product.

• ScottLawrence will look at picking up the Applanix query server.

• Dan Fava's appointment at Leica is up at the end of July. HarveyRhody names a list of things we're all working on, what of these tasks could Dan help with, given his current placement?
  • Bore sight problem
  • Need to extract information from IMU
  • Write a workable fire detection algorithm
  • Need a system to put algorithm into
  • What is this thing going to produce
  • A database to run this thing as a simulated system

• System administrators noticed 72 GB new data since late May. They wanted to know if that was right; Jason says it does.

June 14, 2004

• ScottLawrence will be on a WASP flight soon.

• Kodak has asked us to do a WASP collect for them; MikeRichardson^? coordinating.

• Jangho generated a bunch of potential boresight alignment solutions; DonLight^? complimented the work highly, thinks there are two sets of alignments that may work.

• DonLight^? described a way of visually evaluating boresight calibrations that gives you more information and confidence than a single set of simple statistics.

• Discussion about other approaches to boresight alignment. A follow-on meeting will continue this discussion.

• MikeRichardson^? will follow up with Pano to try and get further support from Pixel Physics. Maybe we should just hire an Applanix engineer for a couple days? Would need to make sure we have all information and data prepared ahead of time.

• WASP "electronic footlocker" contents
  • USGS 30m DEM (for use by Leica as well)
  • Camera calibrations (for use by Leica as well)
  • Topo maps

• DonMcKeown suggests we may have a single mosaic of all DEM, then give Leica slices of it as necessary.

• June 23, 2004, Use Case Walkthrough (9:30am), led by MikeRichardson^? and DonMcKeown

June 9, 2004

• HarveyRhody wants us to start on data management for the raw data we've been taking so far. The tree in titan:/dcs/data is apparently getting a little unmanageable.

• BobKrzaczek asks what are some useful criteria for sorting or indexing WASP data as it arrives?
  • date
  • flight (a string of some kind)
  • raw files (presumably, WASP's names will indicate something)
  • Latitude/Longitude of some "overall" target
  • Latitude/Longitude of each image (post processing)

• Applanix has some proprietary utility for creating GPS and other data files.
  • How do we run this in the plane? In the ADP? While we're doing other things?
  • Can we understand the Applanix data stream? Or do we need their program?
  • Raw files captured in-flight don't "appear" to be real.

• Friday, 1:30pm, design meeting

June 2, 2004

• Upcoming collect possible, as early as Friday, 6/4

• Don wants to re-fly the campus.
  • for geographic calibration
  • has to be "dead on"
  • big flight, lots of data, Jangho will do the processing

• New build environments on vulcan, Cygwin and MinGW
  • good build of ACE and TAO under MinGW
  • completed benchmarking, interesting results
  • reviewed s/w from Leica but haven't responded, will asap
  • adjust design to reflect
    • need to eval our "scaled down" terrapix
    • or consider abandoning distributed design
  • Questions
    • ICC? MSVC? Where the heck? GCC is okay, but not great
    • multi cpu? Do Windows guys like Jason or Jangho know anything special about taking advantage of it?
  • SOFIA travel June 24 ish, 24-25

• H/W power inverters
  • most have 8 week lead time
  • some are under 4 weeks, approx US$700

• Instead of CORBA on all components, we could combine processing algorithms together into "mini-monoliths".

• Tentative Schedule
  • Some sort of Test Bench by end of month
  • 1 week, finish benchmarking
  • MikeRichardson^? wants a date set on the design
  • Implementing should start week of 6/14 if we're going to have any chance of having something by end of month.
  • Design Doc done in meeting, generated as team 6/11 1:30pm EST