In a normal conversation between two parties, say A and B, four possible events can happen: 1) Both A and B talk 2) A talks and B is silent 3) A is silent and B talks 4) Both A and B are silent
I would like to create a text file where I report in which state the conversation is, for every time window of some milliseconds.
In particular, I would like to know if there is already a repository for this [based on a number of sample conversations] and, if not, how I can do this, since I do not have much experience in this kind of things (or if I can use an application for it).
Suppose we assume that the parties speak at same pitch through out, you could use a pitch determination algorithm to identify the users individual pitch and then compare it at all frames.
Related
At a high level, I would like to set up an action that has some required inputs and some optional ones. After the user begins, he/she will be prompted for any required inputs that are missing. If/when the required inputs are collected, i would like to ask if the user wants to specify more optional inputs.
The specific use case is a voice-based real estate search. I have some required inputs set up like zip code, price, and number of bedrooms. Then I would like bixby to ask "would you like to refine your search even further?" and if the user says yes, we can ask about number of bathrooms, parking arrangements, and other more niche parameters. I do not want to make all of these required and have to prompt everyone if they want to filter by "pools" or some parameter not widely used. And being voice-based, I do not want to just have it as a checkbox on the screen because someone on the speaker won't be able to use that parameter then.
I have thought of 2 potential solutions but I do not know if they will work (at least without relying on the controls on screen for a voice-based capsule):
1) Make the search into a transaction and then instead of a normal confirmation, try to shoe-horn the confirmation to ask if the user wants to add more refinements. Maybe something like the bank transfer one but a negative confirmation would cause bixby to ask for information that she didnt ask for before: https://bixbydevelopers.com/dev/docs/sample-capsules/walkthroughs/simple-transactional#sample-capsule-walkthrough
2) Make 2 more required inputs, one boolean called "WantsOptionalParameters" and the other called "OptionalParameters" that will be a structure containing all of the optional parameters. Then it would prompt for WantsOptionalParameters like a normal required input, and if that is "True", I can have a sub-action that will ask for each one of the parameters to construct an OptionalParameters object. then we could feed that output into the search. And alternatively, if WantsOptionalParameters is false, we can automatically construct OptionalParameters with all negative responses and feed that into the original action.
Both of these solutions will take a bunch more research and testing and i don't even know if they will work, so i was hoping to call on the wisdom of you guys!
Here is my take on it for what its worth. Every domain has key inputs that are typically used to start the conversation and optional inputs that can refine the conversation.
Some general ways to start conversation for the real estate example (totally driven by my own experience, perhaps there are more)
Hows the real estate market in 90210?
Show me homes under $250K in Los Angeles?
Show me homes with 4 bedrooms (near me?)
You can club such inputs into an input-group called RequiredInputs that requires OneOrMoreOf these parameters to get the capsule started.
You can also collect the optional/niche inputs in another input-group called OptionalInputs that requires ZeroOrMoreOf and feed them into your capsule logic
Its also possible that all inputs are equally important and are all Optional! It is totally dependent on the domain and how the capsule developer might handle such inputs.
But in a general sense, once the set of inputs is in and the initial results are shown to the user, the capsule developer then has a great amount of control to
Shape the future conversation AND
Highlight capsule capabilities.
So, rather than presenting the user with a set of options, you can control the conversation and offer options that provide most value to the user (and to the capsule developer!)
e.g your capsule is capable of deep analyzing and refining results in a way that no other capsule on the market can do. So, you want to highlight this capability as the first choice via followup
Or You may have a conversation path based on prior experiences and your knowledge of the domain. So, you could say, I can refine the results further by X, Y, Z options.
This scenario is more likely to be useful and less likely to overwhelm (with options) the end user.
Hope this helps!
my graduate project is about Smart Attendance System for University using RFID.
What if one student have multiple cards (cheating) and he want to attend his friend as well? The situation here my system will not understand the human adulteration and it will attend the detected RFID Tags by the reader and the result is it will attend both students and it will store them in the database.
I am facing this problem from begging and it is a huge glitch in my system.
I need a solution or any idea for this problem and it can be implemented in the code or in the real live to identify the humans.
There are a few ways you could do this depending upon your dedication, the exact tech available to you, and the consistency of the environment you are working with. Here are the first two that come to mind:
1) Create a grid of reader antennae on the ceiling of your room and use signal response times to the three nearest readers to get a decent level of confidence as to where the student tag is. If two tags register as being too close, display the associated names for the professor to call out and confirm presence. This solution will be highly dependent upon the precision of your equipment and stability of temperature/humidity in the room (and possibly other things like liquid and metal presence).
2) Similar to the first solution, but a little different. Some readers and tags (Impinj R2000 and Indy Readers, Impinj Monza 5+ for sure, maybe others aswell) have the ability to report a response time and a phase angle associated with the signal received from an interrogated tag. Using a set up similar to the first, you can get a much higher level of reliability and precision if you use this method.
Your software could randomly pick a few names of attending people, so that the professor can ask them to identify themselves. This will not eliminate the possibility of cheating, but increase the risk of beeing caught.
Other idea: count the number of attendiees (either by the prof or by camera + SW) and compare that to the number of RfID tags visible.
There is no solution for this RFID limitation.
But if you could then you can use Biometric(fingerprint) recognition facility with RFID card. With this in your system you have to:
Integrate biometric scanner with your RFID reader
Store biometric data in your card
and while making attendance :
Read UID
Scan biometric by student
Match scanned biometric with your stored biometric(in the card :
step 2)
Make attendance (present if biometric matched, absent if no match)
Well, We all have that glitch, and you can do nothing about it, but with the help of a camera system, i think it would minimise this glitch.
why use a camera system and not a biometric fingerprint system? lets re-phrase the question, why use RFID if there is biometric fingerprint system ? ;)
what is ideal to use, is an RFID middleware that handle the tag reading.
once the reader detects a tag, the middleware simply call the security camera system and request for a snapshot, and store it in the db. I'm using an RFID middleware called Envoy.
Actually arrival is pretty simple, tag gets into a range of receivers antenna, but the departure is what is causing the problems.
First some information about the setup we have.
Tags:
They work at 433Mhz, every 1.5 seconds they transmit a "heartbeat", on movement they go into a transmission burst mode which lasts for as long as they are moving.
They transmit their ID, transmission sequence number(1 to 255, repeating over and over), for how long they have been in use, and input from motion sensor, if any. We have no control over them whatsoever. They will continue doing what they do until their battery dies. And they are sealed shut.
Receiver forwards all that data + signal strength of a tag to our software. Software can work with several receivers. Currently we are using omnidirectional antennas.
How can we be sure that the tag has departed from premises?
Problems:
Sometimes two or more tags transmit "heartbeat" at the same time and no signal is received. With number of tags increasing these collisions happen more often, this problem is solved by tags randomly changing their heartbeat rate (in several milliseconds) to avoid collisions. Problem is I can't rely on tags not "checking in" for a certain period of time as sign of departure. It could be timeout because of collisions. Because of these collisions we cannot rely that every "heartbeat" will be received.
Tag manufacturer advised that we use two receivers and set them up as a gate for tags to pass through. Based on the order of tags passing through "gates" we can tell in which direction they are going. The problem with our omnidirectional antennas is that sometimes tag signal bounces of building and then arrives to receiver. So based on signal strength it looks like its farther away then it is.
Does anybody have a solution of what we can do to have a reliable way of determining if tags are coming or leaving? Also we can setup antennas in different way as well.
I wrote the software that interprets data from receivers, so that part can be manipulated in any way. But I'm out of ideas of how to interpret information to get reliability we need.
Right now the only idea is to try out with directional antennas? But I would like to tryout all the options with the current equipment we have.
Also any literature suggestion that deals with active RFID tags is more than welcome, most of books I've found deal with passive tag solutions.
As a top level statement, if you need to track items leaving your site, your RFID technology is probably the wrong one. The technology you have is better suited to the positional tracking tags within a large area - eg a factory floor. Notwithstanding the above, here is my take:
A good approach to active RFID is to break your area down into zones that are tied to your business processes, for example:
Warehouse
Loading bay
Packing
Entry of a tag into a zone represents the start of a new process or perhaps the end of a process the tag is currently in. For example, moving from warehouse to the packing represents assembling a shipment, and movement into the loading bay initiates a shipment.
The crux of many RFID implementations is the installation and configuration of the RFID intrastructure to:
Map tag -> asset (which you have done)
Map tag read -> zone (and by inference asset -> zone)
Map movements between zones to steps in a business processes (and therefore understand when an asset leaves the site, your goal)
There are a number of considerations: the physical characteristics of 433MHz signals, position of antennae, sensitivity of antennae and some tricks that some vendors have. After an optimal site configuration, then you may need to have some processing tricks on the tag reads that will pour in.
Dirty data
Always keep in mind that tag read data is dirty - that RF interference (from unshielded motors, electric wiring, etc), weather conditions and physical manipulation of tags (eg covering with metal) happen all the time.
RSSI's are like stock tickers - there is a lot of random/microeconomic noise on top of broad macroeconomic trends. To interpret movement, compute the linear regression of groups of reads rather then rely on a specific read's RSSI.
If you do see a tag broadcasting with a high RSSI, which then falls to medium then low and then disappears, you really can interpret that as the tag is leaving the range of the receiver. Is that off-site? Well, you need to consider the site's layout (the zones) and the positioning of receivers within the zones.
TriangulationTrilateration
EDIT I had incorrectly used the term 'triangulation'. This refers to determining the position of something by known the angle it subtends from two or three known locations. In RFID, you use the distance and as such it is called 'trilateration'.
In my experience, vendors selling the tag technology you describe have server software that determines the absolute position of the tags using the received RSSI. You should be able to obtain the position of the tag within 1-10m using such software. Determining if the tag is moving off-site is then easy.
To code this yourself:
First, each tag is pinging away when moving. These pings hit the receivers at almost the same time and sent to the server. However the messages can sometimes arrive out of order or interleaved with earlier and later reads from other receivers. To help correlate pings, the ping contains a sequence number. You are looking for tag reads from the same tag, with the same sequence number, received by three (or more) receivers. If more than three, pick the three with the largest RSSI.
The distance is approximated from RSSI. This is not linear and subject to non-trivial random variation. A quick google turns up:
Given three approximate distances from three known points (the receivers' locations), you can then resolve the approximate position of the tag using Trilateration using 3 latitude and longitude points, and 3 distances.
Now you have the absolute position of the tag. You can use these positions to track the absolute movement of the tag.
To make this useful, you should position receivers so that you can reliably detect tags right up to the physical site boundaries. You should then determine a 'geofence' around your site, within receiver range. I would write a business rule that states:
If the last known position of a tag was outside the geofence, and
A tag read from the tag has not been detected in (say) 10s, then
Declare the tag has left the site.
By using the trilateration and geofence, you can focus the business logic on only those tags close to going awol. If you fail to receive your 1.5s ping only a few times from such a tag, it's highly likely that the tag has gone outside your receiver's range, and therefore off-site.
You're already aware that tag reads can sometimes come from reflections. If you have a lot of these, then your trilateration will be pretty poor. So this method works best when there are fairly large open spaces and minimal reflectors.
Some RFID vendors have all this built into their servers - processing this by writing your own code is (clearly) non-trivial.
Zone design using wide-area receivers
Logical design of zones can help the business logic layer. For example, suppose you have two zones (A and B) with two receivers (1 and 2):
A B
+----------+----------+
| | |
| 1 | 2 |
| | |
+----------+----------+
If you get tag reads from the tag at receiver 1, then one at receiver 2, how do you interpret that? Did tag T move into zone B, or just get a read at the extreme range of 2?
If you get a later read at 1, did the tag move back, or did it never move?
A better physical solution is:
A B
+----------+----------+
| | |
| 1 2 3 |
| | |
+----------+----------+
In this approach, a tag moving from A to B would get reads from the following receivers:
1 1 1 2 1 2 2 3 2 2 3 2 3 3 3 3 3
-------> time
From a programming logic point of view, a movement from A -> B has to traverse reads 1 -> 2 -> 3 (even though there is a lot of jitter). It gets even easier to interpret when you combine with RSSI.
Portal design with directional receivers
You can create quite a good portal using two directional receivers (you will need to spend some time configuring the antenna and sensitivity carefully). Mount a receiver well above the door on both sides. Below is a schematic from the side. R1 and R2 are the receivers (and the rough read field is shown), and on the left is a worker pushing an asset through the door:
----> direction of motion
-------------------+----------------
R1 | R2
/ \ | / \
o / \ / \
|-++ / \ / \
|\++ / \ / \
------------------------------------------
You should get a pattern of reads like this:
<nothing> 1 1 1 1 1 12 1 21 2 12 2 1 2 2 2 2 2 <nothing>
-------> time
This indicates a movement from receiver 1 to receiver 2.
"Signposts"
Savi implementations often use "sign posts" to assist with location. The sign post emits beam that illuminates a small area (like a doorway) in a 123KHz beam. The signpost also transmits a unique number identifying itself (left door might be 1, while the right door might be 2). When the tag passes through the beam, it wakes up and re-broadcasts the number. The reader now knows which door the tag passed through.
Watch out for any metal in the surrounding area. 123KHz travels extremely well down rebar in concrete walls, metal fences and rail tracks. We once had tags reporting themselves hundreds of meters from a signpost due to such effects.
With this approach you can implement a portal much like you would for passive.
Simulating signposts
If you don't have the ability to use signposts, then there is a dirty hack:
Stick a passive RFID tag to your active RFID tag
Install a passive RFID reader on each doorway
Passive RFID is actually very good in restricted spaces, so this implementation can work very well. This solution may be the same cost (or cheaper) than with your active RFID vendor.
If you're clever, you can use the EPC GIAI namespace for the passive tag ID and so burn it with the active tag ID. Both active and passive tags would then be identically named.
Physical considerations
433MHz tags have some interesting characteristics. Well-constructed receivers can get a read of tags within about 100m, which is a long way for RFID. In addition, 433MHz wraps itself around obstacles very well, especially metal ones. We could even read tags in the boot (trunk) of a car travelling at 50km/h - the signal propagates from the rubber seal.
When installing a reader to monitor a zone, you need to adjust its location and sensitivity very carefully to maximize the reads from tags within your zone, but also to minimize reads from outside your zone. This might be done in HW or in SW configuration (like dropping all reads below a particular RSSI).
One idea might be to move the receiver away from the area where your tags are exiting as in the layout below (R is the reader):
+-------------------------+-----------+
| Warehouse | Exit |
| . |
| .
| R . R --->
| .
| . |
| | |
+-------------------------+-----------+
It pays to do a RF site survey and spend enough time to properly understand how tags and readers work in an area. Getting the physical installation right is critical.
Other thing to do is to consider physical constrictions such as corridors and doorways and treat them as choke-points - map logical zones to them. Put a reader (with directional receiver tuned to cover the constriction) and lower sensitivity in to cover the constriction.
What no tag-reads actually means
If my experience of RFID has taught me anything, it is that you can get spurious reads at any time, and you need to treat everything with a degree of suspicion. For example, you might have a few seconds of missing reads from a given tag - this can mean anything:
A user accidentally putting a metal tin over the tag
A fork lift truck getting between tag and reader
An RF collision
A momentary network congestion
The battery dying or fading out (remember to check the low-battery flag in tag reads and ensure the business has a process to replace old tags).
Tag destroyed by a pallet being pushed into it
Stollen by someone wanting to resell it for scrap (Not a joke - this actually happened)
Oh yeah, it may be that the tag moved off-site.
If the tag has not been heard of in, say, 5 minutes, odds are that it's off site.
In most business processes that you would use this active tag technology for, a short delay before the system decides the tag is off-site is acceptable.
Conclusions
Site survey: spend time experimenting with readers in different locations. Walk around the site with a tag and see what reads you are actually getting. Use this to:
Logically segment your site into zones and locate receivers to most accurately position tags in zones
It's easier to determine movement between zones using several receivers; if possible, instrument physical constrictions such as doors and corridors as portals. As part of your RFID implementation, you might even want to install new walls or fences to create such constrictions. Consider a passive RFID for portals.
Beware of metal, especially large expanses of it.
You have dirty data. You need to compute linear regressions on the RSSIs to spot trends over short periods; you need to be able to forgive a small number of missing tag reads
Make sure that there are business processes to handle dying batteries and sudden disappearances of tags.
Above all, this problem is best solved by getting the receivers installed in the best locations and configuring them carefully, then getting the software right. Trying to solve a bad site installation with software can cause premature ageing.
Disclosure: I worked 8 years for a major active RFID vendor.
Using directional antennas sounds like it may be a more reliable option, although this obviously depends on the precise layout of your premises.
As far as using your current omnidirectional receivers, there are a couple of options I can think of:
First one, and likely easiest, would be to collect some data on the average 'check-in' times you are seeing for on-site tags, possibly as a function of the number of on-site tags (if the number is likely to change dramatically - as your collision frequency will be related to the number of tags present). You can then analyse this data to see if you can choose a suitable cut-off time, after which you declare that a tag is no longer present.. Obviously exactly what cut-off you choose will depend on the data you see and your willingness to accept false positives - it could also be that any acceptable cut-off time lies outside your 3 minute window (although I suspect that if that is the case then your 3 minute window may not be viable).
Another, more difficult, option (or group of options more like), would be to utilise more historical information about each tag - for instance, look for tags whose signal strength gradually decreases and then disappears, or tags whose check-in time changes drastically, or perhaps utilise multiple receivers and look for patterns between receivers - such as tags which are only seen by one receiver and then disappear, or distinctive patterns of signal strength (indicating bearing) between receivers as tags go off-site.
Obviously the second option is really about looking for patterns, both over time and between receivers, and is likely to be much more labour (and analysis) intensive to implement. If you are able to capture enough good quality data you might be able to utilise machine-learning algorithms to identify relevant patterns.
We do this every day.
First question is: "How many tags do you have at a reader at any given time?". Collisions are more rare than you might think, but they do happen and tag over-population can be easily determined.
Our Software was written and might be using the same readers and tags that you are using. We set reader timeouts to determine when a tag is "away" or "offsite"; usually 30 seconds without the tag being read. Arrival of course is instantaneous when a tag is detected at the reader, then the tag is flagged "onsite".
We also have the option to use multiple readers; one at a gate and another on the parking lot or in the building for example. The gate reader has a short timeout. If a tag passes the gate reader, it is red and then times out very quickly to flag the tag as "offsite". If a tag is then read by any other reader, the tag is then considered "onsite".
I can post links if you think it would be helpful, else you can search for RFID Track. It's iOS App and there are settings posted for a demo server.
Peter
I'd like to collect some kind of geographical information from website users - for given set of data they will mark checkbox indicating whether place has or has not given property. Are there any tools/frameworks for detecting fraud or spam submissions based on whole colected data set (and possibly other info)? I'd like to get filtered, more reliable data.
Not sure if that's exactly what you're asking for, but here are some tips from my experience using Amazon Turk:
There are several academic papers dealing with such problems. here is a good one.
In addition, based on the following general recommendations, I've created a custom procedure which worked on my data:
a. Include an open question, and filter out cases where it wasn't answered. It's harder to answer such a question automatically, and it might also be more time-consuming, thus less attractive, for a fraudster.
b. If possible, don't use a binary scale (i.e. a checkbox), but some grade (e.g. 1-4 or 1-6). This would give you more data to work with.
c. If available, filter out cases where the time spent in filling your form was too short. (especially useful if you include that open question)
d. If you have multiplicity of inputs per user, check for repetitive answers, and for users which consistently give far-from-average answers.
If each user submits only a single "form", consider putting more than a single element/question in it, so you'll get multiple submissions per-user.
e. If you have only a single submission per user or user-id, your options are more limited. I can suggest filtering out outliars, (e.g. data points farther than 3 standard deviations from the average), in case you have enough data.
f. After all the filtering, check the agreement or disagreement in your data (e.g. by checking what proportion of your data points fall within x standard deviations from the average). In case of agreement, use the average; in case of disagreement, collect some more data.
Hope it helps,
is there any way to accomplish the following?
I would like for each object in Plone would be associated with one more security classifications (e.g. 'alpha', 'bravo', 'zulu'). These classifications would be part of the content type's schema. At runtime, the user's security credentials would be compared against the object, and if and only if the user had all the credentials of the object would the object be viewable. I can't see any way of doing this in workflow.
Open to suggestions. Thanks!
Stan
You need a localrole adapter that can examine the user's credentials (presumably you already have some one to give them such credentials, as - beyond the basic concept of roles - they don't exist in base Plone), and grant a local_role based on the result.
See: http://plone.org/products/plone/roadmap/208.
It might be as simple as providing an __ac_local_roles() method, but if not, borg.localrole is now part of Plone and that link should get you started.
Bear in mind that CMFWorkflow allows for an object to have more than one workflow associated with it. It might be possible for you to implement the various levels of your scheme as individual workflows and then attach them to your objects.
Here is also how you could do it with workflow. Note I am not saying you should do it with workflow, just that you can ;)
You would need a (large) number of states. How large depends on the combinations (!=permutations) of your security states. The combinations of choosing m things among n things is given by:
n!/(m!(n-m)!),
where ! is the factorial.
For instance for the example you give you have 3 security states alpha, bravo and zulu. This gives:
3!/(1!2!) + 3!/(2!1!) + 3!/(3!0!) = 3 + 3 + 1 = 7
The sum is the combinations of having 1, 2, or 3 of them together.
So there you go, seven states all in all;)
The transitions are a different beast. If you do need to be able to go from any of these combined states to any other then you would have to calculate permutations as going from a to b is different to going from b to a. Permutations are given by:
n!/(n-m)!
i.e. for the 7 states above you would have 7!/(7-2)!=7*6=42 (!!!) transitions. You could of course simplify the transitions by only allowing adding/removing one security state each time.
There you go, I hope you have as much fun reading this as I had writing it :)