Cảm biến 3D – TOF

Từ khi ipornX Iphone X của Apple được giới thiệu, cảm biến 3D trở thành 1 hot keyword, làm cho nhà nhà đua nhau tích hợp 3D vào điện thoại, người người thi nhau mua điện thoại có cảm biến 3D. Ông trùm SONY về mảng điện tử một thời của Nhật, mà hiện giờ mảng cảm biến đang mang lại một trong những nguồn sống chính, đã nhanh chân mở ví ra mua luôn Softkinetic, một startup của Bỉ với tầm 77 nhân sự vào 2015.
Tôi vô tình cũng bị cuốn vào xu thế đó khi tham gia dự án làm platform & driver cho con hợi này. Do đó vừa học vừa viết lại đôi điểm cho đỡ quên, nội dung rút ra từ tài liệu [1] ở phần tham khảo. Có thể học thêm về TOF ở kho tài liệu của Texas Instrument [2], rất phong phú và chi tiết.

Trong vấn đề xử lý hình ảnh, việc thu và tái hiện lại hình 3D không phải vấn đề gì mới, trước TOF đã có 2 phương pháp được sử dụng để tái tạo hình ảnh 3D.
Stereo Vision : Sử dụng 2 camera để tái hiện lại 3D, vị trí của 1 điểm sẽ được xác định nhờ vị trí tương đối của nó đối với 2 camera. Phương pháp này sử dụng tương tự hệ thống mắt người.
stereo-vision
Nguyên lý Stereo Vision (Ảnh lấy trong tài liệu[1])

Structured-light: Phương pháp này sử dụng 1 chùm tia sáng với mô hình xác định trước (dạng lưới, quét ngang …) , để chiếu lên vật thể cần quan sát, thu lại hình ảnh khi tia sáng đập lên bề mặt vật thể để xây dựng lại hình ảnh 3D của nó.
structure-ligh
Nguyên lý Structured-light  (Ảnh lấy trong tài liệu[1])
Vậy TOF là gì? TOF là viết tắt của Time Of Flight, dựa trên nguyên lý đo khoảng cách bằng sóng điện từ (sóng ánh sáng ở dải mắt người không nhìn thấy). Trong hệ thống TOF, sử dụng 1 nguồn phát sóng ánh sáng, quan sát nguồn phản hồi từ đối tượng quan sát, bằng cách đo thời gian từ lúc phát ra đến lúc phản hồi thì sẽ tính được vị trí của đối tượng đó.
tof
Nguyên lý TOF (Ảnh lấy trong tài liệu[1])
Dễ thấy nguyên lý của TOF giống hệt như dùng sóng siêu âm để đo độ sâu đáy biển, tất nhiên từ lý thuyết đến thực tiễn là 1 khoảng cách không nhỏ về thời gian cũng như tiền bạc.

Bảng dưới đây cho thấy hình ảnh tổng quan của TOF khi so sánh với 2 kỹ thuật còn lại. Công nghệ thay đổi chóng mặt chả khác gì “chó chạy ngoài đồng” , nên cần chú ý rằng thông tin trong bảng này chỉ đúng với tầm thời điểm hiện tại (~2018).
tof

So sánh TOF với Stereo Vision và Structured-light (Ảnh lấy trong tài liệu[1])

Tham khảo:
[1] http://www.ti.com/lit/wp/sloa190b/sloa190b.pdf
[2] http://www.ti.com/3dtof
[3] https://en.wikipedia.org/wiki/Structured_light
[4] https://en.wikipedia.org/wiki/Time-of-flight_camera
[5] https://en.wikipedia.org/wiki/Computer_stereo_vision

3 định luật XYZ

Sau khi được nhà quí tộc Brahe để lại 1 khối lượng dữ liệu quan sát thiên văn hơn 30 năm, thì Kepler đã hoàn thành thuyết nhật tâm một cách có hệ thống bằng 3 định luật chuyển động thiên thể và những năm 1609 – 1619, lúc đấy ở Đại Việt ta bắt đầu thời kì Trịnh – Nguyễn phân tranh nên chắc chả ai có thời gian đâu mà quan tâm đến thiên với chả thể.
Tuy là tìm ra 3 định luật, nhưng Kepler cũng không hiểu “vì sao lại thế, tại vì sao lại thế, các thiên thể không chuyển động thế này mà lại là thế kia”. Người trong giang hồ phải chờ đến xuất hiện một quái kiệt mới “để tìm ra ngọn ngành”, người mà khiêm tốn nhận mình trông xa hơn vì được đứng trên vai những người khổng lồ, Newton đã đưa ra 3 định luật cơ bản, hình thành nên cơ học cổ điển hay còn gọi là cơ học Newton, cùng với định luật vạn vật hấp dẫn, đã giải thích thấu đáo tại sao qui luật chuyển động thiên thể. Cơ học Newton đã thống trị mọi lĩnh vực của Vật lý học cho đến đầu thế kỉ 19, khi mà mọi ngành nghiên cứu từ chuyển động của phân tử, đến những đối tượng to vật vã như thiên thể, hành tình đều được xây dựng theo các định luật cơ bản của Newton, mà đưa ra nhiều dự đoán đúng. Mô hình vật lý học trở nên thống nhất, rất đẹp đẽ.
Nói đến ngành nghiên cứu về tập hợp các phân tử tuân theo chuyển động cơ học, hay còn gọi là nhiệt động lực học, cũng cho ra đời 3 định luật nhiệt động lực học, trong đó từ định luật số 2 định nghĩa ra một khái niệm mới là entropy, mà nó còn dùng để định nghĩa lượng thông tin trong lý thuyết thông tin.

Tưởng chừng như “con thuyền Vật lý học cấp bến bình yên” như huân tước Kelvin (nhiều tài liệu dẫn tuyên bố này của Kelvin, tuy nhiên thực tế hình như không có thông tin chính thống), thì “2 gợn mây nhỏ” đã nổi lên thành 2 cơn giông tố làm rung chuyển và thay đổi hẳn bộ mặt ngành Vật lý. Trong cơn giông lượng tử, ta lại bắt gặp 3 định luật quang điện

Con số 3 chưa dừng ở đó, ta lại tiếp tục gặp 3 định luật về di truyền Mendel khi học sinh học hình như tầm năm lớp 9.
Hôm nay vô tình biết đến tồn lại 3 định luật hơi bị hay của Arthur C.Clarke, người nổi tiếng về những dự đoán của ông trong các tác phẩm khoa học viễn tưởng đã dần dần thành hiện thực. Nguyên văn của nó như sau:
1. When a distinguished but elderly scientist states that something is possible, he is almost certainly right. When he states that something is impossible, he is very probably wrong.
2. The only way of discovering the limits of the possible is to venture a little way past them into the impossible.
3. Any sufficiently advanced technology is indistinguishable from magic.

Tạm dịch nó như sau:
1. Khi một bậc lão thành cho rằng một chuyện gì đó là có thể xảy ra được thì ông ta hầu như chắc chắn đúng. Song khi vị này bảo rằng chuyện gì đó là không thể được, thì phần chắc là ông ta sai.
2. Cách duy nhất để xác định biên giới của cái có thể là mạo hiểm vượt qua lằn ranh đó để đi về hướng cái không thể.
3. Bất kỳ công nghệ tiên tiến nào đều không khác gì phép thần thông.

P/S: Áp dụng định luật Clarke ở trên, ta dễ dàng thấy được tuyên bố sau của Steve Wozniak là sai, thật là một định luật thú vị 🙂
http://genk.vn/dong-sang-lap-apple-tri-tue-nhan-tao-se-khong-bao-gio-du-thong-minh-de-dieu-khien-mot-chiec-o-to-20181001104135133.chn

Biên dịch Linux OS từ mã nguồn

Bắt đầu đi làm vào giữa 2009, tôi bắt đầu được tiếp xúc với Linux, nhưng trải qua gần 9 năm từ đó đến nay, hiểu biết về Linux rất ổn định như tham nhũng, không có gì thay đổi. Lý do thứ nhất là vì các dự án làm với Linux chỉ là sử dụng môi trường Linux để phát triển, nên cơ bản chỉ biết cái Makefile là xong, chẳng lúc nào cần mó tay một cách chỉnh chu thấu đáo vào các thứ như device driver, hay memory management …, để biết cái gì đủ hay ho mà kể chuyện. Thật ra là có một chút nhưng không ăn thua, mấy thứ cơ bản như system call, char driver, block driver … thì nó phổ cập cmnr, với lại khoảng cách giữa biết tên và biết để kể chuyện được nó cũng quá xa. Lý do thứ 2 là lười & nhác tìm hiểu.

Đang ôn tập lại chút kiến thức để chuẩn bị do dự án làm driver trên Linux, thì bắt gặp trang dưới (ko hiểu sao giờ mới biết, chắc lại do nhác & lười).
http://linuxfromscratch.org/lfs

Trước giờ hay có sở thích, là thử distribution (Linux OS) của Linux, hết Ubuntu đến Backtrack, với mục đích rất đáng sợ là để học sâu thêm về Linux nhưng cài xong  chiêm ngưỡng cái desktop xong  rồi thì sau đó là chỉ để duyệt web ~.~

Việc hay thử Linux OS, nó cũng bắt nguồn từ hồi mới ra trường, được bố mẹ bán hết lúa gạo lợn gà cho mua con hp pavilion, không nhớ chính xác tên nhưng giá là 12 hay 17 chai gì đấy. Đen đủi thế nào lúc ra lúc bắt đầu đi làm 1 năm thì bị trộm nó thó mất, lương thấp ăn chưa đủ nói gì đến mua lại máy. May thay ông anh trong dự án có con T40 thinkpad hỏng main đang đắp chiếu, bảo cầm về sửa mà dùng. Sau thay main cũ hết 1 triệu, cài luôn ubuntu, có hơi rùa bò tí những nó vẫn dùng để kết nối tốt với internet. Vì rùa bò nên nghĩ ra việc dùng các bản Linux OS cho máy cấu hình thấp, nhưng rồi cũng thấy chẳng ăn thua lắm nên mới sinh ra trò thử cài Ubuntu xong gỡ hết gói màu mè về giao diện ra thì tốc độ có thấy cải thiện kha khá. Từ đó có thêm trò ngược đời là cài xong Linux OS thì gỡ bớt gói không cần thiết ra, đôi khi không biết nên gỡ quá tay làm nó chẳng start up luôn được cả giao diện =]]. Dùng được hơn 1 năm thì T40 cũng đi vì cái màn hình hỏng.

Đến 2011, đi công tác ở Nhật, nhịn ăn nên cũng mua được con CF-W5MW8AJR Panasonic đồ cũ cùi bắp, mua xong cài luôn Ubuntu đè lên con Win Vista bản quyền luôn.
Riêng con này từ lúc mua ngoài làm mất thứ vớ vẩn thì cũng kiếm đc chút từ việc
data hiding, do muốn mua con len Nikon 50mm f/1.8G, nhưng lương chỉ đủ nuôi con nên đành kiếm tí việc đánh thêm, đỡ phạm đến phần tiền mua sữa cho con 😦

Nói dài dòng, nhưng tóm lại giờ có con CF5 cùi bắp, tính  cho mấy thằng em ở quê, nhưng chắc là nó không thèm lấy, mà công nhận đồ của Panasonic rất chất, nhẹ, pin trâu vẫn duy trì hơn tầm 1.5h, phím bấm cực đã không bị rung, ai dùng dòng Let’s Note của Panasonic rồi thì biết, chỉ có điều giá trên trời. Như  đề cập ở trên, tự dưng biết 1 dự án rất có tâm, hướng dẫn biên dịch hẳn Linux OS từ source code (có khi google đủ các kiểu + bỏ thời gian ra chắc cũng tự build được), tóm lại từ Linux kernel, đến các gói mã nguồn GNU & non-GNU …

Dù là việc biên dịch chỉ là việc chân tay, nhưng trải nghiệm 1 lần biên dịch ra OS từ mã nguồn nó cũng hay hay, dù sao cũng tạo hứng thú vượt qua lười & nhác để có thể bắt đầu tìm hiểu thêm chút về Linux. Thêm vào đó hi vọng do tự điều chỉnh được các gói cần thiết nên sẽ có được con OS nhỏ gọn để chạy với cái đồ cùi bắp như CF-W5MW8AJR.

Có 1 điểm chú ý khi bắt đầu biên dịch là nên chuẩn bị 1 con USB stick hoặc CD live có thể chạy live Linux OS nào đó (ex: ubuntu), để phòng trường hợp lỗi khi chia ổ cứng này nọ thì còn có cách mà xử lý.
Về phần dữ liệu quan trọng trong máy thì theo tôi không cần phải backup, vì nếu bị lỗi thì có cơ hội học cách cứu dữ liệu, nếu cứu không được thì coi như cái giá phải trả để nhớ bài học hơn =]].

Libc

Bắt đầu từ đoạn code nhỏ dưới viết bằng ngôn ngữ C. Ngoài dòng có chữ printf ra, thì các dòng khác được được biên dịch trực tiếp ra ASM và sang mã máy mà không cần thông qua thư viện nào hỗ trợ. Dĩ nhiên rồi cái nào cũng ra mã máy cả, nhưng printf có gì đặc biệt.

libc

Quay lại chút về ngôn ngữ C, được Dennis Ritchie xây dựng vào 1978, dựa trên ngôn ngữ B, đằng sau đó là 1 câu chuyện dài thú vị, nhưng giờ không phải lúc để kể. C là một ngôn ngữ lập trình, tất nhiên ai cũng biết rồi, tức là để tạo nên C sẽ có 1 loạt qui định về cấu trúc mã lệnh, từ khóa, toán tử … Bên cạnh đó có 1 thứ gần như luôn đi cùng đó là thư viện chuẩn của C, còn gọi là libc, quá quen thuộc với những ai lập trình C. Thư viện này được chuẩn hóa C POSIX library hẳn hỏi, và vẫn được bổ sung theo thời gian.

Thư viện này thuộc loại căn bản của C rồi, nên gần như nó luôn tồn tại sẵn làm người ta đôi lúc quên mất sự hiện diện của nó. Thực tế cũng giống như các thư viện khác, dựa vào đặc tả trên, nó cũng được code, biên dịch trước thành mã máy để liên kết vào chương trình nào dùng đến nó.
Trên môi trường GNU/Linux thì dùng glibc của GNU, trên android thì có bionic do google thực hiện để tránh cho Android đỡ dính đến copyleft licenses chừng nào có thể (trong khi đó vẫn dùng Linux Kernel → LOL), trên các hệ điều hành BSD ( ex: MacOS) cũng tự tạo BSD libc riêng của nó, ngoài ra còn nhiều trường hợp khác cũng viết lại thư viện này, để phù hợp hơn với yêu cầu hệ thống, ví dụ như đôi lúc không cần thiết phải dùng hết toàn bộ libc nhất là đối với môi trường hạn chế tài nguyên.

Trở lại vấn đề chút đoạn mã trên, vậy cái hàm printf trên nó là thuộc libc, chi tiết hơn là thư viện chuẩn vào ra (I/O) stdio.h. Nếu biên dịch trên GNU/Linux thì nó liên kết đến thư viện glibc trên đó để tạo ra mã máy.

Ngó qua chút xem 1 hàm “đơn giản” như printf thì có mã lệnh thế nào.
Official glibc repo ở đây, hàm printf nó ở chỗ này, rồi nhảy sang chỗ này, tổng cộng chỉ có “ít ỏi” gần 2500 dòng lệnh.

Đến đây có chút thú vị trên môi trường OS dùng nhân linux, do chỉ dùng glibc trên user space, nên thành ra ở kernel space không dùng được các hàm libc. Do đó lúc muốn printf thì làm sao giờ?, vậy là Linus viết luôn hàm printk thay thế, đúng theo triết lý, thấy ổ gà thì lấp.

Code refactoring

Từ 1 comment status của thằng bạn trên facebook, nhớ lại về nguyên lý thứ hai của nhiệt động lực học. À, mà sao lại nguyên lý thứ hai nhỉ, có nguyên lý thứ nhất không nhỉ?

Học từ hồi cấp 3, bắt đầu từ câu chuyện không thể chế tạo động cơ vĩnh cửu loại 2, tức là động cơ dùng 2 nguồn nhiệt để có thể biến nhiệt hoàn toàn thành công. Tuy không vi phạm định luật bảo toàn năng lượng, nhưng vẫn không làm được.

Hiệu suất lý tưởng để chuyển nhiệt biến thành công chỉ đạt được = (T2- T1)/T2; T1,T2 là nhiệt độ nguồn nóng & lạnh tính theo nhiệt giai Kelvin.
Tại sao lại thế? qui luật gì đã chi phối cái đó. Trong quá trình giải quyết cái đó thì ông cụ Rudolf Clausius đã mang đến một khái niệm gọi là Entropy (kí hiệu là S), bản chất là đặc trưng cho tính hỗn loạn của hệ thống. Chốt lại là qui luật trên sẽ tương đương với việc phát biểu: Entropy của hệ cô lập không thể giảm. Tức là tính hỗn loạn của hệ thống cô lập sẽ tăng hoặc ít nhất là giữ nguyên.
Câu chuyện tưởng đến đây là hết, thì hóa ra mới bắt đầu. Trong lý thuyết thông tin, Shannon định nghĩa lượng thông tin của hệ thống thông qua Entropy, xem ở đây. Hệ thống càng hỗn loạn thì càng chứa nhiều thông tin, hệ thống càng trật tự thì lượng thông tin chứa trong đó càng ít, nghe cũng có lý đấy chứ nhỉ!. Vậy là từ cái máy nhiệt lại liên hệ mật thiết với chủ đề nóng, vấn đề thông tin.

Cái nghề làm phần mềm chắc chắn cũng không ngoài cuộc, vì nguyên lý phổ quát mà, bao trùm từ vũ trụ bao la bát ngát ( xem Lược sử thời gian – Stephen Hawking, thì biết) đến trà đá vỉa hè (cục đá đang tan dần trong cốc trà, chính là biểu hiện của việc Entropy đang tăng). Vậy phần mềm có xu hướng càng ngày càng lộn xộn, và thực tế đúng như thế. Lúc bắt đầu dự án, nếu là dự án tử tế thì basic design, detail design chuẩn mực thật. Nhưng theo tháng năm, ta thêm tí mắm, lâu lâu cho chút muối vào, thi thoảng thêm tí tính năng để phần mềm lúc đầu đặc tính giống Chó nhưng lại muốn bắt đc cả Chuột, và dần dần nó trở thành 1 đống lộn xộn. Và đâu đó cũng có Sofware entropy thật.
Nhưng chú ý, điều đó chỉ đúng với hệ cô lập, và để phần mềm không trở nên thành 1 đống hổ lốn theo tháng năm thì phải tìm cánh phá vỡ tính “cô lập” của nó, một trong những cách đó là REFACTORING, quyển sách cần đọc, nó nằm ở đây.  Mặc dù  không khuyến khích, nhưng trước khi mua sách tử tế thì có thể xem tạm ở đây

Tóm lại từ nguyên lý thứ hai của nhiệt động lực học, ta rút ra rằng để software không bị xuống cấp, ta phải học cách refactoring?

Zero start with USB

1. Lược sử USB.
Viết tắt của chữ Universal Serial Bus, cái tên nói lên tất cả. Và không hổ danh với tên gọi, đây là chuẩn kết nổi phổ biến nhất, đã và đang thay thế dần các kết nối ngoại vi khác.
Đồ sộ về cả đặc tả lẫn mã nguồn (ví dụ USB stack trong Linux), nếu không phải thánh thì nên tiếp cận từ từ, tránh “đột-thức” (đột quị vì nhiều kiến thức cần nắm).

Lịch sử tóm gọn, có vẻ khi ứng dụng cách mạng nhất là USB Mass Storage(usb flash, thường gọi tắt là USB) bị lấn lướt bởi việc phát triển mạnh mẽ của điện toán đám mây(cloud) và các dịch vụ trực tuyến, thì USB 3.0 lại vùng lên, tuy chưa rõ có nên cơm cháo gì không.
– Khai sinh 1/1996: USB 1.0, Low Speed 1.5Mbit/s, Full Speed 12Mbit/s
– 04/2000: USB 2.0, High Speed 480Mbit/s
– 11/2008: USB 3.0, SuperSpeed 5Gbit/s
– 07/2013: USB 3.1, SuperSpeed+ 10Gbit/s
– 09/2017: USB 3.2, SuperSpeed+ 20Gbit/s

2. Lướt qua đặc tả USB.
Đầu tiên cần nắm đặc tả, vào [1] để lấy đặc tả. Đặt tả là một ma trận chữ nghĩa và khái niệm, nên đọc [3] để biết tiếp cận đặc tả, nếu lười đọc tiếng Anh thì đọc nội dung ở [4], của 1 blog rất có tâm. Ở đây chỉ giới thiệu các tiếp cập đặc tả phiên bản USB 2.0[2], tuy nhiên các chắc các phiên bản tiếp theo cũng có thể tiếp cận theo cách tương tự.
Đồ sộ quá nên cần nắm vững những câu thần chú cơ bản. Đây là chân lý, không bao giờ được buông. NHƯNG nó chỉ đảm bảo cho các phiên bản trước USB 2.0, về sau có thể có thay đổi, sử dụng cần tỉnh táo.
●USB là chuẩn giao tiếp đơn, chỉ có HOST(chủ) và DEVICE(thiết bị, client-khách) giao tiếp với nhau, không phải là giao thức mạng.
●DEVICE chỉ nghe và trả lời khi có lệnh từ HOST, kể cả trường hợp giao tiếp theo interrupt.

Về mặt đặc tính truyền dữ liệu, thì có 4 loại cơ bản:
– Control Transfers: Sử dụng để truyền command (lệnh) hoặc status (trạng thái), ở quá trình DEVICE bắt đầu kết nối với HOST.
– Bulk Data Transfers: Dùng kết nối truyền lượng dữ liệu lớn, không cho phép mất mát, ex: usb flash.
– Interrupt Data Transfers: Dùng cho kết nối đảm bảo tính phản ứng nhanh, ví dụ chuột, bàn phím…
– Isochronous Data Transfers: Dùng cho các kết nối có tính realtime, tốc độ ổn định, ex: Camera, Audio …

Song song với sự phát triển của các thiết bị nhúng (embedded, lai tạp) thì sinh ra USB OTG (On-The-GO), cho phép nó có thể đóng vai trò HOST hoặc DEVICE. Việc lựa chọn vai trò quyết định trong quá trình đàm phán lúc kết nối.

3.Tài liệu tham khảo.
[1]http://www.usb.org/
[2]http://www.usb.org/developers/docs/usb20_docs/
[3]https://www.beyondlogic.org/usbnutshell/usb3.shtml#USBProtocols
[4]https://lazytrick.wordpress.com/category/usb/

 

Ngụy khoa học

Khoảng cuối 2013, thằng ku em, giờ đang phD Vật lý ở Pháp, gọi lên viện Vật lý nghe seminar đủ mọi thứ từ Vật lý đến lịch vực nghệ thuật rồi nghe đâu có lúc ra cả Biển Đông… do thầy của nó, GS. Nguyễn Văn Liễn, tổ chức chủ yếu cho học sinh phổ thông, một việc làm rất đáng quí, không rõ đến giờ còn duy trì nữa không.
Giai đoạn đó công việc đang bận nên mình chỉ ghé qua vài lần, nhớ nhất là chuỗi câu chuyện về Feynman, nhà vật lý đa tài người Mỹ, đạt giải Nobel vật lý 1965, tham gia dự án Manhattan (dự án làm bom nguyên tử của Mỹ), học phá khóa két sắt và giải mã kí tự của người Maya làm thú tiêu khiển. Tiện thể xin giới thiệu phương pháp đơn giản để học nhanh kiến thức mới của Feynman ở đây[2], mời các bạn áp dụng để khám phá chân trời kiến thức bao la bát ngát.
Ấn tượng nhất để lại với mình là tính trung thực của Feynman, thể hiện rõ nhất là quá trình tham gia điều tra và đấu tranh với NASA để có báo cáo trung thực về nguyên nhân của vụ tai nạn tàu Challenger[4,5].
Ở đây trích dẫn 1 phần mà bản thân cũng thường hay mở ra xem lại nhất, nói về việc trung thực trong nghiên cứu khoa học, trong quyển “Feynman chuyện thật như đùa!“, do Nguyễn Văn Liễn và Nguyễn Huy Việt dịch từ “Surely you’re joking, mr.Feynman”. Bạn nào tò mò muốn đọc thêm thì có thể mua sách có hình như dưới.

feynman

… Một ví dụ: Milikan đo điện tích của electron bằng thí nghiệm các giọt dầu rơi và thu được kết quả, mà bây giờ ai cũng biết là không thực sự chính xác. Có một chút sai lệch do ông ấy đã dùng giá trị không chính xác của độ nhớt không khí. Thật thú vị khi nhìn vào lịch sử các phép đo điện tích electron được thực hiện sau Milikan. Nếu biểu thị các kết quả đó theo thời gian, bạn sẽ thấy một kết quả lớn hơn Milikan một chút, rồi một kết quả tiếp lại lớn hơn một chút, và cuối cùng chúng qui về một con số lớn hơn.

Vì sao họ lại không phát hiện ra ngay rằng, con số mới là số lớn hơn? Đây là câu chuyện, mà các nhà khoa học phải cảm thấy xấu hổ, bởi vì rõ ràng người ta đã hành xử như thế này. Khi họ thu được một kết quả quá cao so với kết quả của Milikan, họ nghĩ rằng chắc chắn có sai sót nào đó, họ tìm kiếm và rồi cũng tìm ra một nguyên nhân có thể dẫn đến sai sót. Còn, khi họ nhận được kết quả gần hơn với kết quả của Milikan, thì họ không xem xét cẩn thận. Rồi họ loại bỏ những sai lệch nhiều so với giá trị của Milikan, hay làm những việc tương tự như thế. Ngày nay, chúng ta đã biết những xảo thuật này, nên không còn mắc những bệnh như thế nữa.
Tuy vậy, lịch sử lâu dài của việc học cách không tự lừa phỉnh mình – của việc có được trung thực khoa học tuyệt đối là, tôi xin lỗi phải nói, cái mà chúng ta chưa chú tâm đưa vào bất cứ môn học nào, mà tôi biết. Chúng tôi hi vọng là, bạn sẽ học được bằng cách ngấm dần.
Nguyên tắc đầu tiên là bạn không được tự lừa phỉnh chính mình – bạn chính là người dễ bị lừa nhất. Vì thế bạn phải rất thận trọng với điều đó. Sau khi bạn không còn bị lừa phỉnh nữa, bạn sẽ dễ dàng không lừa phỉnh các nhà khoa học khác. Sau đó, bạn chỉ cần trung thực theo cách thông thường.

Tham khảo
[1]https://vi.wikipedia.org/wiki/Richard_Feynman
[2]http://genk.vn/nha-vat-ly-doat-giai-nobel-chia-se-phuong-phap-hoc-nhanh-moi-thu-tren-doi-chi-voi-3-buoc-20161204110349259.chn
[3]https://vi.wikipedia.org/wiki/Dự_án_Manhattan
[4]http://www.feynman.com/science/the-challenger-disaster/
[5]https://www.youtube.com/watch?v=6Rwcbsn19c0