[757labs] Updated (from Ethan). Cray. Arm. ARMs.

[Matt Davis]

On Sat, Oct 2, 2010 at 3:52 AM,  <telmnstr at 757.org> wrote:
>> I was going to call Geoff this weekend about this too. I was planning on
>> building and deploying an updated web app as a simple ruby project for the
>> 757rb next talk. Here lately too I have actually been programming C
>> extensions as well for ruby. The meetup is only a few weeks away, but if I
>> could mix both examples of C extensions and get the web app (assuming
>> hardware was fixed) I'm still all for it! Possible and will I need to come
>> down there to get the info, specs, etc? Just wondering when I can get more
>> info?
>
> Adam had mentioned it. Honestly, there isn't that much to the web site of
> the Crane. It has a form for the coordinates and user name, and a php script
> that passes that off to a C program after input validation.
>
> The flow is like this:
>
> Website calls out to justin.tv, and takes user input.
>
> User input goes to a C program
>
> C program executes all the work to the crane, and triggers a shell script at
> start.
>
> Shell script talks to VLC daemon that is doing the video stream to update
> the subtitle.
>
>
> In the background is two programs, one is VLC that runs the capture from the
> camera, the other is a program that reads a metafile thing and feeds it to
> Justin.tv.
>
> This has changed from the earlier days, and I might have the C part wrong
> (there is a Crane Daemon that runs using a named pipe.)
>
> The C program uses system time to time the movement and store it, then when
> a user calls the crane it bases movement on that. It handles bit banging the
> parallel port to drive the motors (most of them have 1 bit for move, and 1
> bit for direction, with the exception of the claw grab which is 1 bit to
> trigger.) It also reads inputs to know when the carriage is all the way to
> the left right/front back, or if the claw is up, or if it's bottomed out.
>
> Really all the work is in the C program that moves it, which is a
> representation of the original hardware that drove it.
>
> If the C program dies or malfunctions, it will ruin the hardware.

I can mod it for some signal handling.


> The other problem with using the parallel port is that on system boot it
> comes up in a random state, is bad. I'm thinking of adding some sort of
> watchdog.

Doesn't udev correct this  Where device ids are basically hashed
values that are always unique.


> I told Adam that really there isn't much to the website at all. People have
> talked about making it so that you can steer thing thing around real time in
> all 4 directions, then drop. That'd be cool, but it will require a total
> redo of the hardware system behind moving the claw. Stepper motors would be
> one option, which brings in the issue of worm gears that fit the motors, and
> custom mounts to mount the motors, and a cost behind drive electronics. Or
> keeping linear motors there would need to be some sort of feedback to tell
> the carriage movement (not just motor movent, optical encoders won't work
> because there is slip on the wheels that move the thing.)

I have a test c prog on there that lets you control the crane with the
arrow keys.  So theoretically an interface should be able to
reasonably do the same, just have to be careful of delays from the
webcontroller.


> You don't want the claw dropping in home zone.

When user input is validated from the php side of things, that is one
limit it checks.  I forgot the range, but yes we do prevent that case
pending the user is talking to the crane via the web interface.

-Matt