Hi everyone, I have just signed up after seeing odrive on Thomas Sanladerer’s YouTube video and found a few similarities with something I’ve been working on.
My idea is a scara arm milling machine. I know it’s never going to be as rigid as a Bridgeport but that wasn’t my biggest problem, it is eliminating backlash.
Very low backlash gearboxes are very expensive so I could either use a very large ratio single stage reduction with huge wheels which would restrict access and visibility or use a servo motor with the encoder on the final gear.
As I couldn’t find any very high resolution encoders I was working on the big single stage idea with the large worm gears under the table (and having to hob the gears myself). Then I started thinking about any consumer products I could use as an encoder and came up with tape recorders. If I could use a magnetic tape and tape head as an encoder which led me to CD’s.
My idea is to write a CD with a continuous track of 10101… and read with a standard cd head.
CD’s use complex encoding but without this you could get resolution of 2.25 million per revolution using either rising or falling edges or 4.5 million using both on the outside edge of the disc.
CD’s are written in a spiral but this would not matter for my application as I only need half a revolution. And even if you used 1000 revolutions the you would only be out by 0.0027%.
There will obviously be a bit of work getting a microcontroller to read from the CD head and control the tracking as well as how to write the cd in the first place but I think that’d doable.
A single one bit track will only give distance not direction or absolute position but fourbbit grey code would possibly work to give direction once two full codes are read.
Anyway it’s just in my head at the moment so if anyone has any ideas or wants to try it out I’d welcome your input.
That’s a really interesting idea! Let us know how it goes! At those data rates you’ll probably want to give it some sort of digital interface to talk to the ODrive rather than relying on pulses. And if you’re going to the trouble, a grey code (or similar) absolute encoder is a great idea.
Your idea on the CD’s for codewheels intrigued me and I’ve been researching the past couple hours. I found this post to be of great interest and figured you would too, assuming you haven’t come across it already. http://www.diyouware.com/node/161 Importantly, it describes the auto-focus process which you will definitely be needing on a milling machine due to the vibrations and such.
I’ve been looking in to how to go about “drawing” the data to the CD. One hurdle is that the filesystem dictates how the bits are actually encoded and thus their physical layout. To draw the bits raw, you’d need low level access to the drive which a standard driver (probably? Being pessimistic here.) doesn’t provide. Ideally this would be something anyone could do with any burner, so I think the best way to go about this is to encode the “file” accordingly, so that even with the filesystem encoding alterations, the “image” comes out as desired.
https://en.wikipedia.org/wiki/DiscT@2 Yamaha did some related work back in the early 2000’s. Eventually wound up as LabelFlash. LabelFlash and LightScribe don’t expose an API that takes advantage of the data side’s resolution. I think they’re limited to 1800DPI or so.
I’m not sure if the standard file system would work or not but I did think about modified firmware on the dvd to write whatever you want.
The original Xbox dvd drive could be replaced with a pc dvd drive with hacked firmware. If hacked firmware is already available then further hacking to meet our needs might be possible.
The head focus might be a problem. Focusing on a spinning disc is one thing but if the disc is stationary and the head happens to be over a pit then the head will probably try to focus and have nothing to focus on. Then when the disc moves the head may miss several steps while it tries to focus.
If there is a high chance of missing stepps then the encoding has to be absolute and the resolution will be limited by the number bits required. Luckily a disc could be written specifically for each application, ie for my application I only need 180 degrees so the sequence could repeat every 180 degrees, other applications may require several revolutions.
Resolution would be further reduced be needing to read two complete blocks so that the direction of travel and consequetly whether or not to reverse the block if it was read backwards can be determined.
I’ll see if I can make sense of the cd file system. It might suit our needs as is for all I know.
I also have worries about the error rate in written CD’s. For an application requiring only a few revolutions I think multiple we could write multiple tracks or repeat the sequence several times in the same track and just skip to the next section or track if an error is found.
If the CD needs to be spinning, you could put one reader on the robot base, and one reader on the moving axis, and read the data from a spinning disc on both, then subtract the position in the data from each other to get the angle.
Been doing more reading lately… You should be able to use straight SCSI commands to control the burner at a low enough level to do what is needed (particularly, using the IOCTL_SCSI_PASS_THROUGH_DIRECT control code) . http://www.t10.org/lists/2op.htm for reference. The MMC-5 would also be of interest. I think this may be your best bet.
I do know there has been hacking done as far as altering firmware binaries to enable different write speeds, regions, and add support for oddball discs - however that has been (as far as I know) more of a hunt-and-jmp hexedit sort of process rather than compile-from-source.
Obviously this project has intrigued me; so I’ve bought a BD burner and a few of the xbox head units to tinker with. You should hop on the discord server - there’s much more than just ODrive support going on over there =)
Using two readers (one fixed, one on moving axis) relative to an independently spinning disc is an interesting idea, and would even work on ordinary encoder wheels. After “calibrating” for imperfections in the encoder wheel, you could in theory get very high resolution, since the spatial signal is transformed into a temporal one.
I like the idea of two heads and spinning the disc.
The data on the disc becomes almost irelevent, all you have to do is measure the time between the first and second head reading the same data and if you know the speed the disc is spinning at you can calculate the angle very precisely.
You could even use any audio cd and just read the time codes.
Problems I can see are, it’s very easy to know the linear velocity but we need the angular velocity and since the track is written in a spiral the relationship is constantly changing and at some point we would reach the end of the track.
I suspect we could skip back to the beginning of the track at an opertune moment but I’m not sure about the best way to accurately measure the angular velocity. Might be possible from the spindle motor.
FWIW there are already time codes on recordable media in the form of a “pregroove”. Choice of physical media will play a non-trivial part of this… e.g. DVD+ sports a pregroove wobble frequency of 817kHz versus 140kHz for DVD- and CD… however DVD+ has the time/address phase modulated, whereas DVD- and CD exhibit the values in their corresponding physical location. DVD+ wins for resilience to noise but relies on speed and DVD- and CD lose on noise but you can creep past the pit and pick the values out of the groove.
I did some work this weekend on the codewheel mastering side of things… So far just using SCSI passthrough to retrieve the Absolute Time In Pregroove info so that I can get the linear physical bit density and track width for the media. Next up is reading an SVG and doing the cartesian->polar shift and authoring a .CUE that can be burnt using “Disc At Once”.
Edit: Once I receive my PHR-803T optical pickups, the first thing I’m going to do is determine their voice coil movement envelope. It would be nice to discover +/- 1mm of travel from center as one could translate the laser across several cylinders to afford more clever encoding. Since we’re not dealing with a whole sled assembly (or traversing the entire span of the media) like a functioning optical drive I don’t think there will be as much reliance on timecode frames and other synchronization mechanisms; the voice coils should give us enough control to “blindly” move a discrete amount. There are also two more photocells on the pickup beyond the quadrant cell (used for astigmatic focusing) which provide a mechanism for calculating tracking error by detecting the ambient light reflected from the pregroove walls. Ultimately the goal would be some clever data encoding of neighboring cylinders and linear modulation (tangential the spiral) of the laser to pick up all the data per scan or similar.
The primary road-block in controlling the physical results of the disc is the Eight-to-Fourteen modulation process. This process happens just prior to the NZRI encoding and after supplying the drive with the user-data; it is not something that can be avoided. What really fouls things up in particular is the elimination of DC bias by choosing merging bits that result in as close to 0 a digital sum as possible (effectively inverting the sequence you wanted on the disc depending on its context/relationship to prior data that may or may not have been inverted). As the result of this process, not only is our “signal” of user-data diluted, but the difference in visual result between two very long and drastically different sequences of user-data is diminished to the point of being indistinguishable from each other naked-eye wise. My plan has been, worst case, to utilize the disc media as an extremely high resolution canvas for generic reflectance-based codewheels; something that you would use a linear photodiode array to read as opposed to a laser.
I am now looking closely at using the mere existence of data as the signal (though now at 50% contrast) by linking data frames across large gaps of sectors. I’d like to continue prototyping with CD-R’s as I am able to verify the results optically with a microscope, however the later formats relax some key constraints that may make me swap. I’m preferring optical verification for now because using all the bits at your disposal, you sacrifice error detection and correction of the sub-channels and the drive will read different values depending on what mood it is in. If I swap to smaller wavelength media then I’ll have to move to reading multiple times and using the median or similar as we’re knocking on the door of the diffraction limit.
All is not lost on the laser-read-head front, though. None of the encoding process is non-deterministic except for maybe a tie-condition of choosing merge bits for EFM - I’d have to get some sleep and think that one through (Edit: https://www.ecma-international.org/publications/files/ECMA-ST/Ecma-130.pdf selection of merging bits described on page 43… => if a tie, choose the one that inverts). EFMPlus (DVD) doesn’t use merging bits and is entirely deterministic. So while you would not be able to get 100% control, or even bit density, you could at least “know what you’d be looking for”.
Also - as far as multiple read heads go, the cross-interleaving as described in the spec already seems like a pretty good choice. And don’t forget about dual sided DVDs where you would have precise alignment of the bit-spirals between sides!