otaviogood

FWIW, I tried the prototype. It's very real. I scanned my hand and arm. It showed realtime images of slices of my hand as I dipped my hand in the water. Really amazing IMO. I think this will be a game changer when it comes out. It's just so easy to scan yourself.

for an introduction to the CAD software, Kicad, which this project uses, I really liked "Shine on you crazy Kicad": https://www.youtube.com/watch?v=eMW9ohCbcik&t=27s It takes you from basics to buying a PCB from the manufacturer.

Like many have said, start with Arduino-like boards + servos. You can get servo driver boards that let you plug in multiple servos to your Arduino without power problems. Get those from Adafruit. Then you can graduate to the "bus" style servos like Feetech if you want to load up on servos.

If you want to learn to make PCBs, this tutorial shows you how to design them in open source software and then get them made cheaply (highly recommend): https://www.youtube.com/watch?v=PlDOnSHkX2c

Get a CAD program like Onshape (I love Onshape). Learn how to use it to design 3d printed components. Get a 3d printer. Maybe Bambu Lab. Now you should be able to make nice form factors for your robots. If you want to graduate from 3d printing to Aluminum, then you can send your designs to a place like PCBWay or JLCPCB and get the aluminum parts reasonably cheap.

At some point when you want to make a more "real" robot, read this guy's thesis and try to understand almost all of it: A low cost modular actuator for dynamic robots https://dspace.mit.edu/handle/1721.1/118671 It goes over so many things that are useful, like types of actuators, how they're designed, controlled, etc. I wish I had read that earlier. Then if you want to make something like that, I highly highly recommend MJBots. https://mjbots.com/

Make something amazing!!!

You might be reading into it too much. I think the originals were just random pieces of different kinds of paper. Graph paper, yellow lined, paper, blank white paper... I don't remember exactly, but I think the copies could be special paper with a colored backside so they would know which way was up really easily for the scanning process.

DARPA scanned the shreds. The funny thing is, they didn't want to shred the original paper, so first they photocopied the paper in a high quality color copier, shredded it, and scanned it. And that's where the little yellow dots came from. :D

Me and my team used these yellow tracking dots to reconstruct shredded documents for a DARPA shredder challenge over a decade ago. You can see our program highlight the dots as we reconstruct the shredded docs. https://www.youtube.com/watch?v=uzZDhyrjdVo Thanks to that, we were able to win by a large margin. :)

This is much more interesting if you see the animations. https://x.com/jaschasd/status/1756930242965606582

‘1984 is 1 token. 1884 is 2 tokens.’

I would be surprised if they use this tokenization still as it’s not math friendly.

Where do you see the room for improvement that gets you to much faster speeds? Also I love the single file to do everything. :)

The geometry in my raytracer can either be ray-traced primitives, like spheres or boxes, or it can be "signed distance functions" (SDFs), which let you define all kinda of crazy shapes. Inigo Quilez does a good job of explaining SDFs here: https://www.iquilezles.org/www/articles/distfunctions/distfu... The refraction math in my code is around line 799 or 809 depending on what you're looking for. There are a few errors in the refraction code in this version. :/ But caustics are handled well by my renderer.

This article talks about a pretty full-featured ray tracer. If you just want to play around with some ideas and have fun, you can make different tradeoffs and still get very nice and fast renderings. Here's a ray tracer that I made that's GPU-accelerated and can make some nice looking images quickly in 1000 lines of code. https://www.shadertoy.com/view/4ddcRn The tradeoff is that it's all procedural graphics. So there are no triangle meshes and it would also be a bit tricky to implement a bidirectional ray tracer like this.

I thought it would be nice to listen to these with my podcast player on iphone. Here's my too-complicated process that worked:

- in Chrome inspector, look at the network tab when you click play on a Feynman lecture. Right click the mp4 and do "copy as cURL".

- Go to command line (unix style) and paste. Then append to that command line something like "--output flp1.mp4". That will download the file locally with that file name.

- Put the file on Dropbox or something that will get it to your phone.

- From dropbox on iphone, share and export the file, then choose your podcast app. The podcast app that worked for me is "Pocket Casts".

- Now in Pocket Casts -> Profile -> Files, you should be able to play the mp4s with nice podcast-style controls and learn physics and be happy!

Maybe we should have tried Daily. :) We tried Twilio video and unfortunately had a really hard time tracking down bugs. Wasted tons of time on that and then went back to doing our own stuff. :( I still don't know where the bug was. Could have been our code or Twilio's. But when we got rid of Twilio and used our own stuff, it resolved the bugs. Was a very frustrating process. Also, the way Twilio video charges seems to assume lots of n-squared, high res connections, which we don't have, so for an application like ours, the cost can be more than 10x less.

25 person Zoom calls aren't fun. So me and my friends made a virtual gathering space for people to host online events, meetups, social hours, etc.

Tech: Frontend uses Svelte / Snowpack, which is great. The game view uses the DOM, which is questionable, but my webgl implementation wasn't so hot either.

Backend is Firebase for general stuff, server written in Golang for the realtime game stuff, and another Golang server for video.

Main techincal lesson learned so far: WebRTC sure is a pain to get right across everyone's devices, browsers, and connections.

I think this eventually turned into Andrej Karpathy's class at Stanford, CS231n. The class notes are here: http://cs231n.github.io/ The class is on youtube. If you like this hacker's guide, I think you'll definitely like the class and the notes. edit: A lot of the compute graph and backprop type stuff that is in the hacker's guide is covered in this specific class, starting about at this time: https://www.youtube.com/watch?v=i94OvYb6noo&t=207s

People say you have to "do" math to learn it. Usually they make it sound like you need to do the exercises in the books. I think that doing just that can be boring and demotivating.

I would suggest finding projects that can motivate you and help you exercise your math. Some suggestions of mathy things I regularly work on for fun:

1. Make a video game. If it's a 3d game, you'll have to do your matrices, dot products, trigonometry, etc.

2. shadertoy.com - This is a community site where people just program cool looking graphics for fun. All the code is open, so you can learn from it. Similar to game programming but without the mathless overhead. :)

3. Machine learning projects - I love writing various machine learning things, but the project that has been a great ML playground has been my self driving toy car. It gives me plenty of opportunities to explore many aspects of machine learning and that helps drive my math knowledge. My car repo is here: https://github.com/otaviogood/carputer but a much easier project is donkeycar.com. ML will touch on linear algebra, calculus, probabilities/statistics, etc.

The most important thing for learning is to be inspired and have fun with what you're learning. :)

Books might not be the best resource for Shadertoy-type stuff. Almost all of Shadertoy 3d shaders use a technique called ray-marching with signed distance functions. If you Google it, you should find good resources. Also, someone on Shadertoy made a very good tutorial using Shadertoy, which I think is kindof amazing... https://www.shadertoy.com/view/4dSfRc There are other tutorial shaders on Shadertoy and I always try to make mine readable and heavily commented... https://www.shadertoy.com/user/otaviogood

Shadertoy shaders _do_ include the render algorithm. That shader is completely ray-traced, so the only real input that is used for that shader is the x, y coordinates and time. It's not using any of the GPU's polygon rasterization. It's stateless and is generating the terrain while it ray-traces it.

It could be fun if you released your tagged data set of lego piece pictures so people in the ML community could try to write classifiers. Even untagged pics could be interesting.

http://www.arxiv-sanity.com That helps sort through arxiv papers and get recommendations.

The Skew language compiles to Javascript, C#, and C++ (which is still a work in progress). So if you don't like that it's in Skew, you might have the option to switch it to one of those languages. It probably won't work for the more system-dependent parts of the code, but you might get something out of it.

Yes, one of the keys to reconstructing the harder puzzles was that we found a yellow dot pattern on the paper. At the time, I was reading HN and I saw a headline that said something about the government tracking photocopies using little yellow dots. DARPA had photocopied all the docs before shredding them, so they all had a very high-res repeating dot pattern on them. We made our program snap the pieces to the dot pattern. With that in place, the puzzles came together relatively quickly. Some people at DARPA knew about the concept of little yellow dots, but didn't think much of it. I don't blame them. The shredded pieces were so small that it would be hard to imagine any secret pattern helping with the reconstruction. But I guess it helped enough. :)

I was on the team that won the shredder challenge. I talked to one of the UCSD people afterwards and he practically convinced me that my team did it. After a while I realized that it was so damn easy to sabotage their effort that I didn't really care if my team did it because that's what happens when you invite the whole internet to your party. Now I guess they managed to clear us of that. :) Unfortunately, when this Adam guy wrecked their program, he wrote them a letter which simultaneously implied that he was our team and the group "Anonymous" at the same time. Some people at DARPA seemed to believe that claim (even though I used my real name to sign up) and so DARPA was very hesitant to announce that we had won the competition. It was a fun competition though.

Since you mentioned it, me and at least 2 other people have written Tetris in 256 bytes. I used 80286 assembly and you probably can't get away with that these days - even when I did, it was already old. 64 bit code will probably be much bigger. But the main trick besides the right instruction set is to use XOR for drawing, erasing, and collision checks. Have fun!

Don't be afraid to drop a project. I tend to have a handful of projects going at any one time. A good project will stand out and it will pull you through to completion. Pretty much all of my significant jobs were spun out of my side projects. My current job started as a side project that I prototyped in a few weeks. A company was built around it and now our company is part of Google. This. https://www.youtube.com/watch?v=h2OfQdYrHRs

Take note of things that inspire you. For me, books or other people's projects. Show your work to your friends and try to convince your friends to work on projects with you.

Find programming languages / environments that make it easy to spin up a simple project without too much overhead. Start small. Last I counted, I have about 140 folders in my dev directory. Each one has a small project I started up. One turned into a successful company. Another won a DARPA challenge. A few others were released in various forms. But most got dropped because they just weren't as cool as something else. And I think dropping projects isn't just ok, it's great fun and will help you find that project that's worth completing.

Yeah, jf is friends with the dev team. When we first released Word Lens, he posted it and explained Hacker News us. HN made such a huge difference for getting the word out. Since then I've been reading HN many times daily. So thanks, HN community.

Yes, it works best with larger fonts. There's not a lot we can do about the focus on the software side unfortunately.

Yes, this is the same app I was showing to people at Super Happy Dev House pretty much the whole way through the development process. I'm a big fan of SHDH. So many creative people.

Word Lens needs a lot of light. If there isn't enough light, the scene will have noise and motion blur. That's bad for the OCR algorithms. The camera also makes a huge difference. As cameras get more sensitive, the noise and motion blur are reduced. That has been our experience working with Word Lens over the years.

They might allow non US citizens to compete as long as the primary point of contact for the team is eligible to compete. This is how I remember they did the Darpa shredder challenge.