MAV Study Focus Group Post

[Britney Spears]

<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]

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]

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]

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]

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.
 

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]

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]

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

 

[Andyboy]

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]

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]

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]

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]

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]

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]

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]

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]

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

 

[48Highlander]

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]

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

 

[Andyboy]

Necro post alert.

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