lead-ing to non-hallucination examples becoming hal-lucination ones
But I think the "Adaptive Plausibility Constraints" in VCD are there to address this. In fact, DTC uses it itself: https://github.com/JackChen-seu/Reefknot/blob/310ec0c468f7763440ca4ffb53f1fe00d9a3deb7/DTC.py#L151
λ
They mean gamma!
Table 2
Numbers are falsely swapped, see https://github.com/JackChen-seu/Reefknot/issues/2
Rscore =
Average of a sum!? Weird notation. What they probably mean: Basically the average "non-hallucination rate"
Significant probabilitychanges are observed in deeper layers
Why is it tending so much towards yes (before becoming uncertain)? Maybe the model tends to favor positive responses, as mentioned earlier being the case for another model. But I hypothesized there to be relation hallucinations with the yes and no flipped compared to the Figure. Since the plot is averaged, are those cases so rare that they do not get represented after averaging anymore?
Why does it become uncertain only once the last layers are reached? They call it sharp change in Figure 8b.
first
Should be "previous", right?
wewill utilize the hidden states from intermediate lay-ers to calibrate the final outputs layers
That assumes that the token that has high probability in the intermediate layer (e.g. yes in Figure 7) is the correct answer.
557.78±1.92
Too much distortion harms performance. Not too sure why the contrastive noise can't be too much. I mean if we take an image of completely random noise, doesn't this expose the hallucination the most? Maybe not, because the model will at some point, when there is too much noise, refuse to provide an answer?
Figure
Table
The Appendix provides a detailed analysis of the OUI and AS distribution of the WAN corpus.
Stopped reading here (bookmark)
2) constraint-based techniques that leverage speed-of-light propagation delay to triangulate an address [33, 34]; 3) network topology [29, 35];
How exactly are these different?
this would make no sense for the zero vector
Except \(\lambda=0\), which is noted above:
or equal to 0
[eigen2]
Forgotten to format as (7.1.2)
in the variable x
Actually \(\lambda\)
. Like Alidade,
bookmark (continue reading here)
2.1 GeoIP Databases
bookmark (done reading (at least continuously) until here)
Further, we identify478 instances where the phone’s cellular interface address is assigned a publicIP address but it does not match the observed IP address at the applicationserver, thus indicating the presence of middleboxes between the device and theapplication serve
Or is it simply hijacked IP space? e.g. US Department of Defense IP address space misused for private IP addresses .
If not: What would be the purpose of such middlebox? Why does it not use private IP space?
Again notice how the relation has arrows both ways
Not actually shown in video. Revision Feb 13, 2022
we can also see the relation to display another "hasChild" relation
Not actually shown in video. Revision Feb 13, 2022
n * m integers
+ m*k cluster centroids
https://dl.acm.org/doi/pdf/10.1145/3419394.3423618 :
We found in Section 6.2 that IPv6 /48 subnets appeared most similar to IPv4 addresses in their distribution of user population sizes, so existing rate limiting logic applied to IPv4 addresses could potentially be translated to IPv6 /48 prefixes
logging in a portal, VPN
Just to keep the definition open for further use cases?
Since the address changes only when a new session is established, there is no disconnection/reconnection involved.
It is, but it's done already anyway.
the probability of address duplication in a network is negligible
Duplicate Address Detection
iii) provide means for the device not to use MAC addresses it is not authorized to use or that are currently in use
Duplicate Address Detection
The randomized MAC address does not get re-randomized when the device forgets a WiFI network
Can be enabled via:
option "Wi-Fi-enhanced MAC randomization" in the developer options.
IEEE 802.11aq
So what did they do?
[rcm_tig_final_report]
Mentions some use cases you want to prevent against. (Grocery store tracking its customers)
In order to do so, a node produces a sequence of temporary global scope addresses from a sequence of interface identifiers that appear to be random in the sense that it is difficult for an outside observer to predict a future address (or identifier) based on a current one, and it is difficult to determine previous addresses (or identifiers) knowing only the present one.
It's not necessarily a sequence at all. https://www.rfc-editor.org/rfc/rfc8981.html#section-3.1-2.6
config_wifiAllowEnhancedMacRandomizationOnOpenSsids
This is the old name. See blame: https://cs.android.com/android/platform/superproject/main/+/main:packages/modules/Wifi/service/java/com/android/server/wifi/WifiConfigManager.java;l=530;drc=0b982af97721be4665bd54b0cf174f82f386c7de
$ dig @8.8.8.8 a.b.qnamemin-test.nlnetlabs.nl TXT +short "NO - QNAME minimisation is NOT enabled on your resolver :(" $ dig @8.8.8.8 a.b.qnamemin-test.internet.nl TXT +short "HOORAY - QNAME minimisation is enabled on your resolver :)!"
Glancing at the paper explains why:
This was because Google wanted to get credit for minimizing queries at the root and TLD level, which originally did not show on DNSThought statistics.
So Google literally put "internet.nl" on a special list (for qmin beyond TLD)
This clarity seems to have been lost in this article.
Further readings: https://www.ietf.org/archive/id/draft-levine-qmin-performance-01.html#name-stop-at-two-or-three
Unassigned
Actually I-Field
the next higher layer of the coordinator shall allocate a address with a rangedepending on the addressing mode supported by the coordinator
important
Figure 7-109—Association Response command Content field format
important
The Allocate Address field shall be set to one if the device wishes the coordinator to allocate a short addressas a result of the association procedure. Otherwise, it shall be set to zero.
important
The lower theTTL value associated with detection, the lower the upperlimit on topological distance to the monitor and typically, themore constrained the observer’s possible location.
You should also see multiple nonces affected by eavesdropping. I.e. hop 8 is monitored, then all nonces with TTL>=8 should be affected, since hop 8 does not only care about TTL-expired nonces. Or is only that traffic subject to monitoring, whose source IP address is the router's own? (with which it sends ICMP errors)
Edit: Sometimes, see Fig. 4
Edit see later
uniform packet sampling, irrespective of hop limit
TABLE II
They could have matched pdns to rdns. Instead of N/A
The hops that do pdns could even be doing it not by themselves but only be subject to it. So it's worth checking who resolved the pdns data. In extreme case there is a single resolver that is used by all pdns eavesdroppers.
there are routers that respond to UDP probes to or fromport 443 that did not respond to our ICMPv6 ping probes
Commonly observed in traceroutes. That routers do not send TTL-expired ICMP message when your original packet is ICMP and therefore likely a traceroute.
public DNS services
merely because they use them as resolvers, as later explained:
This strongly suggests that monitors and surveillants propagate their queries to third parties, resulting in some traffic information being disseminated to them
thenumber of peer hosts (unique remote addresses) that were thesource of the reaction
a single peer may result in multiple detections because the peer observed multiple nonces
forwarding all packets destined to addresses within that blockto the NOISE source host
"aliased IP addresses"
ownsld.cn
They should have published their domain or done themselves a lookup in pdns databases to see who contributes to these.
Further, RFC 4941 [20 ] species only that a device implementingSLAAC with privacy extensions SHOULD generate a new, randomIID each time its network changes. Our work shows that SHOULDis too weak, and the privacy goals of this standard dictate that theCPE MUST do so in order to prevent the same type of tracking usingthe randomized IID rather than an EUI-64 IID.
Updated it RFC8981:
new temporary addresses MUST be generated for use on the new link
previously in RFC4941:
a new randomized interface identifier SHOULD be generated immediately together with a new set of temporary addresses
In response, the Modified EUI-64 format was developed. This version introduces randomness into the address generation process by obfuscating parts of the MAC address, enhancing user privacy on IPv6 networks.
Factually wrong.
Abstract
A wonderfully summarizing abstract.
o "Compression Format for IPv6 Datagrams over IEEE 802.15.4-Based Networks" [RFC6282] o "Transmission of IPv6 Packets over IEEE 802.15.4 Networks" [RFC4944] o "Neighbor Discovery Optimization for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)" [RFC6775]
6lowpan
For example, [RFC6282] allows for the compression of IPv6 datagrams over IEEE 802.15.4-based networks [RFC4944] when the IID is based on the underlying link-layer address.
.
periph_hwrng
.
I don't think this paper adds value over existing RFCs like RFC7217 and RFC7721
TCP/5938
TeamViewer (they have TeamViewer IoT)
UDP/51413
BitTorrent
UDP/5060UDP/6881 (SIP)
Switched up. 5060=SIP, 6881=BitTorrent
Thus,the number of affected /56 prefixes accounts for about
You did not ignore WAN prefixes yet! Which you explicitly intend to ignore:
If the CPE device’s WAN-facing address is not within the end-user prefix, it can not be used for tracking with our methodology
and
Thus, in our methodology, the IPv6 address of the CPE is not sufficient to track the devices at home.
4.4
Stopped reading
Completely removes the ability to run ChromeOS (and ChromeOS Recovery Mode), creating a small risk of bricking your device
Im Vergleich zu nur einem Entscheidungsbäumen haben Zufallswälder den Vorteil, dass jede Variable, diezur Klassentrennung beiträgt, irgendwann auch verwendet wird.
Wie ist das gemeint? Weil angenommen wird, dass man bei einem einzelnen Entscheidungsbaum pruning verwendet, wodurch unwichtigere Variablen evtl. komplett wegfallen?
in der Bestimmung der nächsten Verzweigung ver-wendet, sondern ebenfalls nur eine Stichprobe aus den dem Baum zur Verfügung stehenden Merkmalen
Merkmalsreduktion bezieht sich auf einen gesamten Baum! Nicht Entscheidungsweise!
(b) Boosting
Das lässt boosting so aussehen, als ob es in der Anwendung nicht parallelisierbar wäre.
Falls es das Training abbilden soll, so sollte bei "Modell 3" nicht "Gesamtausgabe" stehen, sondern "Ausgabe 3". Vielleicht sollte "Ausgabe" außerdem lieber "Vorhersage" genannt werden.
max_samples: I reduce a fixed number. max_depth: I reduce an upper bound. Both are called "max", because they have default values of infinity.
we abbreviate the states high and low, and theactions search, wait, and recharge respectively by h , l , s , w , and re
Abbreviation "re" is never used
Exercise 3.12 Give an equation for v ⇡ in terms of q ⇡ and ⇡. ⇤Exercise 3.13 Give an equation for q ⇡ in terms of v ⇡ and the four-argument p. ⇤
Solution to this exercise can be later verified with definition (3.14)
RFC 6755
This is a typo and should have been RFC 6775
the following discussion
if AdvValidTime > 2 || AdvValidTime > RemainingLifetime: set to AdvValidTime
else if RemainingLifetime <= 2: ignore AdvValidTime
else: set (decrease) to 2
the last 2 lines of which can be condensed to
else: set to min(2, RemainingLifetime)
Unit: hours
The IEEE RAC is not aware of any cases, but if MAC-48 is used asthe name for any 48-bit MAC address, then EUI-48 is not the appropriatereplacement term for MAC-48, as EUI-48 only refers to individual,universally/globally unique network addresses.
Read this text with emphasis on "any". I.e. the term "MAC-48" also includes locally administered MAC addresses (U/L bit set to 1), EUI-48 doesn't.
Unfortunately, there doesn't seem to be a term like "MAC-64" to refer to same for a EUI-64.
Figure 6 depicts two /48s from the same ISP , one of which is dividedinto /56 allocations while the other is split into /64 subnets.
That's because the /64 customers are for the router IPs. WAN link: https://www.ripe.net/publications/docs/ripe-690/#4-1--numbering-the-wan-link--interconnection-between-the-network-and-the-end-user-cpe-
Figure 4 displays two Versatel 1&1, a German consumer ISP, /48s withdifferent customer allocation strategies.
However, the CPE rarely knows that before the reboot there was a different prefix on the network, and the packets to revoke the old IPv6 addresses do not get sent.
Directly related: https://www.rfc-editor.org/rfc/rfc8978.html https://datatracker.ietf.org/doc/draft-ietf-6man-slaac-renum/
Source: some CDN and RIPE Atlas. they can detect dual stack Figure 1: assignment durations Figure 6,7: What prefix lengths ISPs delegate
a personal firewall at the target host would not be able to mitigate this probing technique
Couldn't the personal firewall just respond with the same ICMP messagt to unsolicited packets? Although it would still decrease the hop count by one. But the sender (the personal firewall) can just increase the hop limit by that number.
rationale for looking treating the preference as a signed rather than unsigned value
Maybe they wanted "00" to be the default. For no special reason...
MAX_DESYNC_FACTOR
Linux (according to sysctl doc) just uses 600 seconds (as absolute value, probably derived from 0.6 * TEMP_PREFERRED_LIFETIME) as default value for this. The RFC doesn't even allow changing it.
lifetime of an address should be further reduced when privacy-meaningful events (such as a host attaching to a different network, or the regeneration of a new randomized Media Access Control (MAC) address) take place
Isn't the address deleted in an event of a network disconnect anyway? Hmm, Linux has keep_addr_on_down sysctl option.
REGEN_ADVANCE
``` 2s + (3x * (1x * 1s)) = 2s + 3s = 5 seconds
values from the referenced documents: DupAddrDetectTransmits: default: 1x RetransTimer: default 1s Ethernet doesn't override any of these values ```
8981
The following concepts are used before they're explained. - DESYNC_FACTOR - REGEN_ADVANCE
It MUST be smaller than (TEMP_PREFERRED_LIFETIME - REGEN_ADVANCE).
For the same reason as https://datatracker.ietf.org/doc/html/rfc8981#section-3.4-3.5
except for the transient period when a temporary address is being regenerated
!
at the expense of making the corresponding IPv6 addresses dependent on the underlying network interface card (i.e., the corresponding IPv6 addresses would typically change upon replacement of the underlying network interface card)
If that's a problem, use DDNS.
restricted space of IEEE EUI-64 addresses
This mapping for non-EUI-64 identifiers differs from that presented in Appendix A of [RFC4291].
But this mapping is used here because it is used in https://datatracker.ietf.org/doc/html/rfc4944#section-6:~:text=if%20no%20PAN%20ID%20is%20known
16-bit short addresses (Section 3 and Section 12) are also possible
And their usage defined in this document overrides https://datatracker.ietf.org/doc/html/rfc4291#:~:text=Links%20with%20Other%20Kinds%20of%20Identifiers
Note that the check against the prefix performed at the beginning of this step cannot always detect the address conflict in the list. It could be possible that an address already in the list, configured either manually or by DHCPv6, happens to be identical to the newly created address, whereas such a case should be atypical.
So different prefix but resulted in same address
race conditions when more than one node is trying to solicit for the same address at the same time
i.e. both nodes failing DAD, so none of them using the tentative addr. (defined as DAD failure in section 5.4.3, last bullet)
Temporary Stateless Addresses Auto-configuration
Not more info than in the RFC
becomes invalid in less than 1 second
Explanation:
TEMP_VALID_LIFETIME - TEMP_PREFERRED_LIFETIME < 1 second
In this mentioned unfortunate case, the connection would be made less than 1 second before expiry.
Full context: It would, upon expiry of the valid lifetime, just never enter a deprecated state, where it could keep existing connections open, but be immediately deleted.
lifetime of temporary addresses must be statistically different for different addresses
Implemented as DESYNC_FACTOR
implementations MUST NOT employ the same secret_key for the generation of stable addresses [RFC7217] and the generation of temporary addresses via this algorithm
So another secret to store
and against those IIDs already employed in an address of the same network interface and the same network prefix
don't forget
limits the time window
Although if you're continuously monitoring, chances are high you can even track IP address changes.
Assuming that - there are only so many devices that at most one at a time is detected to have changed its IP address. - it's the same device, not a new one.
(e.g., at random)
e.g. IPv6 over PPP https://datatracker.ietf.org/doc/html/rfc5072#page-14
methods for choosing the tentative interface identifier
:
If a good source of uniqueness cannot be found, it is recommended that a random number be generated.
a client whose address cannot be mapped into a DNS name that also maps back into the same address
called FCrDNS
some servers
e.g. mail servers
an address does not reliably identify a particular device over time spans of more than a few minutes
Or rather however long their dial-up line session is
Figure 11 shows that the resolvers that account for 50% of theIPv6 ingress set have relatively close number of IPv4 and IPv6egress addresses; the left 50% resolvers have more IPv4 egress IPaddresses than IPv6 egress IP addresse
Only Figure 12 shows that this is indeed the distribution (for 99%)
Otherwise, I think that's only one possible distribution matching Figure 11. And still, like the author's mentioned analysis of Figure 9, under assumption of equal distribution.
under the premise of resolverswith the same proportion
"Under premise of equal distribution (of both groups: IPv4 and IPv6)" - Interesting wording and probably the only one you can make from an ECDF graph.
Figure 10 actually conveniently shows that this conclusion (under the simplifying assumption) is false, as ~1% resolvers have >50% IPv6-to-IPv4 ratio (p99 = 0.5).
Figure 9
Description: The graph shows that resolvers overall have more IPv4 than IPv6 egress IP addresses. - ~99% of resolvers have about at most 10 IPv6 addresses only. - The top 20% of resolvers with most IPv4 egress addresses have >80 IPv4 egress addresses.
Numbers
"Amount" is more appropriate word
6
So far, the paper has interesting references
rule definitions for network packets that were found to be miscategorized by nDPI
Spoiler: Was just Tor IP addresses on a shared cloud netblock (Akamai).
Third and finally, for privacy and security reasons, these sites may need to be restricted or even blocked on some networks with high security requirements.
The paragraph continues to elaborate on the impact of data breach of a consumer business website. However, blocking these websites from the company network wouldn't help prevent this data breach. -> Going offtopic
In addition, there were different domain names and IP addresses obtained with the nslookup method, although they did not appear in the Wireshark results.
Probably because of load balancing
name of the organization
That's WHOIS data (inetnum)
it did not return IP addresses
Because WHOIS was used when DNS should have been used.
This suggests signal for malicious detection in activeDNS’s non-routable IPs.
Really unclear to me why they went into detail on these malware domains. - It just seems a coincidence that these domains resolve to bogons. - Identifying active infections is impossible with active DNS.
don
Typo, should be "don't swap"
The remainder of these domains provideinteresting cases for further study.
Could these be domain transfers?
Using this information, we were unable to uncover amuch larger set of malicious domains, allowing us to actively warnpotential targets.
Attackers fault for token reuse
for files that are gigabytes long
This being a convenient special case where you know the expected amount of payload data ahead, but oftentimes you don't know (e.g. TCP connection reuse).
But you could always redirect on start of the connection.
(I didn't read further, though.)
libprotoident [7], UPC [8], L7-filter [9], and TIE [18]limit their scope to protocol identification
also references [8] and [9] are interchanged
nDPI is prettyaccurate, even more accurate than PACE, the commercialversion of the old OpenDPI library on which nDPI is based
;D
googlesyndacation
Typo, meant syndication
decoderfor SSL that extracts the host name of the contacted server
read "decoder for TLS SNI"
(1)
They meant "(4)"
lack of uptake of IPv6
:(
it is infeasible to exhaustively determine RTTs fromall Google PoPs to all authoritative name servers for domainsfor which our test server is also authoritative
Because of amount of various zones, i.e.
The SURFnet name server we used is authoritative for approximately 10,000 DNS zone
Otherwise, for a single zone it's possible:
e.g. gov.uk NS -> IP addresses (v4/v6) are only 3 ASs, one of which is AS1103/SurfNet itself. The others ones being (and their looking glass being): - AS786/Jisc (lg.ja.net) - AS702/Verizon (see PeeringDB for LG. Even though Verizon has multiple ASs, this particular AS is selectable as location from the LG)
Re-check whenever Google changes its PoP prefixes.
IP2Location dataset to map the ECS IPprefix to a country, as well as to coordinates
Smells inaccurate, even at country level
protocol
transport layer protocol, not application layer protocol
first 20 payload bytes in each direction
For comparison: libprotoident does the first 4 bytes per direction
overridden
Actually, added
only allows one phone number per account
You mean "one account per phone number"
This whole document feels like it could have been written more compactly.
yet none of these domains’ MX records matches thedecoded TXT record
Discussed here (esp. this observation at this comment): https://serverfault.com/questions/1068301/base64-encoded-mx-records-in-txt-records#comment1393364_1068307
15 other internationalizedccTLDs run by India
Filter term "National Internet Exchange of India" at https://www.iana.org/domains/root/db
(alternative 3rd party front: https://research.domaintools.com/statistics/tldpedia/) Also listed at https://en.wikipedia.org/wiki/.in#Internationalised_domain_names_and_country_codes
fixed this inconsistency on 2019-11-02 (we analyzed DNSOARC’s root zone file repository [4]).
Can also be seen here visualized https://dns.coffee/zones/in
either if thename server information retrieved and used in the following query is the oneprovided by the child, BIND caches the data from the paren
(Grammar: Probably meant "even though" instead of "either if")
I.e. if you query for "A" RR, BIND will - first query P(NS) (by the notation used in Table 4) (this query being as usual) - store this, P(NS), in cache - then query P(NS) for "NS" RR (query for C(NS)) - not store this, C(NS), in cache - then query on these NSs (C(NS)) for "A" RR (C(A)).
it sends the parent an explicit NS query beforeperforming the A query. This is not a bad behavior, i.e., it does not violate RFCs,instead it tries to retrieve more authoritative information.
They probably meant "it sends the child an explicit NS query".
Seems so: - This word makes sense esp. in conj. with the provided reason "to retrieve more authoritative information". (Since there are only parent and child involved, the child being more authoritative since it is the actual nameserver in question) - And also: "the name server information retrieved and used in the following query is the one provided by the child" - whole logic of the remaining 8 line paragraph block
It doesn't matter how the resolver asks the parent for the auth. nameservers. As long as they get them, that would not affect the result of this experiment. (How the resolver asks would be rather related to QNAME minimization.)
he small number of child-centric resolversshown in §4 with Minimal Responses
referring to §4.1 "Disjoint Parent and Child NSSet"
Only about 40 vantage points receive data from the name servers in the child NSSet, indicating their resolvers likely performed explicit NS queries.
And shortly before, the setup was explained:
Only if resolvers perform explicit NS queries will they learn about [ns2,ns4].
([ns2,ns4] being said child NSSet)
or because some probesshare upstream cache
Not entirely sure what sharing upstream caches means. Just a shared cache (when resolver IPs belong to the same resolver service)? If so, the "or" is probably meant as "and possibly".
unresponsive nameservers
Server responds REFUSED status code (code 5) or does not respond at all if there is no DNS server anymore
results in improper load balancing among the name servers
I think this only applies to case (ii)
Case (ii) may lead to unresponsive nameservers
I think they meant case (iii)
different responses from the Google Public DNS resolvers based on the domain
It's just nlnetlabs.nl vs internet.nl, why does this cause a different behavior?
Farsight - the Public Benefit Company that works to sustain the spirit of the Internet
...
if the model refuses to stop on red light, how can we know if it successfullydetects the red light and the stop line
They do have this feature vector output of the vision model (link), but still:
This feature vector is uninterpretable to us
In the end, for their problem, they used "KL-divergence loss" to filter out simulator artifacts (direction of image warp) from the feature vector, at train-time. This does not seem applicable for this case, though.
suppose that the leading vehicle is moving slowly. For human drivers, we can choose toovertake it or not, which leads to at least two possible trajectories. Then, how can we decide whichtrajectory is better and force the model to learn it?
"We use a type of MHP loss, to make sure the model can predict multiple possible trajectories." - https://blog.comma.ai/end-to-end-lateral-planning/ (cites [17])
Doesn't this cover it?
the WARP mechanismwill introduce image artifacts
https://blog.comma.ai/end-to-end-lateral-planning/:
For any large movements this seriously distorts the images
0.033 seconds
1/30 of a second, i.e. 1 frame
In this way, the model will not even have the chance to learn how to recover frommistakes. For example, if we manually feed a video sequence where the vehicle is going over thecenter line, which of course is a kind of dangerous driving, the model is likely to predict a trajectorythat keeps going straight, instead of returning to the correct line.
Assumption or tested? Explained in comma.ai blog that is referenced in footnote (link):
a model that just predicts a human’s most likely trajectory does not predict how to recover from mistakes
They mean the model wouldn't even find back onto lane through the lane markings because it wasn't trained with such cases?
Comma.ai’s blog
Namely here: https://blog.comma.ai/end-to-end-lateral-planning/ ("we just apply a simple warp to the image")
Openpilot loses the leading target when following a vehicleto turn, because the leading vehicle quickly vanishes
😄
Openpilot maynot handle it well and may alert the human driver to take control of the vehicle
Afaik, it's not because openpilot misplanned something, it just expects the driver to help in applying steering force (torque), which because of car limitations it can't do by itself. Whether this is the case depends on your car.
m/s
Since when is meters per second a unit for distance? This should've been meters only.
test
train and test
crowdsourcing
Mapillary
The two models are running simultaneously.
Hence the name "dual-model deployment framework"
We further compare the two model’s predicted trajectories in Figure 10b.
Which is which? origin = Supercombo, extra = OP-Deepdive (i.e. the reconstructed one)
daul
typo, should be "dual" Occurs twice in document.
Note that they arenot uniformly distributed between 0 and 10. Instead, they are dense in the near future and becomesparse as the time goes, which suggests that the model should focus more on the near future.
They could have plotted that :) Plotted it myself then.
The resulting feature vector only contains information relevant to the problem it is trained on, which is trajectory-planning on unwarped images.
Causing it to have no sense for warping, therefore ignoring it.
train the vision model with the simple approach described above
How do you ensure that it actually strips out (does not forward) the information about the warp direction? How does such a training process look like?
Ahh, see later:
Unfortunately, our tests indicate this vector does still contain information about how the image is warped. To remove that information [...]
it still doesn’t stay on track well
Why is that? The trajectory seems right, so who's at fault? The car controller in determining the steering angle?
Explained later:
even in a simulation where we don’t introduce noise, there are linearization errors, model prediction errors, rounding errors, etc…
MHP loss
Isn't it called MTP?
Thanks to the power of insourcing, we’ve been able to reduce manufacturing costs.
A play on outsourcing.
similar things are being worked on for longitudinal (gas/brake)
stopping at traffic lights, going for green lights, stopping at stop signs
Promo video: https://twitter.com/comma_ai/status/1595235027960225793