Tag: tech

  1. Buckyball Robot

    In this idea we build a bunch of little modules that consist of basically a AA battery, one or two fast linear actuators, a chip, and some sensors.

    Then you can link these all together using dumb hubs between actuators to build a little ball. This could then hopefully move around using the same properties as the collapsing donkey toys.

    When the actuators are fully extended, the linkage between the hub and the module is loose and flexible, but when the actuator retracts the linkage becomes tight and stiff.

    At this point the actuators at the front should be able to loosen, which will cause the front to collapse. Then the ones just under the back, currently against the ground, should be able to tighten which would cause the whole thing to pitch forward a bit.

    If done repeatedly in this way it should be capable of rolling in any direction.

    It's also possible, depending on the strength of the actuators and the weight of the modules that the ball could hop a bit by collapsing all of their nodes in preparation, followed by a cascading tightening causing it to suddenly regain ball shape.

    It would also be able to, I think, remain tight while it's falling, but as it hits the ground collapse the bottom ones, followed by the next up, followed by the next as a way of absorbing impact on landing.

    Rolling up hills might be tricky, dunno yet. If the back sorta hopped a bit and more of the front collapsed maybe it'd work.

    It should also be able to collapse the front as a means of braking.

    As a last thing, if you put a bunch of cameras into the dumb nodes, recessed a bit so the lens didn't take a beating from rolling around, I wonder if you could capture an interesting image with 30 independent cameras...

  2. Zen Social Network

    In this one you have a profile, and follow your friends. You can't post anything, though. On your main page, you just see who else is online.

    It'd just be a white screen with avatars on them that pop in or out.

    Maybe, if we go one step further, which I'm not sure about, then there could be a speech bubble you can type into. Then, it pops up a speech bubble on your avatar for a while, then goes away again, and the only people who see it are the people who were looking at you while you were there.

  3. Torrent Stream

    BitTorrent has made distributing files trivial. That's awesome. Live streaming, though, is still really really hard and takes a lot of money. So, the idea is to adapt BitTorrent to streaming.

    Since torrent files are chunked little bits anyway, this should be "easy". Also, I don't want to have to be ready to start streaming when it first comes on, necessarily, since one of the things I like about downloading things is that I can't "miss" them.

    The basic idea is to have a swarm that has chunks and shares them exactly the same way it ever does. Then, though, when the source seeder has encoded a new chunk, they signal to the swarm that a new chunk is ready. In general, this should look very similar to a swarm where nobody has chunk 15, but then someone arrives who does. The only difference is that chunk 15 didn't exist until now, and no one was sure it was going to.

    That's the basic idea. Then, when someone joins the swarm they can choose to download every chunk that's been downloaded so far, thus getting the stream from the beginning, while it's still being laid down, or they can choose to just download the last chunk, and then the new ones as they come in.

    Then, when the stream is over, the source publishes an "end" chunk that is a normal chunk, but signals that the file is over now. The swarm, though, can continue to hang around and seed, since we now have a swarm that's seeding the content already.

    For example, it's an episode of a show. As the show is on, the source is recording it and releasing chunks, and people who join at any time while the show is airing can start downloading the chunks that already exist. If the show starts on boring TV at 19:00, and they show up at 19:23, they can still watch it from the beginning. But, their client is also downloading the new chunks as they come out, so by the time the show is over, they'll have all of it.

    Now, the show is done airing, and it's just a regular torrent. It's got a bunch of regular chunks, and someone who shows up an hour after the show ends might not even know that it used to be dynamic.

    So, the latency will be higher here, but I think that'd be fine. I don't need to be really up-to-date, I just want to start it before it's over. The way it currently is has two options:

    1. Wait for it to finish airing and then be uploaded
    2. Have a (crappy, sketchy) stream, but if you come in 4 minutes late you missed the first 4 minutes like we've learned nothing since antenna TV.

    I like this better. Also, latency and stuff will very quite a bit on chunk size. If the chunk size is the size of roughly 3 minutes worth of video, then a chunk won't be published until at least 3 minutes have passed (since a given chunk is atomic)

    Playing the file is up to the client. This doesn't have any kind of smarts. It just allows one to start downloading a file before the end of it is finalized. The same thing could be used for, like, the output of `tar -cjf blah.tar.bz2 files`, to start allowing people to download the tarball before the end is complete. It's up to the video player to be able to play the start of a file without the end. Certain formats (like mkv and mp4) are better at that than others (like avi), but the protocol doesn't care.

    This is a problem for more constant streams, like webcams or something. It'd be nice to have those, but really I think I'd want different tech for it. To be able to just jump in live, like I said above, by downloading the most recent chunk and then every one after that isn't likely to work with any format that I know of. The headers and stuff need to come down no matter what. One could maybe make a format that works that way, with a headers file and a "raw" stream that you can do... I don't know.

    So, I feel like this is less suited to webcams and more suited to airing programs through torrents as they air. Anything that starts, goes, then ends.

    BitTorrent has something at http://live.bittorrent.com that seems more like the solution to that last problem I was talking about. They mention that it needs H.264 and stuff, which is way more smarts than I want, but I think it's because they're going more for the "jump into the stream" style stuff, which is harder to do dumb. They'll probably also need a special player, etc. I don't want that.

    So, the one issue I can see, is "who gets to publish new chunks". That seems like an obvious attack. So, I'm thinking that as part of the streaming torrent metadata, a public-key is given as well. Then, the "New chunk" message is signed with that key. That way it can be forwarded through the network peer-to-peerfully, but you know that the new chunk your neighbour just told you about actually belongs to this stream.

    It's been a while since I read the actual protocol spec, maybe this is all super dumb and useless. I intend to look into that later, maybe branch off of libtransmission, see if it is a workable idea.