# MAV Study Focus Group Post



## MarkR (22 Jun 2005)

Good Morning

This is the online focus group discussion topic for a Micro Air Vehicle study (protocol #L-513).

FOR ALL ARMY.CA FORUM MEMBERS

The discussion about to be undertaken in this thread is a scientific experiment, subject to all the usual stipulations on control.  For focus groups, "control" translates to only those participating in the focus group actually carrying on the discussion.  If you haven't signed up for this study, posting a comment in here could bias the opinions of participants who have.  To that end, only posts from the following Army.ca members will be responded to in this thread.

Grunt031
MJP
48Highlander
a_majoor
Allan Luomala
Pte Massecar
Andyboy

Thus, if you have not signed up for this study and emailed in your consent form, please refrain from posting until after Wed, June 29th when this thread will once again be open to anyone and everyone.

Thank you very much

Mark Rutley

* * *
For those taking part in the focus group, here are the ROE for this discussion:
1.  Rank is not a factor.  
2.  Everyone's opinion in this room counts and will be counted.
3.  Personal attacks will not be tolerated.
4.  Keep on topic.
5.  The skies the limit with respect to ideas and concepts, but try to keep them grounded in current technology or soon-to-be emerging technology (i.e.: no disintegration beams).
6.  Have fun.

Here is information concerning the Micro Air Vehicle (MAV) under discussion.

MAVs have the following goals:
- A dimensional limit of 15 cm in length, width and height
- An approximate vehicle weight of 50 g
- A useful payload weight of about 20 grams
- An endurance of 20-60 minutes
- An operating range out to 10 km
- A cruising speed between 10 and 20 m/s
- Total unit production cost of $5,000 (early) down to $1,000 (later)

Possible payloads (not all at once):
Visible light or infrared camera
NBC Sensor suite
Acoustic sensor
Munitions?
Other?

The first question is: 
What specifically do you want this device to be able to do for you?  What would be your goals for this device?


----------



## ZipperHead (22 Jun 2005)

I would want this device to be able to see without being seen. Anything that would allow a commander to gain eyes or ears onto a given area with minimal exposure of equipment or personnel.

Personally, I am having a hard time envisioning a device that could accomplish what you/we/I would want given the parameters stated. A payload of 20 grams seems to rule out anything other than a tracking device (like they place on animals). Not being a huge fan of Star Trek type of science fiction, I can't imagine any vision equipment that is particularly useful to fall into this category. As it is now (with the kit I have exposure to), we're talking kilograms, not grams..... and the power requirements..... recording (SD style cards, tape) or transmitting?

Being a computer gaming nerd, the only thing that I can even envision with my feeble brain is the "security drones" in HalfLife2 that come after you.......

Because technology does move at a dizzying pace (it wasn't too long ago that cell phones were carried in a purse-like bag, and now worldwide cell phones with MP3 players and cameras are common and so light-weight it's easy to lose them) my above arguments will seem quaint in 30 years. But, like most everyone in this day in age, I want results NOW!!!! With what exists now (or the near future.... 12 - 24 months), what is out there that can even remotely fit the bill (without getting into OpSec issues, i.e. CIA spy gear)???? Are there things that can be bought off-the-shelf (OTS) that you have links for that could give an idea of what the present day capabilities are, to give a better reference point for those, like me, without the vision to imagine sci-fi style technology???

I am the type of person who needs to see something, I just can't wrap my head around the theory until I see it in practice. Hence, that is why I am a Crewman, and not a rocket scientist......... Once I get more clear focus, or left and right of arc, so to speak, I should be able to think more about what something will be able to do, rather than dwell on what it can't do....

Al


----------



## MarkR (23 Jun 2005)

Hi Allan

Here's one right here - 7 ounces and has two cameras on board...

http://www.defensetech.org/archives/001467.html

I've also seen research on a MAV "insect" that is about the size of a large fly - with onboard camera.  That ones still about 10 years out for practical use, but they've made a good headstart.  Pretty nifty stuff.

cheers
Mark


----------



## a_majoor (23 Jun 2005)

Making the assumption that the MAV is possible as described (I wonder about a 10Km range in a package that small, as well as the ability to get a clear transmission from that range), my concern is how will the section commander control it. Stopping behind a wall, unpacking a controller and TV screen etc. reduces the amount of leverage the MAV could give you (the section will not be able to follow up rapidly on any information the MAV reveals)

I wonder if it is possible to have a "helmet sight" controller:

Step 1: the section commander or UAV controller pulls a monocole sight down from his helmet and initializes the MAV

Step 2: The MAV's image is transmitted to the monocole sight, with a reticle superimposed on the image.

Step 3: The commander or controller turns his head and "places" the crosshairs on the area of interest. The MAV responds by turning, climbing etc. to centre the camera on the highlighted area.

Step 4: the MAV also needs to respond to a simple set of voice commands: Forward, Back, Still, Return.

This should be standard for all MAV users, i.e. a tank commander or Engineer section commander has the same helmet sight/interface rather than separate vehicle mounted control systems. (I would support secondary "feeds" to larger on board displays on vehicles, such as the display in the section compartment of a LAV III or something similar inside an AFV or Engineer vehicle).

First cut at the idea.


----------



## MarkR (23 Jun 2005)

Good thoughts.  I like the helmet mounted monocle for viewing MAV camera data - very doable right now.  Turning the head to control camera direction might be difficult - most MAVs are too small to have a gimbled camera, but rather, you just turn the whole MAV and fly it toward the target.  Or have a camera mounted on the side and fly it in circles around the target (sort of like a spectre gunship without the ordnance  )  Other visualization systems incorporate a PDA or laptop computer to both control the MAV and view any camera imagery it's sending back.  The one I'm building will be based on a ruggedized tablet PC design (think large PDA).

Mark


----------



## a_majoor (23 Jun 2005)

I wasn't expecting a gimballed camera in a package that small, the pointing of the camera controlls to direction of the MAVs flight. Sorry for not being more clear on that point.

Thinking a bit about "other" MAVs, NBC sentry, sensors or ELINT/EW vehicles could just be programmed to fly a "grid" pattern and report back to the CP. To increase the utility of the MAV (or any other sensor suite system) the data should not only go to the operator, but also to the CP for colation with the other systems. End users could have access to a stylized map display (icons for contacts, contamination, EW sources etc.), or something like ARCVIEW where the database is related to particular map grids (i.e. click on a grid and a window with relevant data opens). This is obviously for higher level users, and needs to be done in the "background", perhaps at the ISTAR CC and fed back to Combat team commanders or Pl Commanders (depending on bandwidth).

One other feature which might be nice to have on a MAV is a laser pointer, allowing the MAV to designate a target for a PGM, or just freak out the enemy when thier laser warning system "lights up".


----------



## MJP (23 Jun 2005)

> The first question is:
> What specifically do you want this device to be able to do for you?   What would be your goals for this device?



I jotted down a few quick ideas and I want to type them before I headed off for some more deck building fun.

So in no particular order;


To be useful and flexible I think the ability to carry two types of visual sensors at a time.   The ability to flip from day camera to thermal or IR will help a the operator distinguish what he is looking at faster.   If it's low light and on the day camera he thinks he sees an enemysoldier, but isn't sure.   He flips over to hermal and voilia clear as day all he was looking at was a wierd shadow on the ground.     

I think the MAV has to be able to fly pretty much on it's own.   A operator at times won't be able to direct the MAV and probably won't have the required skills sets a pilot will have in regards to flying principles.   As well there will be times where the situation will dictate that the operator has to leave the MAV controls to do other tasks and the MAV has to be able to carry on flying without direction.   This sort of ability is already found in   the Dragoneye MAV used by the USMC.http://www.wired.com/news/politics/0,1283,52766,00.html

Ability to lase a target to get a grid or to direct in CAS 

As Allan said above it would be nice that the MAV was quiet and hard to see.   However with that being said I've seen a mid sized UAV flying around overseas by Camp Julien and the thing was next to impossible to actually see evne though it was only 2-300 feet off the ground.   The only reason I clued in on it was the noise from the engine. 

Now delving into a bit of wishful thinking.   The ability to let the MAV fly a set pattern ahead or around a unit/patrol and look for familar shapes(tank, gun, person).   IE: While flying the pattern it sees what it knows to be the shape of a tank, it alerts the operator and from there the operator directs the UAV

The control interface has to be light, fairly easy to learn, and rugged.   The user software has to be user-friendly, and easy to interpret.   The ability to send back further information t o a higher HQ through the interface would be desired.

Thoses are just some quick thoughts.... more later.


----------



## MarkR (23 Jun 2005)

Like the reference map idea.  And autopilot I think is pretty much a given at this scale of aircraft (no human has the reflexes to "fly" these things).  Good stuff.  Keep the brain-storming going...

Mark


----------



## ZipperHead (23 Jun 2005)

I know this may sound a little "strange", but I had a crazy idea for a launcher to get this thing in the air (particularly if it's noisy, little RC airplanes): a surgical tubing slingshot launcher, like those things that you would use to launch water balloons. This of course would require 2 or 3 people, but nobody should be travelling alone on the battlefield (it's dangerous out there, you know!!!!  :warstory After it gets to a certain height and/or distance, it could turn on/initialize/whatever. 

The automated racetrack pattern is also going to be the only way (IMO)  a person could stay situationally/tactically aware, without becoming totally oblivious to his surroundings trying to "steer" this bad boy, when he should be looking for other areas of concern, or plotting contacts on his map. He can override as neccesary to move it to another area, then switch to autopilot.

The controller should/could have a one earpiece earphone to alert the "pilot" to contacts, moving out range alert, low "energy" (for lack of a better term, as is this thing going to be battery, fuel, fuel cell, di-lithium crystal (the only Star Trek reference I know, I swear!!!!) powered????) alarm, proximity alarm (ie to a solid object such as a tree, mountain, humanoid). A wireless (Bluetooth?) headset would be better, with a wired option as backup would avoid the inevitable entanglement issues. One earpiece would be ideal, so as not to remove the ability to remain aware of surroundings.

If feasible, GPS assist, or the ability to move to a 6 figure grid would remove a lot of the burden on the operator to maneuver the MAV. Or, if digital maps are on the controller, just select via the stylus/pointer/joystick. A touchscreen would be ideal, but apparently (based on my limited knowledge of such things) they are fragile, and it breaks, it's useless, so a backup system would be required.

A backpack, such as that found with the MSTAR equipment (Coyote surveillance), would be useful to lug this eqpt around, if it was even remotely as big as the Aerial Head Assembly (AHA.....radar dish). It would have to integrate with the Tac Vest and/or daypack system (no matter what people think about it (personally I like it MUCH better than what it replaced) it will be around for a good 15 - 20 years, so may as well think along those lines. 

Has any thought been put into the maximum weight of the complete system (MAV, controller, EIS, pouches, etc)? Will it be portable by only one person (keep in mind the continually diminishing fitness standards of Generation X-box..... soon a manpack will be a 2 man lift....). And remember, It's not about the gizmo's!!!! Er, actually this study is..... I sit corrected!!!

I'm getting silly now, so I must go off and do some housework.....

Al


----------



## Grunt_031 (23 Jun 2005)

Here are a few notes, I lost my original post.

This is such a large topic I will concentrate for now on the most common denominator the Controller interface.

I think that a head mounted interface is not the way to go. Everybody likes to add equipment to the head because they think it is convenient and a space saver. We did some trials in FT Benning with DRDC with off weigh displacement and the troops found that carrying out the job was near impossible overall during long periods. Already we have Night vision, IFF, Comms Headsets, and Ballistic Goggles. They want to add the radio itself, intergraded ear protection, laser points, and now maybe a â Å“MAV head controlâ ?. Image the neck strain! Never mind working in urban areas, vehicles, wooded areas, etc. We also trailed versions of the helmet mounted monocular for data processing and that to affect eye/hand coordination. 

The most popular interface was an arm mounted PDA with touch screen. This version was field rugged (Used in Civilian Field Survey), and a 

Combat versions are being used by the US ARMY in Iraq

http://www.strategypage.com/gallery/articles/military_photos_2004622.asp

In addition, it includes a number of the options we are already discussing such as

3-D Topographical Reference Map

IFF 

Stylus Operation

Data/Video interface with Higher HQ (with preformatted report and returns (Form fill and send)

Data/Video interface with UAV. (This was done with Remote controlled aircraft/hovercraft with real-time video footage. RC were loaded with a blue tooth GPS and sent Grid of a/c location through out)

With this, I would add the following;

1.	3 D Flight planning with ability to adjust flight plan (Including hover options), with touch of a stylus, during mission. We used something similar for Patrol route planning.

2.	Tgt ID Software with ability to immediately disseminate tgt info to FSCC

3.	Veh Status

4.	Optional Manual Control of surveillance packages, such as pivoting cameras, zooming, etc

5.	Control Transfer protocols to other PDA's



No bigger than a small portable DVD Player or the New PS video system.


----------



## MarkR (24 Jun 2005)

The new PSP video game system would be the target size of the controller (and is what DARPA uses to control the WASP - looks like a big Gameboy).  That and the MAV (and launcher if the surgical tubing idea isn't used) shouldn't be more weight than your average filled canteen.  According to the PSP website, the weight of the unit (with battery) is 250 g.  With a vehicle weight of 50 g (including payload and fuel) that means less than 1/3 of a kg for the entire package.  And would fit in a pocket in the load bearing vest.

Just for my eductation (if I attempt to simulate the "moving map" display/overlay) - is there a standardized set of map icons that the you use during patrol or planning offensive/defensive engagements to indicate placements of friendly/enemy positions?

Mark


----------



## Grunt_031 (24 Jun 2005)

> (if I attempt to simulate the "moving map" display/overlay) - is there a standardized set of map icons that the you use during patrol or planning offensive/defensive engagements to indicate placements of friendly/enemy positions



For us, it was color coded symbols (Blue=Fr, Red=En, Green=Obs, etc), such as circles, squares, trianlges, etc and when you taped on the symbol a data window (with description, Grid, Speed etc) poped up.


----------



## a_majoor (24 Jun 2005)

There is a NATO standard set of map marking icons (updated from the old standards we learned in the Jurassic era) which are designed to be computer friendly as well as to contain more data (friendly, enemy, neutral, unknown, for example), I don't have the reference here, but it should be easy to find.

A few thoughts on "support" issues:

1. The MAV launcher and control unit should not be obvious to outside observers. The MAV launcher/carrier should resemble something a soldier would normally carry, like an M-72 tube. The helmet sight should resemble a set of NVGs if used, or the wrist display/controller idea should be as small and thin as possible, maybe with a CADADT cover and some means of reducing "glint" from the screen. (Operating at night might present a problem, the glowing screen could attract unwanted attention from enemy snipers). Obviously we do not want to call attention to the MAV or the operator, since they provide a large amount of leverage to the section. As a bonus, the MAV could be larger and more capable if "M-72" sized.

2. Logistically, it might be simpler to make MAVs disposable, rather than try to have troops recover them, repair and refuel them etc. If they are mass produced, a new ones could be delivered each day with the DP on a "push" system. Think of MAVs as more like "Air Hog" toys with the expensive part being the camera/transmitter. (This could also be applied to making the MAV a weapons system: Launch, acquire a target and dive on it, delivering a grenade sized warhead).

3. From previous research, I found the biggest flaw to UAVs was the narrow field of view. Any MAV sensor should be able to "flip" between a wide angle view (default mode, so you don't miss anything), and a "zoom" view for precise target identification.

4. This is way outside my area of expertise, but how are the bandwidthand frequency allocation issues going to be delt with? Would it be possible to have a "burst" transmitter in the MAV rather than having it send a constant stream of information?


----------



## MarkR (24 Jun 2005)

Bandwidth is very much a problem that is holding these things back right now. A few agencies are working on multi-frequency transmitter/receivers - able to transmit data on several freq's at once.  That will overcome a lot of bandwidth issues.  But as more and more sensors/higher definition sensors go on the MAV platform, more and more bandwidth will be required.

Let's change tack slightly - instead of talking about what would be good on a UAV, how about what would be bad?  What can you see causing you grief in the field with this?  Light was already mentioned, and weight/bulk is a given.  

Mark


----------



## a_majoor (24 Jun 2005)

Bad:

1. Complicated user interface (ideal: point and click)

2. Cumbersome launch and retrieval procedures (ideal: fire and forget)

3. Overly complex data sets: the MAV should do one or at most two things only

4. Overly ambitious mission profiles. A section/Platoon MAV should have about a 2 Km range, being in line with the GPMG or Javelin/Spike missile range. Armoured or Engineer MAVs "could" go farther, but by then you start overlapping with TUAVs and higher level systems. The MAV should be clearly designed for "around the corner/next bound".

5. A MAV weapons system might be more problem than it is worth (imagine looking for "dud" rounds, or not spotting a target after launch)

6. Very bad: attempting to use high energy fuels to increase range/performance. This stuff is toxic and difficult to handle, what does the soldier do when he sees fuel leaking from the launch container?


----------



## ZipperHead (24 Jun 2005)

I just got around to looking at the Wasp (I'm Mr Mom this week, with 3 young 'uns, plus I justy bought Battlefield2, for "research purposes"..... yeah, research)

Anyway, now that I have an idea what is out there already, I think I can see where you want to go. It didn't indicate how loud this thing is, but I imagine not particularly if it's using a Li-ion battery. 

How difficult would it be to have this thing become a helicopter-style of craft, as opposed to the flying wing? That would allow the hover ability that I think most people seem to want, especially if we are talking about shorter range (up to 2 km) for the around the corner/over the hill aspect of what the average combat arms user would need. I'm thinking that 2km is actually TOO far, and 400-500m should be what most people would want. As mentioned earlier, there are other types of UAV's for looking further out. 

I'm specifically thinking about built up areas, or more urban style areas, than the traditional open plains. 

I don't know how practical this would be, but could you have a common controller and paraphenelia, but a variety of different MAV's for different applications? Longer range (distance and/or flight time) version, IR and day camera version, weapons platform version, laser designator, etc, etc. Maybe even mix and match, or plug and play, to use a computer analogy..... I don't think a one-size-fits-all approach is the best, but may end up being the most practical (read as: cheaper and easier to train with, and support).

Al


----------



## a_majoor (25 Jun 2005)

I agree with Allen that the most common use of the MAV will be close in, but giving it the ability to "spot" for the pl support weapons is a huge bonus, especially if you are trying to arrange an indirect shoot, or observe the effects of a cratering charge from a safe distance (for engineers), or check out the woodline ahead in the next mounted bound. (2000m will put you in the effective range of the MGS gun and coax as well). 

I can see the MAV doing a "racetrack" orbit for 80% of the time, helping the troops look a short bound ahead or around the corner, but that 20% when you need to take a long look/long bound will make a 2 Km range well worth the extra expense.


----------



## 48Highlander (25 Jun 2005)

Instead of speculating on what features you'd want on the MAV, how about first defining what role(s) they'd be filling?  It makes much more sense to debate the specific requirements and then figure out how theMAV could best fill them.  Also, who says we need to stick to one type of MAV?  Close observation of a point target would probably be best carried out by a helicopter-type MAV, whereas searching a grid square would be more effective with the flying wing design.  For providing advance warning during patrolls, you'd need a MAV capable of indeffinite flight time - so possibly an extended-wing glider type design with a small engine and solar panels on the wings.  So, like I said, we should define the specific roles in which MAV's could be used, and exactly how they would be utilized to support the misson.  Then, for each role discuss what body-type and instruments would be most suitable.


----------



## MarkR (26 Jun 2005)

48Highlander - excellent idea, and was ultimately my goal (was going to move into that starting Mon or Tues  ) but since you brought it up now how about we go there?

Everyone else, what do you think?  AndyBoy?  Pte_Massecar?

Thanks
MarkR


----------



## ZipperHead (26 Jun 2005)

48th has a good point, IRT to the types of flying that should be done. I was toying with an idea, but I suspect it would be too complicated for a simple machine (KISS is a good rule to follow...): fixed AND rotary wing flight, not unlike the US Osprey. Props forward for fast movement forward, props up for hover, slow movement, rearward movement, lateral.......

Don't know how feasible, but it's a thought.

BTW guys, I gotta depart this study now, as I have to deploy to the field (Sunday night to friday night for the next 3 weeks). I will try to check in on the weekends, but as I have a family to deal with, computer time becomes low priority.......

Lot's of great ideas coming, and hopefully when I'm and RSM (retired service member), I will read about it in action in the latest hot spot, and be able to say "I had input into that thing!!!!" Yeah, right Grandpa!!!!!

Al


----------



## a_majoor (27 Jun 2005)

I don't know that you need multiple types of MAVs so much as you need mini mission pallets for want of a better word. (These would be factory installed, the CQ just pulls the right one off the shelf and sends it to the DP).

The basic use is local surveillance, so the "standard" package would have a camera with a wide angle lens, and a "flip mode" to a fixed zoom factor (3x ?) for pinpointing the target. Version two would have a thermal imager camera. The only other feature the standard MAV should carry is a laser pointer/designator. Other MAV payloads are possible, but for the Infantry section, Engineer section and AFV commander, these would be the most important.

A fixed wing design that fits into a launch tube, perhaps cylindrical in design with a payload mounted in the nose, pop out wings and tail after it leaves the tube, and a shrouded propeller in the rear would be a flexible airframe that could do "racetrack" orbits over a patrol, fly out to 2000m to spot for the support weapons and fly slowly enough for target observation (although it won't hover). It could also be inexpensive to mass produce.


----------



## MarkR (27 Jun 2005)

Hi all.  

We lose one, we gain one.  Allan - thanks for your input.  I'll forward remuneration details when I get them.

KevinB is joining us.  This is a late notice change, but in consultation with my supervisor, we don't think it will cause any undue affects to the program - especially considering this whole focus group is virtual.  

KevinB, welcome.

Just to recap:

WRT to missions/usage, so far we've mentioned:
1.  Recon
2.  Marking or lazing a target
3.  Patrol
4.  NBC detection (through DARPA)
5.  Munitions delivery (albeit limited)
6.  Spotting for platoon support weapons.

WRT to features:
1.  Cameras (wide angle, infra red, zoom)
2.  Some form of switchable payload for different missions
3.  "Hands-off" or simplified piloting scheme
4.  Some form of map on the controller that can display troop positions via standard icons
5.  Map interactivity (likely at HQ level)
6.  Ability to share data to other groups.
7.  Stealthiness
8.  High bandwidth
9.  GPS positioning/autopilot (ie: click on map, vehicle navigates to that spot)

48Highlander brought up a good point as well that different MAVs are better suited to different missions - such as a hovering MAV vs a traditional airplane flying MAV.  You could also include in this list ground vehicles - say a small controllable ball or car that you could throw through a window or drive around a corner to see what's what.  This of course then generates more Human Factor problems, like attempting to keep the interface consistent in both control and operation while at the same time ensuring the soldier doesn't get confused on what "mode" they are in (ie: flying, driving, hovering, etc).

I've likely missed a few things.  These were just off the top of my head.

Keep the ideas coming folks.

Cheers
Mark


----------



## KevinB (27 Jun 2005)

Thanks for letting me get in Mark - even if I was tardy.


Control/Display - has any thought been given to interface with the LandWarrior/Future Warrior data systems? The Xybernaut etc.   As well to intergration with the IFF/location setup with the SAS (Situational Awareness System) and display on the C-SAM of a LAV.
   a.) I don't like the idea of voice activated command, if you anything like me you get a little squeaky when scared and it may not react to your words of command - secondly you migth have it do something you did not want, while you .
   b) using the Xybernaut touch screen as an examply you could have it setup for simple commands - forward, back, left right and a second touch for distances.
   c) using the same icons and interopting with the SAS is key IMHO - being seemless intergation to higher - and back.

Flight - I think a hover / loiter w/ tight race track is a necessity - a_majoor makes excellent points as to range etc. however all things being equal the more range the better.
   
Data Transmission - I'll admit I am clueless on the bandwidth issue - would it be easier for it to send stills rather than motion video?   I'm not sure at the section level we need 100% realtime video all of the time - it would be nice - but more importantly I think we need the immediate ability to send info higher - you could turn on video once something is observed 

Payload - so much for being able to drop munitions - but perhaps some sort of small magnesium flare   - it could be used to draw attention / fire away from the section just breifly - like a tiny DD? and double as a self destruction means.

Laser Designator / Illuminator - talk to user JD here - he is the SME.   I'd like to see a variable system for pulse and steady beam so if the vehicles are operating in conjuction with others they can easily discriminate.

Vision/Detection Systems - II/FLIR - MAD (can it be made that small?) just an idea on using Magnetic detection for clearing woodlines etc.


----------



## 48Highlander (27 Jun 2005)

Allan Luomala said:
			
		

> I was toying with an idea, but I suspect it would be too complicated for a simple machine (KISS is a good rule to follow...): fixed AND rotary wing flight, not unlike the US Osprey. Props forward for fast movement forward, props up for hover, slow movement, rearward movement, lateral.......
> 
> Don't know how feasible, but it's a thought.



Very feasable, and was done by the US.  The helicopter propeller can be stopped in mid flight and locked in place to serve as a wing, while a jet engine in the center of the aircraft propels it to high speeds.  However, doing this for a MAV would be too pricey, make them too bulky, and isn't really neccesary.  Better solution I suppose might be building a MAV with a large enough wingspan to allow it to fly at very low speeds (like a glider?), yet also be capable of ataining high speeds without tearing itself apart.  I'm not sure about the physics behind that, we'd need an aircraft tech for input, but I'm pretty sure it's doable without too much difficulty.  The other advantages of a longer wingspan would, ofcourse, be longer flight time for the same ammount of battery power.  And you'd have enough surface area on the wings to hook up photovoltaic cells, which would give it a heck of a lot of flight time between recharges.

So ok, assuming the proposed MAV can travel slow enough for detailed target observation, anyone still see a need for a helicopter type MAV?  I'm starting to lean more towards the single airframe, multiple package idea.


----------



## MJP (27 Jun 2005)

I think a helo MAV would be benificial in some circumstances, but for the prpose of providing some eyes on for a Sect/Trp/Sqn, a traditional winged airframe is fine.  The MAV itself itself isn't going all that fast so loitering over one spot is relativly easy to do by just race tracking over the position as 48th suggested. 

Kev brings up an excellent point in regards to SAS.  I've used the system and was pretty underwhelmed to say the least, however my prejudices apart I think that the MAV could have the abilty to project what it sees onto the SAS using the standard map icons.  I don't see the MAV it self sending this info to the SAS system but the interface itself.


----------



## MarkR (28 Jun 2005)

Dumb scientist question here - can you tell me what SAS stands for? ???  I'm pretty sure it's not the Special Air Service.

Thanks
Mark


----------



## MJP (28 Jun 2005)

Situational awareness system...overseas we basically use it(right now) to track our vehicles, but it's capable of a whole lot more.

Here is a brief overview here http://www.army.forces.gc.ca/lfwa_hq/feature_situational_awareness_training.htm


----------



## KevinB (28 Jun 2005)

Situational Awareness System -- it works in conjunction with PLGR and TCCCS to IRIS and gives units the ability to see where they are - where others are and where the enemy is on a digital map


----------



## 48Highlander (28 Jun 2005)

SAS - Situational Awareness System

http://www.army.forces.gc.ca/lfwa_hq/feature_situational_awareness_training.htm



One other thing I meant to cover as far as bandwidth issues go - anyone have any idea just how much bandwidth is used up for video transmission?   And what sort of data compression/encryption are we talking about here?   I don't see there being a problem with bandwidth if you utilize a complex compression algorythm.   If you want to go off-the-shelf, there are proccessors on the market capable of DivX compression/expansion.   Assuming a bitrate of 700kbps, you could have DVD quality imagery from the MAV.   Considering that the 801.1G wireless transmission protocol is capable of speeds up to 125Mbps (about 178 times faster if I did my math right), bandwidth shouldn't really be a problem.   You could even have the MAV transmitting ultra high quality pictures of the target area for recce purposes without creating a bandwidth problem.   Ofcourse, maintaining that speed over a distance of 2km might prove difficult, however, no matter how slow the transmission speed, I can't imagine it dropping below 1mbps, which would still be fast enough for our purposes.   The bigger problem would be providing enough electricity to power the data transmission over ranges of up to 2 km - which once again would make solar panels pretty cruicial unless you only need your MAV for a few minutes at a time.


----------



## a_majoor (28 Jun 2005)

Moving back to the physical as opposed to the electronic, a tube launched MAV could have a "cruise" and "loiter" mode; the wings snap out to 450 on launch for cruise, and extend fully to 900 for long term loiter.

I think 48th has hit on an important point; power supply. Even with Lithium Ion batteries, it will be difficult for a MAV to have long endurance and send high bandwidth transmissions over extended ranges without running into serious power supply issues. Perhaps the MAV needs a traditional model airplane engine to run things (2 or 4 cycle engines with glow plug ignition using methanol fuel or diesel). There are some medium term work arounds, though. The MAV could actually be powered by a "micro turbine" engine; some of these prototypes are the size of a dime, and are designed to power laptops and other electronic devices for extended periods of time. Fuel cells that can work with a liquid fuel are also in the prototype stage (handling hydrogen in the field is a headache I don't want the troops to be saddled with). The only reason I don't mention solar cells is the MAV needs to be able to work 24/7, including when the battlefield is obscured by dust, smoke or fog.


----------



## Grunt_031 (28 Jun 2005)

> power supply



Maybe a Hybrid type engine both conventional/battery/solar panel?

as for range. how would it fit into the ISTAR plan/ Surveillance plan. I think the 2 km or less at the section level would be good. 

Are they not have problems in Iraq with the problem of coordination of all the UAV/Aircraft.


----------



## Grunt_031 (28 Jun 2005)

Here is a good link discussing the same ideas we are hashing.

http://www.defense-update.com/features/du-2-04/mav-design.htm


----------



## MarkR (29 Jun 2005)

Yeah, that's a good link.  I've visited that quite a lot over the last few weeks or so.

Okay all, you've given me a lot of good information to go by.  There's just one last thing I want to ask you, and I know it's been partly covered before, and that's more detail on the actual controller interface itself.

Specifically I'm looking at how you want to control this thing.  Previously, it was mentioned that most of the actual flying should be done automagically, leaving the soldier to either watch the video feed or keep eyes on the surrounding terrain.  Therefore, assume the MAV carries enough onboard intelligence (or in the controller) to fly itself to wherever you tell it to, and can avoid obstacles.  Also assume that all the technical problems that have been discussed have been solved.  You've got in your hands a 15 cm flying machine that can hover or fly a racetrack pattern, with a range of up to 2 km, and an endurance of up to 1 hour.  Current payload is wide angle and zoom cameras.  You've got a large PDA device (or laptop if you prefer) as the controller.  You've got a village or wood to recce and there may be unfriendlies in the area (always design for the worst case scenario).  

You know roughly where you want to put the machine.  What do you think is the best way to tell it where to go?  

IE: 
1.  Have a map display and click in waypoints with airspeed, altitudes, heading, etc.?  Then sit back and watch the camera feed.
2.  Have a bunch of "knobs and dials" to set heading and altitude for a semi-manual piloting capability?
3.  Have the ability to switch back and forth between the two as mission requires?
4.  Some other kind of input scheme?  Voice? Joystick? 

This is my last question, so please everyone sound off on it.  After this, I'll be writing up a Product Design Specification based on what you've talked about and on my research into MAVs which I'll email to you if you wish.

Mark


----------



## KevinB (29 Jun 2005)

#1 - with touch screen buttons for additional input (like right/left, forward/back, up/down and loiter)
Something like the xybernaut






 the thing on the wrist...


----------



## Grunt_031 (29 Jun 2005)

> 1.  Have a map display and click in waypoints with airspeed, altitudes, heading, etc.?  Then sit back and watch the camera feed.
> 2.  Have a bunch of "knobs and dials" to set heading and altitude for a semi-manual piloting capability?
> 3.  Have the ability to switch back and forth between the two as mission requires?
> 4.  Some other kind of input scheme?  Voice? Joystick?



1.    I think that is the easiest may to go, the preflight planing would have to be 3-D (Hopefully via Sat imaging) to take advantage of the tactical movement of the MAV. If it did have the AI to follow the map of the grd without instuction would be great and eliminate the need of the controller to program it.
2.    semi-manual piloting should be done via touch screen commands, image feed adjusted by a small joystick.
4.    Voice command maybe a option in future but the ones we tested were unreliable and hard to calibrate. I think that this would be the least desirable of all the input option because too many things could go wrong with it. Joystick for the flying or movement would take alot of practice to use, restricting a joystick to a secondary function such as camera manipulation would be alright.

The size of the interface controller should be about the size of the xybernaut, or smaller. The restriction is , a smaller device is that it must have great resolution for the imagery feed. These days the smaller the screen the less you see, or the quality is poor.


----------



## a_majoor (29 Jun 2005)

I would not want to be glued to a controller (especially if I had to move suddenly), so perhaps a map "pre planning" session (set a series of waypoints for the MAV to follow), and a means to override if you identify a target. This needs to be quick and intuitive. I am going to assume a setup similar to KevinB's picture on the previous post:

Step 1. The display shows a map, and the operator inputs the waypoints by tapping the screen with his stylus (or fingertip). (If a 2-D map is used, the MAV may have a default altitude, or be able to assume a constant altitude relative to the ground.) If the MAV is recoverable, it might be simple for the control unit to have a "come home" homing signal or beacon, allowing the operator to recover the MAV anytime on the move. One toggle switch to initialize the MAV and recall it

Step 2. The MAV is initialized and launched. The display goes over to the camera feed (another toggle switch to allow back and forth between the image and map) (third toggle switches between wide angle and Zoom)

Step 3. The controller sees something on the screen which arouses his interest. He taps the stylus on the image twice, and the MAV assumes an orbit which keeps the image centred on the screen. (This would require a fair amount of intelligence built into the MAV, I think).

If I have this figured right, the display and control unit has a low glint screen, a stylus attached by a wire or cord, and three toggle switches on one side: 

     Map/Camera
     Normal/Zoom
     Initialize/Return

I still have a bit of an issue with the controller strapped to the wrist; it is an indicator of who is important in the section; the screen's glow could have tactical issues at night, and the resolution of the image might not be there.  Maybe in the longer term this could be done in "virtual reality", i.e. the camera sends images to a monocle display while the actual MAV control is done through a "data glove" which interprets hand movements into controls (mostly for overriding pre programmed manoeuvres). Of course enemy snipers are going to be looking for guys who are waving their hands around spasmodically


----------



## MJP (29 Jun 2005)

MarkR said:
			
		

> IE:
> 1.  Have a map display and click in waypoints with airspeed, altitudes, heading, etc.?  Then sit back and watch the camera feed.
> 2.  Have a bunch of "knobs and dials" to set heading and altitude for a semi-manual piloting capability?
> 3.  Have the ability to switch back and forth between the two as mission requires?
> 4.  Some other kind of input scheme?  Voice? Joystick?



I think #3 would be the best with an option to change altitude and speed through the interface, of course I'm assuming that to change airspeed and altitude it would not be a knob that you have to turn but rather an interface button.  The problem with a map display/Touch screen/pad that you click in on is that they usually require a special type of stylus and things like that tend to get lost rather quickly in the field.   Plus looking at how small some screens are(not that you want a large one), some people may have "large fingerinitus" and  not be able to use it properly.  I've personally found them to be finicky at times and  especially hard to use with gloves on.  But if technology allows you to use anything to I would prefer a touch screen of sorts rather than manually adjusting or inputting waypoints.

I like the Americans approach which is to make the interface similar to controllers that their soldiers are already use to working with(PS2, Gamecube, gameboy).  Game boy is the picture I get in my mind when you talk about the interface.  Either attached to the wrist or hand carried/'binered to a persons tac-vest or the option to do both.

Simplicity would be the key for controlling the MAV through the interface.  Easy to use Pre-launch, Launched, and Camera menus that can be called up fairly quickly in a fashion similar to a_majoor's suggestion of a double click on the screen idea.


----------



## KevinB (29 Jun 2005)

I just want to clarify that I DONT like the xybernaut method of wearing for this system - more of a size /interface setup idea.  I (personally) dont see this as something for the section commander to play with as he has enough on his plate, and with all the highspeed gizmo's we deploy with these days this sort of thing won't be much of a target identifier.

I'd rather have it in a pouch on your LBE able to foldout (the pouch) and be used both with the pouch 'unstowed' for movement (you moving) and seperate from the pouch - or pouch removed from vest - when static.

 As much as I hate to go off on a tangent - this sort of thing for the LI-SOC building block 4 man det could be ideal - as well as for a 4 man (heavy) sniper det to pick a route to the FFP.  it would be nice if the MAV could accept (on the fly) digital aerial photo's from other assets.


Cheers


----------



## Andyboy (29 Jun 2005)

Hi everyone, I meant to contribute to this discussion before but I just started a new job so I haven't had much time to reply.

When I was in my fourth year my minor project was working with the aerospace engineers at Carleton who were designing a UAV to patrol the coast around NFLD for oil spills. The ID portion of the project was the portable control station which was meant to be housed in a pickup and used at the landing site in case the A/C needed to be landed visually. 

 We researched a lot of new technology that is available (that was about five years ago) and the technology exists to do pretty much whatever you want to. Soft, foldable/flexible screens, soft keyboards, wireless controlers, the ability to broadcast sound to your ear wirelessly and without anything in your ear, the ability to control simple functions on a computer using thought, screens the size of a thumbnail with resolution equal to any desktop computer...believe it or not, it's all possible. Which leads me to the only point I can really make, why design a requirement based on what you think is possible rather than what you think is required? 

Andrew


----------



## MarkR (30 Jun 2005)

Hi AndyBoy.  

Designing based on soldier requirements is actually what I'm attempting to do here and is the end product of Phase 1 of my MSc (Development of the Product Design Specification).  I'm a cognitive/human factors specialist, so the actual physical design of the MAV itself doesn't much matter to me, as long as it fulfils the needs of end users and allows me to build an interface without imposing a lot of complicated constraints.  And I agree, given enough time and resources, just about every technology is possible these days.  (I've seen MAVs that look like big mosquitos - complete with flapping wings to fly and the ability to "walk" - the creator of which is currently attempting to make them "forage" for combustible fuel in the natural environment.  How Science Fiction is that?)

Anyway, based on the suggestions everyone has made, the next step is to generate a list of user requirements, then bend the technology to fulfil that list.  Then of course take the whole thing back to the users over and over to "tweak" it, because no-one ever designs right the first time around.

There are still a couple of people I'd like to hear their opinions of concerning the nature of the interface, such as yourself, and KevinB.  Even if you agree with what was already said, please simply say so.  

Thanks everyone
Mark


----------



## a_majoor (30 Jun 2005)

Slight tangent here:

KevinB is right about having lots of high speed kit strapped to our bodies, stuffed in Tacvest pouches etc. Looking at the device strapped to the soldiers wrist in the picture, it occurred to me that instead of having a separate MAV controller, combine it into a next generation "soldier interface" (for want of a better term).

Since we already assume the ability to display maps, transmit and receive video feed and so on, then this device would _also_ be able to serve as the section level radio/GPS/SAS system etc. The GARMIN RINO is a FRS (Family Radio Service) device which can download maps from the Internet, act as a GPS receiver (displaying waypoints and location on the downloaded map), a short range radio, and gives situational awareness since it displays the location of any similar GARMIN RINO that is transmitting to you. All this in a $400 package you can buy at Radio Shack. The soldier interface would do all these things as well as act as the MAV controller. As a sort of bonus, if we assume the section commander has one and uses it as the "radio", and a separate soldier is the MAV operator, then each section has two of the devices, so there is a level of backup built into the system.

Most of the time the soldier interface would be in a pouch or pocket. If the user needs the map display, or is using a MAV on the move, it could be clipped to the front of the Tacvest so the user can quickly look at the screen, and taken off and held in the lap when stopped.

The use of a stylus on a touch screen is a potential weakness, perhaps issuing combat gloves with a "fingernail" that can be used as a stylus (but then, the guy will loose his gloves....), touch screens offer faster interfaces than any joystick, cursor and mouse or knobs and switches approach that I know of.

Ideally the MAV can be initialized, launched and tracked while the section is safely out of sight, but more realistically, they will be using the MAV to scout the next bound, flying overhead while they are on a patrol, or during a firefight to locate the enemy and place the support weapons fire on him. If you make prototypes and trial them, make sure the test section(s) are using the interface under those conditions to see what "really" works.


----------



## Andyboy (30 Jun 2005)

Sorry, I didn't make my point very well, it was late, I was tired and it is frigging hot here. 

People want toast, not toasters. Infantry soldiers don't want MAVs they want the information that a MAV, amongst other things, might provide. The physical details of the instrument that gathers that information is irrelevant provided the information is reliable and accessable. As an infantry section commander the airspeed, altitude, heading, etc is of no use to me. What I want is to be able to se what I need to in order to make my plan. Let someone else figuire out how the device gathers that info, just let me see it. 

Personally I think the control of the MAV should be under the control of someone outside of the section, the infantry section has enough on their plate without having to consider the MAV and the phyiscal space it is occupying. I think that at some level, PL?, Coy? there is going to have to be a warm body controlling and coordinating the information gathering systems that the sharp end relies upon to make their plans. I think that autonomous flight is of course a given and perhaps it is as simple as racetracking above (or near) a designated sub call sign who has priority over what information the device gathers. It really isn't all that different from how we employ recce assets (in the infantry at least), just at a lower level. I think the relationship between the lead section(s) and the operator will be key. The operator will have to anticipate the section's move and interpret the section's requests for info and direct the MAV (or whatever device is appropriate) to gather that info. This may sound cumbersome but it isn't any different that how we employ signallers in the infantry now and perhaps the mav controller would be colocated with the infantry section or slightly behind.  

The key will be in designing a system to link the end user of the information to the operator so that the information exchange will be as natural as speaking. The end user should be able to "point" and verbally request information on a target, just like we do now. "Pointing" could include physically pointing, designating with weapon sight, clicking on a map, etc, It's going to vary by task and by the user. Once it is understood what exactly the end user needs it would be up tot he operator to gather that info and relay it to the end user. 

The information should be available to the end user in the format that is most useful to him. For example a c-6 gunner will want to see the target from his perspective so that he can judge the fall of shot/effects of his shooting and adjust accordingly without having to think (ie left is left, up is up). A section commander might want to see it on a heads up display of some kind or in his weapon sight or both. The question is not what sort of device the end user will carry around with him to control the MAV, the question is as a_majoor alluded to, what OTHER devices are we going to be carrying? 

We already carry weapon sights, radios, gps, maps, binos etc etc. Personally I think adding yet another "thing" is going to get people killed. We should be concentrating on a systems approach to data and how we convey it. Will it be a screen? Probably, but like you said, at this point who cares?

I think I forgot my point except to say that all I want from the MAV is what it can see and an intuitive method to give input into what it sees. What does the operator want to see? I don't know, I'm not an operator, but from my very limited experience in the matter the operator will want a few different things.
First will be a systems screen that details the devices systems and status, this will be crucial for take off and recovery as well as assessing battle damage.
Next will be a nav screen so the operator can input/monitor nav data. We found that a top down scalable map centered on the veh was most useful, with the ability to change the map to be North-to-the-top versus rotating with the heading of the A/C was also useful. We found that a touchsceen was easiest to manipulate with all the controls being on the sceen. Many touch screens can be used with any pointed object as a stylus so sticks, pens, rocks whatever could be used. 
Next would be a camera view. The UAV we worked on was signifigantly larger than the one we are discussing here and had a separate turret mounted system of observation devices. 
Next a front facing view was used for us for inclement take of and landing. This view included all the info found in a typical pilots HUD.I think that allowing the option to toggle the HUD on or off  wold be good, or perhaps delivering the picture without the HUD data as it isn't useful for the end user.

FInally the ability to set your screen up with any of the above combinations. IE Nav and camera, camera and systems, systems and nav etc etc. 

At any rate sorry for the long post Ihave to get backto work now. If youa re interested I can dig up some of the work we did to try and give you a better idea of how the screen system worked.


----------



## a_majoor (30 Jun 2005)

I'm with Andyboy here, but would even go so far as to strip out the "control", systems and takeoff/landing information by building it into the MAV or making it irrelevant. 

By making it irrelevant I mean launching disposable MAVs from M-72 style tubes. One the control unit gives you the green "initial" light the soldier carrying the tube extends and fires it. The MAV jumps into the air and begins transmitting.

By stripping out control, If the soldier has enough time (i.e. preparing for a patrol), then he inputs the waypoints at leasure and lets the MAV do most of the thinking after that. In an advance to contact scenario, the MAV could be preprogrammed to fly an irregular orbit based on the position of the control unit (irregular so the enemy can't just pinpoint the controller by watching the MAV). The only time the MAV is under direct human control is when the operator identifies a target and uses the touch screen/data glove/telepathic implant to change the MAVs course to put the target in the center of view (this should be stressed in operator training). 

Once the target is centred on the screen, the gunner can "walk" busts onto target, section commander can make his quick estimate, engineer can decide what tools or vehicles are needed to deal with the obstacle, tanker (excuse me, MGSer, MMEVer etc.) can select a round for the main gun etc. For me, the primary use of the MAV is to allow me to see "one bound ahead" or "around the corner". High definition video or Thermal Imaging is what I want from a MAV, and if the HQ, Int, Sigs etc. wienies have other potential uses for a MAV, then great, they can slide in the appropriate payloads and operate them on their own.


----------



## Andyboy (30 Jun 2005)

I agree that the takeoff/landing portion would be automated, witht he project I worked on the UAV was large, expensive nad expensive so they wanted ta backup option to land the A/C in the off chance that there would be inclement weather on the east coast. ha ha.

I thikn htat depending on the manouverability and "intelligence" of hte veh plus hte ability of hte operator the MAV could be used in urban ops as well for pieing corners and the like. I imagine the comd could designate the room that he wanted the MAV to enter and the operator could fly it in there. while the comd and entry team watches.  

That is an example of what I would want it to be able to do, not necessarily what will be designed into the system.


----------



## 48Highlander (30 Jun 2005)

There's no point to taking control of the MAV away from the section/platoon as Andyboy suggested - the whole idea behind having a MAV is so that the people on the ground can have an information gathering resource which doesn't rely on personnel who may be dozens or hundreds of miles away.  So we don't want the section commander being burdened by more stuff?  Make it a platoon resource and put the signaler in sharge of it.  He's generaly a glorified secretary, so since he doesn't have much to do, and since he's always right beside the platoon commander, he'd be in the perfet position for gathering intel through the MAV and getting it immediately to the platoon commander to be distributed through the chain.  Anyway that's more of an organizational problem, and it can always be solved once we have the equipment.  Right now we're focusing more on design.

I also don't like the wrist interface - it's either too bulky, or if it's small enough it'll have shit resolution.  A PDA sized device that fits in a pouch on the TacVest sounds like a good idea.  A laptop sized device might be better if it's a platoon resource being controlled by the signaler, or an individual tasked solely to controling the MAV.

And as for the controls, I'd say we deffinitely need to be able to set simple way-points (doubleclick on a map for instance), as well as being able to fine tune the controls.  If it was only one or the other, I'd go with the waypoints.  To an infanteer, simplicity would be more important since, as has been pointed out, we have enough to worry about in the field without having to stop for 10 minutes in order to dick around with dials and buttons.


----------



## ZipperHead (30 Jun 2005)

The idea of an M72-style launcher sounds about the best to me so far. Maybe even similar to a comet para-flare. Something similar would remove the "hey, shoot me because I'm carrying something important" factor would be removed (or force the enemy to shoot everybody carrying M72 or para-flare tubes.......).

That xybernaut console, while being somewhat bulky (remember cell phones from 6 or 7 years ago, compared to now??? the size would probably be tiny when developed for the future, compared to what it is now.....) is along the idea that would keep ones hands free for other things (shooting bad guys) but allow the controller to be readily available. The graphics resolution could be an issue, along with ambient light, but I'm sure something could be done about that. I use a red piece of clear red film for my Garmin GPS to cut down on white light "leakage" at night, so low-tech works pretty good sometimes.

A flip down visor idea (sort of like what pilots have on their flight helmets) that has a HUD to display it on the inside of the visor might be an idea, though it would cut down on vision. An easy/obvious solution would be that the operator would have to have local security while employing this, but that more or less goes without saying: you're going to be pre-occupied as it is, so that would neccesitate a "wing-man" for protection while employing this bad-boy (only Rambo can drive, command, load and gun a tank by himself.......)

Al


----------



## a_majoor (1 Jul 2005)

In organizational terms, a MAV should ideally be under the command and control of the end user: the section commander/2I/C. A Pl HQ MAV would be useful for setting up the platoon attack and support weapons fire, although rather cold comfort for the survivors of the lead section.

As well, if you read LCol Bank's paper in the latest CAJ: http://www.army.forces.gc.ca/caj/documents/vol_08/iss_1/CAJ_vol8.1_05_e.pdf you will see platoons and even sections are becoming widely dispersed, "_Squads were working 5-30km from their platoon headquarters_" so sections will have to have the means directly attached.

Adding an extra person in each section to fly the MAV may be a viable idea, we accept having HUMINT and CIMIC pers on patrols, and have long had engineers and other arms and services attached to various units and formations, so having the Sergeant yell "scope out the third floor of that house on the end of the street", then looking at his screen while the MAV operator flys the MAV into position isn't a big streach.


----------



## MarkR (1 Jul 2005)

(hmm...snazzy colour scheme for this Canada Day.  Plays havoc with the eyes though)

Hello everyone.

Because of time pressure, today is where I will officially "stop" the discussion, although I think there's some other great comments waiting in the wings.  But please feel free to carry on if you wish.

For your interest, here's my way ahead:

1.  I may attempt to run one more focus group to bring my numbers up from 7 to 12 - we'll see if time permits...
2.  Use this data, combined with information gleaned from my literature review, to develop a MAV Design Specification that reflects user needs as much as possible.
3.  Model a simulated MAV using the flightsim package X-Plane.  This flightsim allows a user to build just about any aircraft they want, provided they know it's dimensions.  For this round I'll likely keep the MAV simple - i.e.: a WASP type device without the ability to hover.  Perhaps later if there is interest at DRDC I'll remodel it into a hovering vehicle.
4.  Develop a flexible user-centered interface for the MAV using LabView software and trying to incorporate as much of your discussion points as I can.  I've got about 25 days (if that) to model and code the interface, so I likely won't get all the bells and whistles in.
5.  Perform user trials on the interface.  Ideally I would like to use CF Soldiers for this, but seeing as I'm all the way over in the UK I don't think that will be feasible.  So I'll use local college students.  Again, maybe when I get back to Canada I can continue with this research and make it far more relevant to the CF.
6.  Write it all up, hand it in by Sept 14, then defend it in front of a panel of Uni PhD's.
7.  Try to drum up interest/funding to expand this research when I get home again.

Ideally I would've liked to have had your involvement from beginning to end.  And if I was running this study in Canada, that's what I would have pushed for. If anyone want's to see any part of what I do from here on out for interest sake (i.e.: the design specification, or JPGs of the final interface, etc.) let me know.  I'll also in the next week be forwarding you the details of the remuneration we discussed.

So thank you very much for your time and input.  I've got a lot of great comments to work with here, and a lot of new directions in which to take my literature review (ie: integration with this SAS device you mentioned).  

Cheers
Mark


----------



## Infanteer (1 Jul 2005)

Ok folks, this was very interesting to watch - I hope we can do things like this again, as it increases the role Army.ca can play in critical discussions and idea sharing on the profession of arms.

Thanks for honouring Mark's request to not post unless part of the team (you made the mod's job easy).  Now that it is over, the rest of the membership should feel free to contribute.

Cheers,
Infanteer


----------



## Andyboy (1 Jul 2005)

48Highlander :

I'm not suggesting that the control of the MAV be out of the section commanders hands, I saying that the physical flying should be left to someone who is capable of devoting their concentration on flying the AC. 

"Anyway that's more of an organizational problem, and it can always be solved once we have the equipment.  Right now we're focusing more on design." 

How can you design something without understanding how it is going to be used?


----------



## 48Highlander (1 Jul 2005)

Andyboy said:
			
		

> 48Highlander :
> 
> I'm not suggesting that the control of the MAV be out of the section commanders hands, I saying that the physical flying should be left to someone who is capable of devoting their concentration on flying the AC.
> 
> ...



Well, SOMEONE is going to have to use it.  Chances are they'll be human, with all the abilities and limitations that implies.  So a common interface can be designed which can be used by all humans, nay? 

Seriously, I like your idea of someone else controling it, I'm just saying it can't be someone outside the immediate organization.  If it's a section resource, someone in the section operates it.  If it's a platoon resource, someone in the platoon operates it.  There's no point in having them controlled from batallion HQ - those guys should have their own UAV's to play with.  The MAV's are meant to be used by much smaller units.  So wether the MAV is controled by someone at the section level or at the platoon level, it has little to no impact on the actual controls for the aircraft, which is what I was trying to say.  Wether we want to have it controlled by the section commander, his 2ic, or the platoon signaler, the interface will be very similar.


----------



## Andyboy (2 Jul 2005)

" So a common interface can be designed which can be used by all humans, nay?"

Nay. It isn't being deisgned for all humans, it is being designed for a specific application that has specific requirements. The interface required for someone familiar with aircraft (say a fixed wing pilot) will be different for a person who has no familiarity with an aircraft (say an infantry soldier). The interface is also going to vary depending on what information that particular user requires. That is the point. The section member who is going to be using the information that the veh gathers will not require the same information that the member who is "flying" it will. Additionally the person who is "flying" the veh is going to need a different set of input and output devices than the person the veh is "reporting" to. For example the person viewing the data may not need a throttle control, the person "flying" the vehicle probably will. What physical form those requirements form will depend on where the personis, what other tasks he has to perfom, threat, weight, complexity, power, etc etc, etc. Further more what is appropriate for flying the MAV may not be appropriate for interfacing with a map, or a writing orders, or requesting supplies, etc, etc. That's why it is futile to approach army transformation in patches. It has to be decided beforehand what exactly we want our future soldier to be able to do and then design his kit from there. 

I agree that the person controlling the device has to be a member of the section, I am just concerned that as long as that person is "flying" the device he is a liability to the section. If his eyes are somewhere else he has to be protected. Which is why he may or may not be physically beside the sect commander, but maybe a tactical bound behind the section,, maybe even pooled at the PL like you suggested. Both are two very different environments. 

The bottom line here is that this "focus group" is not a particulary effective way to find the answers he is looking for. If you want to find out what controls would be required to fly a device as described you need to find someone with experience flying such a device or something close. Asking an infantry soldier what he needs to fly a non-existant a/c that he has zero experience with is pointless. Do you really know what you need to fly a MAV? I don't, I could take an educated guess but that would be about it. The only way to find out is to mock one up (virtually or physically) and try it out, which I think he is doing right now.


----------



## Andyboy (2 Jul 2005)

Sorry, I meant to include this in my reply: 

"Wether we want to have it controlled by the section commander, his 2ic, or the platoon signaler, the interface will be very similar."

Maybe, maybe not.

Here are a few questions that spring to mind: How long is the operator's course? How much time will be devoted to training? How about keeping current? What is the demographic of the average operator? Gaming experience? Flight experience? What specific skill set will be required to operate the device? What is their proximity to a power source? Is is possible to make it so simple to operate that anyone could do it? How much time and money can be invested in the development of the device? What are the size/weight limitations? 

And so on. You might think these are trivial matters, but good design is all about detail and "triviality". If you take a look at 99% of the kit you have been issued you would see that few people in the Canadian defence industry understand that.


----------



## 48Highlander (2 Jul 2005)

Eh I'm pretty sure that's why we were dsicussing a point-and-click interface.  Waypoints sound familiar?  I've met a lot of dumb/slow people in the infantry, but most of them can handle looking at a map and selecting a point they want monitored, or a circuit they want the plane to fly.  Smart technology for dumb soldiers   I could see your arguments being valid if someone had to literaly sit at the controls and move the thing around manualy.  When it's flying itself most of the time, the interface becomes much less of a problem.


----------



## Andyboy (3 Jul 2005)

48th,

Well as long as you are "pretty sure" then that is good enough I guess, I mean after all, why would we want to bother to investigate a system that has the potential to revolutionize how we fight? It would be far better to make assumptions and push the system into service and cross our fingers and hope for the best, right?

The design process is a formal series of steps that must be taken to ensure #1 the problem is well defined, #2 the solution solves the problem. Seeing as we have never employed an air vehicle at the section level there may be more to the problem than "point and click interface". Then again what would I know, you seem to know more about it than I do.


----------



## 48Highlander (3 Jul 2005)

Andyboy said:
			
		

> 48th,
> 
> Well as long as you are "pretty sure" then that is good enough I guess, I mean after all, why would we want to bother to investigate a system that has the potential to revolutionize how we fight? It would be far better to make assumptions and push the system into service and cross our fingers and hope for the best, right?
> 
> The design process is a formal series of steps that must be taken to ensure #1 the problem is well defined, #2 the solution solves the problem. Seeing as we have never employed an air vehicle at the section level there may be more to the problem than "point and click interface". Then again what would I know, you seem to know more about it than I do.



Well as long as there "may be a problem" I guess we better start spinning   There's always the possibility of a proble, but you gotta start somewhere.  All I'm saying is there's no reason why we can't start off with a simple, universal interface that can be operated by any member of the platoon.  If we find it doesn't work, sure, make the changes that are needed.  Worry about operators courses and other nonsense later.  I've never had an "operators course" for the piece of crap GPS unit we use, but I can still employ it when I need to, and I'm pretty sure we can come up with a much simpler interface for the MAV.


----------



## Andyboy (3 Jul 2005)

Look 48th, I'm trying to give you the benefit of my experience and education in product design, GUI design, and uav design. If your experiences in those areas tells a different story, lets hear it. If not then keep your snarky comments to yourself.

Product design, no matter what the product, is a FORMAL PROCESS to solve a problem. The way you are describing accomplishes nothing except wasted time, money, effort and capital and results in inferior product. That method you propose is the exact frigging reason why we have been repeatedly saddled with the garbage kit that we have been. This "lets just do it and hope it all works out" is incredibly shortsighted and wasteful but unfortunately is not uncommon.

It's pretty obvious that you have zero experience working with budgets, business plans or project management, if you had you would know better than to suggest that if we don't get it right we'll just fix the problem. The army doesn't work that way, not in Canada anyway. You only get one shot at a project, if it is shit, we're stuck with it. That is just a fact of life and therefore it behooves us to put as much thought into the front end development as we can. It costs virtually nothing to think a problem through but it is very expensive to fix a mistake afterwards. 

With that ends my attempt to share the knowledge I have worked to gain over the past decade or so. I guess there's some men you just can't reach.

Regards.


----------



## Britney Spears (3 Jul 2005)

Israeli M-203 launched Camera/Probe: Rafael Firefly







Israeli "Mosquito" Micro UAV, weighs 250g and flies for 40 min. Newer models will be heavier, have better cameras and fly longer.


----------



## KevinB (3 Jul 2005)

FWIW - I don't think the PL signaller is the person for this - operationally our signaller was run ragged.   Secondly you have 1 signaller alloacted for the PL - with 3 sections - when we where in Afghanistan we had some sections 30+ km from the rest of the PL.   

W/O the ability to hover We wlose thew bality to enter homes - which personally in the close combat environment is something I would as an 031 like to have. 

 Secondly I KNOW ANDYBOY has a lot of involvement in some DND projects ontop of his activities he has alluded to here - so I'd bank on his knowledge in how projects make ti or break it.


Cheers


----------



## Andyboy (3 Jul 2005)

Kevin,

The more I think about army transformation the more I think the Signal corps needs to evolve. They need to get away from "communications" and think about "information". Sounds like splitting hairs and it might be but it seems (from my worms eye view anyway) that there is lot of time energy and ewffort dedicated to voice communication and not enough dedicated to information communication. 

Personally I think there has to be a section level member dedicated to managing information. In the corporate world every team has a systems specialist who runs and maintains the computers and applications (software) needed for the team to do it's work, I think the section is no different. If we approach the need for information from a systems standpoint rather than a patchwork of individual items then we can eliminate a lot of duplication. As A_Majoor mentioned earlier the Rhino is a good example of combining like products. Add a few features like text messaging, email, and the ability to expand and it starts to look like something everyone should be issued.

Britney,

Any more info on that 203 launched deal? Looks very interesting. Are those in service or experiemental?

Andrew


----------



## Britney Spears (3 Jul 2005)

<a href=http://www.rafael.co.il/web/rafnew/products/land-firefly.htm>Right here</a>

No takers, besides (probably) the Israeli secret squirrels yet as far as I can tell.


----------



## a_majoor (3 Jul 2005)

Andy, I confess I am wondering how exactly we can "define" what doesn't yet exist? (This is a question from a PBI, so take it as a request for information, not a dig)

I can imagine what I would like to be able to do, and I hope my posts during the study were fairly clear in that regard, but since I don't have a MAV or pospective interface in my hands, I can only speculate that a machine with a fair degree of built in smarts combined with a touchscreen "point and click" interface would be fairly easy for a section to use and provide the information needed. (I added the disposable aspect in order to make it as simple as possible for the soldiers to use.)

The next step in my mind would be to actually make a few prototypes and put them through their paces, to see if the soldiers can actually use them. After a few cycles of trials and refinements, then a "ruggedized" unit can be made for actual issue...not to put words into anyones mouth, but I will bet that is the sort of process 48th is thinking of as well. What exactly are we missing here?


----------



## KevinB (3 Jul 2005)

The M203 launcher seems Ideal to me  - one less thing to pack - however hopefully this MAV can do more.
 I agree on the signals corps - but since to even get a medic in a combat role we had to put trigger pullers on the TCCC course...

I for one want to keep the section / det at 031 level - if you have to farm out jobs at this level it gets very problematic in that you basically have to then send the 'att' on a recce course or 'basic combat' to get them up to speed in working with the rest - for he/she (this is 2005  : ) has to be a shooter first - and gatherer bee second.


----------



## MarkR (4 Jul 2005)

Now that my week of questions is done, I can put in my comments without fear of derailing things.   ;D

A_Majoor has hit it on the head.  You can't define what doesn't exist.  But you can define a user demographic, and device requirements.  In this case, I'm designing for everyone in the Combat Arms, regardless of their current role in the section.  This is because NOBODY knows how a MAV will fit into a Section.  Some feel it should be a piece of every soldier's personal kit.  Others that it should have a dedicated "information specialist" in control.  Still others think it's a waste of time, and that more research and emphasis should be placed on allowing soldiers to use the Mk1 Eyeball to judge enemy troop positions and firing arcs.  

AndyBoy, I think we're all in heated agreement here.  You're absolutely right in saying product design is a very formal process requiring detailed problem definition leading to a solution.  But bear in mind here I'm not designing an end user product, I'm designing research. I wasn't looking for detail on exactly what was required (ie: "there shall be a button and the button shall be red and located 35 mm from position X...").  I wanted vague "hand-wavy" gestures and comments that began with "I think...".  NOBODY knows what Canadian soldiers will be doing with these things, or what is the best way to help them do it.  Or even if there's a need for these things.  That's why MAVs won't be available for 10 to 20 years.  This is, after all, the point of my research - to find out what is required in a MAV interface and how that device will interact with soldiers.  I was looking for left and right of arc here so that I don't begin doing research on something that is completely irrelevant to the task at hand.

Which is also the reason why I'm simulating the MAV, and then designing an interface to interact with that simulation.  That way, as the research progresses and new ideas surface, I can easily change the interface or the MAV characteristics without spending bucketloads of cash.  Then, as A_Majoor has said, sometime down the road when a good clear understanding of the cognitive and physiological aspects behind controlling and using a MAV has been developed, a Big-and-Ugly prototype can be built so that research into how a MAV will fit into CF doctrine can be conducted in the field.  Once that is done, then an extremely detailed design specification outlining a problem of the type AndyBoy has mentioned earlier (i.e.: how long to train a user? power requirements? integration with current kit, etc) can be handed to a bunch of engineers.  The engineers can then begin to work toward a solution to that problem.  

And if us egghead scientists do our research right, then engineers and designers will have far more guidance to produce something that will be useful.  After all, designing without researching human liimitations WRT new technology is the reason why so many people have the numbers "12:00" repeatedly flashing on their VCR's  

Cheers
Mark


----------



## 48Highlander (4 Jul 2005)

Andyboy said:
			
		

> Look 48th, I'm trying to give you the benefit of my experience and education in product design, GUI design, and uav design. If your experiences in those areas tells a different story, lets hear it. If not then keep your snarky comments to yourself.
> 
> Product design, no matter what the product, is a FORMAL PROCESS to solve a problem. The way you are describing accomplishes nothing except wasted time, money, effort and capital and results in inferior product. That method you propose is the exact frigging reason why we have been repeatedly saddled with the garbage kit that we have been. This "lets just do it and hope it all works out" is incredibly shortsighted and wasteful but unfortunately is not uncommon.
> 
> ...



If that's the way things are run it explains why government projects always cost so much more than ones civvie side.  And as far as I can see, flaws in current kit are due to the fact that nobody throughout the testing process wants to hear negative feedback.  But hey, if that's how things are done, who am I to try and change things.  Certainly we've got very good user interfaces for the GPS and the 522 set  :  Thank god for the current testing proccess.


----------



## Andyboy (4 Jul 2005)

Well then I guess I've been told. HA, I don't think this is a heated discussion by the way, it is just a miscommunication. I'm used to speaking with other designers so some of the terms I use may not be fully understood. 

When I speak of a "problem" I'm not referring to something that has gone wrong,I'm referring to the problem the end user has that needs solving that is driving the product. In this case the problem is not the interface, the problem is the section commander needs information he can't get without exposing humans to danger. This problem is very easily defined, it has existed since the dawn of warfare. Every commander at every level wants more information, the solution is how we gather it and present it to the commander. The solution has to include as many possible aspects of the items use throughout it's life cycle. 

An example I pointed out was the training cycle. The amount of time that can be dedicated to training the operator of the device (assuming the operator will not be the commander) will affect the interface and the capabilities of the MAV. 48th brought up the example of the 522 as a good interface (with which I wholeheartedly disagree, but that is another topic). If you compare the interface of the 522 with the 521 you can see that they are completely different. One is very simple with few input devices (switches, knobs) and few output devices (lights, beeps etc) beccause they are intended for different end users with different uses. The time available to train someone on the 521 is very short (i.e the battery goes in here), and the time available to fool around with it int he field menas the interface has to be as simple and straightforward as possible.  

The point is to start from what the end user wants, not in terms of a physical project, but what he needs. In this case what the end user needs is the information that a MAV might provide, not the mav itself. Do you see the difference? Ther is a saying that when you have a hammer everything looks like a nail, I hope that the MAV requirement is being driven by a requirement at the pointy end rather than finding a problem to solve with a solution. What has to be defined is not the "device" but the need, or problem. The problem is that I need to make a plan and I can't see everything I need to see in order to make that plan. How can I see what I need to see? I can send a warm body out and look and report back, I can ask for overflights, I can look through a pair of binos etc. Those are all solutions of varying appropriateness/effectiveness, but they are not the problem. The problem is seeing what you can't see what you need to without risking human life. Defining the problem includes detailing what exactly needs to be seen and the context. 

KevinB And A_Majoor nailed it when they said that they wanted to be able to point to a room and see what was in there. That is the root for the requirement summed up in one sentence. For the best results the trick is to think of the worst case scenario, inthis example you might add, at night, in winter, in a storm, under fire, etc etc etc.  From there begins the process of detailing exactly what that would entail in loose terms. Here it might be that the craft has to be able to climb stairs, fit through doors, hover, land etc etc. These requirements would then determine what the craft would actually be and would also drive the interface. Is that more clear? 

48th,

Our kit sucks for a number of reasons, one of which you have picked up on but it goes further. Feedback is rejected because the solution has already been "found" and the testers are looking for validation of their ideas rather than real feedback. Time money, effort, and reputation are all invested in a solution instead of defining hte problem which means the solution doesn't solve the real problem. 

That is the reason why gov't projects take so long and are so expensive, they don't follow the design process. What tends to happen is they throw something together that doesn't address the users needs (or industry's needs) , which then has to be recycled, usuaslly after tooling has started. Additionally you have to remember that some people build their career around such projects. 

I have to get back to work now, I'll add more later. Thanks for the discussion guys.


----------



## KevinB (4 Jul 2005)

Andy -FWIW I think 48th was pegging the sarcasm meter with his comment about the 522 and 521 radios...


----------



## Andyboy (4 Jul 2005)

My sacas-o-meter is still in the shop, along with my laptop, personal drive and motiviation.

The 522, 521, gps, tac vest, frag vest, CWWB, etc etc etc are all examples of bad design that was product driven, rather than user driven.


----------



## KevinB (4 Jul 2005)

Andyboy said:
			
		

> The 522, 521, gps, tac vest, frag vest, CWWB, etc etc etc are all examples of bad design that was product driven, rather than user driven.



YUP


----------



## 48Highlander (4 Jul 2005)

Sorry andy, I think it might have been my comment that disintigrated your sarcas-o-meter.  What I meant is that the GPS and 522 both have a horrid interface, and could have been made much simpler.  A MAV interface could be made a heck of a lot simpler even though what it needs to do is more complex.  I understand the basic idea behind the design proccess, I've had to follow it myself on other occasions.  Programming for example requires very similar procedures - you have to identify the problem, chart out possible solutions, and pick out the best one before you write one single line of code.  However, in some circumstances the solution is so clear that following the normal steps is just a waste of money.  I guess that's the way I see this - assuming your MAV is intelligent enough to fly itself in a holding pattern, and has enuogh juice to stay up for an hour+ at a time, the actual structure of the control interface becomes almost irrelevant as long as you keep it simple.  Say a PDA or a laptop with 2 types of views - one a map overlay of the area, one the picture from the MAV's camera.  The user simply selects either the spot on the map he wishes the mav to circle over, or the object on the camera image he wishes to observe.  Now you've got an interface that anyone can operate with 1 minutes training, and can do so quickly and easily without taking much time away from his/her other duties.  Modifications can be made to the interface throughout the testing proccess if neccesary at minimal cost, and there shouldn't be many in the first place.


----------



## KevinB (4 Jul 2005)

K.I.S.S.  

 Something lost on the TCCS designers - as I dont need to netwrok a battle group through my dismount radio - the guy who designed the 521 should just be killed to stop his offspring any chnace of designing kit...


48th - ideal concept


----------



## Andyboy (5 Jul 2005)

48th,

I'm still not getting through and I'm not really sure if it's me or you, but I assume it's me so I'll try again. Thanks for the clarification on the 521 and gps thing, sometimes it's hard to read tone on the internet. I wrote a paper on the ergonomic and human factors of the 521. It is a nightmare because the designers started with the assumption that we needed a "radio" rather than the "ability to communicate". Sounds like the same thing but they aren't. Toast is the problem, toaster is the solution. Protection is the problem, frag vest is a solution. Information is the problem, a mav is a solution. IF it isn't laid out inthe begginning what the problem is and what the requirements are in solving hte problem then the solution will not be ideal. You will end up with a radio that noone uses because it doesn't solve the problem that the end user has. 

As an example how does the solution you propose deal with the requirement that both Kevin and A_Majoor had for "pointing to a window and having the MAV fly in" to see what is inside? 



Edited to add

"However, in some circumstances the solution is so clear that following the normal steps is just a waste of money."

And sometimes the "solution" seems so clear that it overshadows the need. If the need (or problem) is not properly defined to begin with the "solution" tends to become the need. IE "Check out this awesome MAV, just think of what we could do with it, lets buy a bunch." as opposed to "We need to be able to get in to some really confined spaces under some really trying conditions, I wonder if we can make the MAV do it, if not lets keep looking." If the solution does not solve the original problem then it isn't a solution. Problem definition has to be fully exhausted before even considering a solution. I say again; problem definition has to be fully exhausted before even considering a solution. Often what happens is that a solution is considered even before the problem is defined. This tends to happen when the "designer" is wedded to a particular industry or mfg process and tends to result in stagnation rather than innovation. Sewn goods designer tend to think everything can be solved by sewing stuff together even when there are more appropriate solutions. Injection molders thikn everything should be molded. What makes a good design good is that is addresses the users problems rather than the designers.

 As an example the equipment that the Designers at Crye came up with is innovative becasue they had zero experience with designing kit. They started with very few assumptions and spent months learning what the soldier's probles were before even thinking about how to solve them. As such they ended up with something fairly radical for the time. If you ask a company that builds radios to suppy you with a communications solution don't be surprised when they bring you a radio becasue all of their knowledge revolves around radios (ie 521/522). The advantage of using an independant designer is such that he is free to consider the problem from a blank slate.


----------



## a_majoor (5 Jul 2005)

Thanks Andy, this presents the problem in much finer detail than I am used to thinking about it. (If you follow some of the Combat arms posts, you see we are trying to jury rig organization, doctrine and TTPs around already existing pieces of equipment, which presents rather messy "521" solutions to the problems).

So perhaps Mark didn't step back far enough, since he started with the MAV, (and even a particular design if I read his early posts correctly). The process should have started with," Kevin, Arthur, what do you need as section members/commanders?" and worked from there. 

How quicklly does an iterative process like this work? I really don't want to be in a position where we are gazing at our navels for a decade or so, and finally produce a piece of kit in 2015 which is "State of the Art 2005". Can the cycle be run quickly enough to produce kit in very short time frames?


----------



## Andyboy (5 Jul 2005)

Bingo, you've nailed it. The need or problem never goes away, it is just solved by newer (and hopefully more appropriate) solutions as tiem goes on. A MAV is not THE solution, it is A solution, or perhaps A solution to one aspect of the problem. The beautiful thing about working from this angle is that you aren't finished until the problem is solved from the users perspective which he himself determines. As you can see the tricky thing is gettting the user away from wanting a "thing" (i.e. a MAV) and thinking about the problem he needs solved. 

Can the process be done quickly enough? Absolutely. It sounds more involved than it really is. In fact most of it has been laid out already in various forms.  The most important part is determining what it is that you want to do and committing it to paper as a benchmark. If it is done in general enough terms as needs rather than products then any solution can be measured, quantitatively or qualitatively, against the desired outcome. 

Again, I want toast, not a toaster. I want to be dry, not a rainjacket. I want some way to eliminate the enemy threat, not a tank, rifle, mg, etc etc etc. Unfortunately 99% of what we use has been aquired by the "we need a new ruck" mentality. We don't need a new ruck, we need a new way of carrying our kit, guess which one we are going to end up with? And then guess how effective a solution it is going to be. The tproblem is we are now saddled with kit that doesn't do what we need it to do because we never determined what we needed to do in the first place, which then affects our doctrine and tactics.

If the army transformation is going to be successful we need to fundamentally rethink what the army is for and the best way to achieve it. The US is waaay ahead of us in this aspect, not becasue they threw money at it either, although their idea of throwing money and ours is different. According to Eric Fehlberg at Crye (a Canadian BTW) the US was tired of gettting the same old stuff from the same old suspects so the took a chance on Crye. Look at the results. The depressing thing is there is a LOT of talent in Canada that is being ignored becasue they don't belong to the "industry" (translation don't exist becasue of gov't contracts, an entirely different thread). The products coming out of companies like Blackberry, CAE, SMART technologies, and Arcteryx should make our Army the best equiped and organised on the planet, bar none. But hey I like those transformation posters!


----------



## Andyboy (5 Jul 2005)

Sorry for these long posts guys, this is one of the few areas I am able to comment on. As for navel gazing, I didn't really answer your question. The iterative process can be as rapid as the designer has time to devote to it and the client has funds and willingness to support it. 

That being said if you go too fast you run the risk of overlooking or bungling something, too slow and you get the situation you describe. Part of the requirement HAS to be a delivery date, which will affect the solution. Obviously if you have a week to work out a solution you are going to have something vastly different than if you had a month. 

As an example I designed a load bearing vest for a client which took me roughly one year from project start to production using this process. 

CTS took over 7 years for the TV and did not use this process.


----------



## Infanteer (6 Jul 2005)

Andyboy, this has been a learning experience - thanks alot for offering your input.


----------



## 48Highlander (6 Jul 2005)

Thanks Andy, that made your point a lot clearer.  I absolutely agree that you need to clearly define the problem before you consider solutions.  I just didn't think of the interface, or who within a platoon would be responsible for controlling the MAV, as an important part of the problem.  You're right though, it's something that should be considered fairly early in the proccess.


----------



## Andyboy (7 Jul 2005)

No sweat guys, thanks for listening, now if only someone at DND or NDHQ would listen...


----------



## Andyboy (7 Jan 2010)

Necro post alert.

http://www.cultofmac.com/meet-the-first-iphone-controlled-augmented-reality-helicopter/25497


----------

