SSingh email #1

On Fri, 22 May 2015, AMER HMAIDAN wrote:

> A few questions that warrant your attention:
> 1. Does it matter what scenario we envision for this project? We've had some
> "what if" ideas, such as  "what if the system we've described is government
> mandated?". This actually would change quite a few things; if it was
> government mandated we could assume that there was wifi (or some kind of
> internet capabilities) within the entire city limits and a central database
> to connect to. As such we can say the device is always on. If we say that
> this is a service provided by a private company then only some businesses
> will have it. Therefore, for power saving purposes, we can have the gun be
> turned "off" (or just in a minimal power mode) while not in those areas. I'm
> leaning more towards the former. I'm just wondering if we need to think
> about political feasibility as well as technological feasibility.

It will matter for project relevance. If you assume unrealistic or
improbable scenarios to force-fit your use cases to fit your design,
you're going about it backwards. Indulging in the fantasy of this being
government mandated is making an assumption that if it were not to happen,
would render your work irrelevant.

Better to work within existing parameters and norms and roles: rural usage
of firearms, urban and suburban law enforcement, building and campus
security, mobile asset protection (ie. Brinks trucks), military and
special operations, and others that escape me, oh wait ... hunting.

This is the sort of stuff you should talk about with Jackie Ego at the Gun
Room. She knows about all kinds of gun usage scenarios and would be able
to suggest how to narrow the scope of your project to be doable within the
8-month to one-year time frame.

Consider analogies to your current design goals:

Airplanes have a black box that logs airplane telemetry and position and
so on so that enough information exists to reconstruct what happened. It
is physically secure, but does not make use of wireless or cloud
infrastructure ... you make a gun with a "tamper proof black box" and you
can then use it outside of wifi-enabled areas.

5th generation fighter planes have built-into them new co-operative
abilities to increase sensor-based situational awareness. This means that
you have several airplanes all communicating with each other covertly and
sharing their sensor data with the other planes. This enables each pilot
to have a more complete view of the entire battle space than if they
relied on their sensors alone. There are limitations to satellite and
AWACS (airborne warning and control system) aircraft can provide in some
cases ... similarly you could have a "network of guns" that might be able
to share data with other guns in some way, such as when a gun is fired,
the other guns will know the time and location of the gun being fired, and
so their authorized users will know that some kind of shit is going down
such as during a hostage taking or campus attack. This will avoid the use
of radio chatter which the bad guys might be able to monitor and react to,
just like a squadron of Joint Strike Fighters or F-22's.

What kind of existing technology can be leveraged to improve C^4 ...
military doctrine of Command, Control, Communications and Computing
insofar as the design of a SmartGun is concerned, across the different
usage contexts you will encounter?

Do you remember how to do a computational decision making chart? You might
want to do a sophisticated version of this in order to compute the right
mix of functional attributes appropriate for the different usage contexts.


> Also I should mention that we've come up with a more formal motivation for
> our project: deterring gun crime in urban centers. The system is not
> particularly useful for anything other than providing accountability, and it
> wouldn't be necessary or usable in rural areas with poor (or no) internet
> capabilities and low gun crime. The major locations of gun crime are all in
> large population centers such as Baltimore.

I made my comments above without reading this paragraph.

If you limit your project to the scope of recording gun telemetry at the
time it is fired, then it will primarily be about providing accountability
in terms of the good guys who use it ... but you can do more ...

Well consider the ecosystem in which your SmartGun will exist. Lots of
dumb guns wielded by even dumber bad guys. Give these wretches some
thoughts in terms of how the SmartGun can help make them sorry for taking
the path of unrighteousness.

How about adding in listeners and echo-locators on the SmartGun to help
figure out where a bad guy is firing from, assuming the hooligan does not
get off a lucky shot and take the good guy down?

Again you need to enumerate the various usage scenarios and misusage
scenarios in order to find that mix of features in terms of sensors and
on-board processing that could then either be uploaded to a database or
cloud or sent to other SmartGuns in the vicinity to provide greater
situational awareness.

Do whatever you've go to do to consider as many scenarios as possible.

> 2. You mentioned earlier that you met someone at the bow shop that is
> willing to help. Can you send me her information so I can call/email her?

The Gun Room ... Jackie Ego ... nice lady. The info is at home, but I
would like to go with you to help facilitate the introduction. Problem is
that I will be out of town this one weekend, because my sister is visiting
my parents, and is also expecting her first baby, and I did commit to
being there this Saturday.

I suggest in the meanwhile that you uphold Waterloo style efficiency and
prepare a set of questions and topics for discussion so that you can make
the most of your visit to her. I will also offer her some money for her
consulting time, as a gesture of respect, even though she might politely
refuse it. In any case, you will have to acknowledge her support in some
way for your project because without her, we'd be flying blind. She can
help reduce the search space of permutations down to something manageable,
then you do your use cases, and then your computational decision matrix,
and go from there.

> 3. We're planning on having at least 2 meetings per week. We'd like to have
> one of those meetings with you so we can all be on the same page, and we can
> get problems out of the way early. Is this alright with you? What time is
> best for a regular meeting?

At the beginning, this is OK, but remember I have 240 students in ECE 155,
am taking a course, doing ASIC Team tutorials, and helping with a robotic
vision system this term ... so my time needs to be rationed. It is
imperative that a decent plan be formulated so that the tasks to be done
are distilled easily from the project plan. I will have to get back to you
in terms of regularized meeting times.

(S)