HN user
UBC does, or at least did, implement it across many of their physics and math courses. I'm not personally aware of on-going discussions, but there are many faculty members there and collaborators working on this stuff, as well as many students who served as the guinea pigs.
It's true that the laser frequency is sweeping, but it very well may not be over the same band. The sweep bandwidth in a typical lidar is likely in the 1-10GHz range. The carrier frequency of the laser that this modulation is riding on is probably in the neighborhood of 200THz. Let's say you're using a telecom laser at 1550nm. The actual wavelength of that laser will centered on some channel in the 1530-1580nm band, with each channel spaced by say 100GHz. So already each laser might intentionally be in a different channel, depending on chance and how many cars are there. But even if they are in the same channel, the chirp bandwidth is small compared to the channel bandwidth, so there will likely be at most only partial overlap, depending on where the respective center frequencies actually are. Unless your lidar is using a very expensive, very fiddly laser system, this center frequency will be drifting around within the channel all the time. It varies with temperature, mechanical stress, output power and a bunch of other stuff, depending on the type of laser. However, even if the lasers are magically in the same channel, and perfectly locked to the same center frequency, you still need the light be coherent to produce an interfering RF signal. They will not be coherent.
Certainly the balanced detectors will have finite CMRR. In general you definitely have to make a good detector but it doesn't need to reject to 100dBc. A photodiode might have 100dB of dynamic range, but most likely your RF front end does not, and more importantly for most applications you will be dominated by photon shot noise, so you don't need to push common mode signals all the way to your electronic noise floor. 35dB of rejection works wonders.
Yeah, it definitely can be shorter than 100ms. See my sibling comment. It just depends on the type of radar being used and the target range/velocity. Certainly for shortish range targets and mmwave radars on reasonably reflective targets you can get a signal with decent SNR in shorter time frames.
It depends entirely on what configuration of RADAR you've got, and what you're pointing it at. You can build a system that will result in returns with beat frequencies of just about anything, depending on the Tx modulation and the range. The question is whether it will be useful for your application in terms of range/velocity resolution, latency, integration time etc.
Like I said I was just speculating about why OP specifically mentioned 10-100ms. the light does indeed travel pretty quickly (although, as anybody in the radar/lidar industry will tell you, not nearly quickly enough!), however the round trip time is just the minimum latency you have to eat to get any information about your target. Once you have light coming back, you need to integrate for some about of time to achieve your desired SNR. That time could be very small, or it could be infinite if there are no photons coming back. Let's randomly say that you're using a RADAR with a Tx bandwidth situated such that the round trip time is 1us, and that your target range is s.t. the beat frequency of the return is 1kHz. Your job is to estimate that frequency, so you have to observe the waveform (by integrating samples for an FFT, typically) for at least one cycle of the RF wavelength. That would require that you wait 1us for the light to fly, and then wait another 1ms for the RF to cycle once. So your measurement latency is ~1ms. Now that's not 100ms, but perhaps you need more than one cycle to give a good estimate of the frequency, and then even more because the target is faint and there aren't many photons coming back. You could possibly arrive at some much higher number, like 10-100ms.
I'm not sure if that was OP's point, but that's all I'm saying ;-)
So your're correct that there is a Fourier Transform analogy for the uncertainty principle, but in the context of FMCW lidars (which brought up the question of velocity vs position uncertainty), the measurement of frequency actually determines both the position and the velocity. It's actually a problem for most FMCW lidars because you just get 1-2 frequency measurements and somehow need to disentangle what the range frequency is, as well as what the doppler (velocity) frequency is. A massive amount of effort has been put into developing lidar methods and architectures that solve this problem well.
But in summary, the uncertainty principle as encountered in quantum mechanics has ~nothing to do with a trade off between range accuracy and range uncertainty. It's possible that it could come into play in a very detailed treatment of FMCW lidar SNR, in the context of counting return photons, but also not generally necessary there. The time-frequency uncertainty plays a role in that the range and velocity resolution both get better the longer you stare at a signal. So for a given amount of reflected light, at a given range/velocity, there is a fundamental lower bound to how long you must integrate to a) get a signal at all and b) achieve a desired precision.
It really depends on the type of RADAR being used. If it's an FMCW radar, typically you will get a beat signal whose frequency corresponds to the target range. That frequency will vary with range, and in order to be well resolved you have to observe it for something like 1/period. So that puts a fundamental lower bound on how long you have to integrate. There are lots of tricks to improve things, and there are lots of variants of the standard radar hardware/methods, but I suspect that's what OP was referring to.
Actually most pulsed lidar systems use pretty high peak powers, which result in an eye-safe average power only because they are on for a sequence of very short pulses (~1ns). It's pretty unlikely OP is actually experiencing vision problems due to lidars, but it's probably possible for some kind of weird interaction to happen in the eyeball due to the high power pulses. Even so, it's unlikely to be causing an damage, temporary or otherwise. I would hope it doesn't happen to him/her while driving or something, though.
I suppose it will be a good while before we can approach an empirical proof for this sort of thing, since FMCW lidars are still very scarce, even more so than pulsed lidars right now. However, even if every car does have an FMCW lidar, the conditions required to get them to interfere with each other is are:
a) Have identical laser wavelength. Not just '905nm' or '1550nm', but _precisely_ the same wavelength. This is very hard to do even if you try.
b) Have a coincident beam path. Again, this needs to be very precisely aligned.
c) Have an overlapping coherence area. This is a bit technical, but it is a higher bar than just having spots spatially overlapping.
d) Have coherent+matching phase fronts at the detector. Again this is a fairly technical subject these properties vary along the beam path, and transversely. This also vary in time, temperature and many other things. The source lidar is able to 'interfere' with itself (in other words, get a signal), because it compensates for all of these effects with a local copy of the outgoing laser light. Other lidars' outgoing beams will in general, even for 100 cars, not be 'synced up' in this way.
Moreover, those conditions are just the intrinsic interference rejection properties of coherent lidars. Layered on top of that is that two lidars need to be using the same type of modulation, bullseye each other as they scan around the FOV, and provide enough photons to actually contribute to the signal. Then, if you satisfy all of those prerequisites, the interfering lidar also needs to overcome any heuristic/algorithmic rejection of spurious signals. Finally, if all of those conditions match up and you get a signal to punch through, and it's strong enough to over come the true signal, and you can't tell that it's an erroneous signal, then it will result on one bad/missing point in a frame of thousands of points, present for one frame.
You're correct, however, that there is a saturation issue. If you just DOS the photo diodes with photons you can potentially prevent any signals from getting through. But again, this isn't super easy to do. The detectors will almost certainly be balanced, not single ended, and AC coupled. So you really have to blast the photo diode, effectively bringing it up to it's damage threshold so it is just flooded with current and can't do anything, and/or just breaks. The raw laser light doesn't do much, both because the DC signal is rejected and because the balanced detectors will reject common mode signals (clearly you know this already). You also have the same issue with needing to shine into a very narrow field of view, at the right time, for long enough to matter.
Sorry I didn't see your responses until now. Indeed, there are many ways to slice the specific problem. I was specifically responding to the parent's statement:
It would be a game changer if someone were to come up with a novel method of decomposing audio into discrete components
It's something that has been generally addressed and ~works. It will obviously depend on the specifics of the application, and yes if you can constrain the problem space further you ought to do better!
The tools to do this exist. It's usually called 'blind source separation', as in "What are the N distinct audio signals which sum up to best explain a given compound signal, without knowing the possible source signals ahead of time." Usually it's done with some sort of matrix factorization, Principal Component Analysis, and/or Independent Component Analysis. It's also used for non-audio signals, like pulling the discrete firings out of noisy EEG signals. It's definitely not a foolproof solution but in a lot of applications it can get you going, at least.
I find it odd to state that ASC's lidars work, and just cost too much until there is sufficient volume, but then turn around and say that the pulsed lidar groups with working products (that work better than flash lidar, in fact) are too expensive. Presumably the same applies to them. ASC's focal plane arrays may be ICs that scale well, but they still need lasers, electronics, housings, lenses, and more. Just like everyone else.
It also seems odd to state that Lumotive isn't novel. The fact that people have made SLM based phased array beam steering is hardly germane to the Lumotive being able to put together a robust, wide aperture, high speed, high resolution beam steering technology, let alone a complete lidar. There is simply a lot more to getting this stuff to work than just reading some paper from 2004 about SLM based steering in the lab.
Also, no lidar OEMs have a "buy" button. You're suggesting that this is because it's all a scam? I think it's because they don't need or want to sell to you. They are all out making partnerships with large vendors. I'll grant that some companies do appear to have vaporware products (most famously Quanergy's solid state product), but the reason there are many companies working at it is being there is a need and lots of commercial potential. The commercial potential in this case comes from the automotive industry, so there is basically zero incentive to sell at a consumer level. Not even velodyne, who definitely has real products, sells over the web. Even Ouster, who prides themselves at being the "available now" high performance lidar company, doesn't have a "buy" button. Perhaps if you email their sales guys and then send them $4k they will send you a unit, but it remains that the business model isn't sustained on individual sales.
Finally, the continental lidar you linked has pretty bad angular resolution (~1deg) and no stated range. The latter probably being because flash lidar is at a fundamental disadvantage to scanned lidar. Instead of all the photons going to one place, they go everywhere. This scales very badly with range, so they will be power (SNR) limited. The only way to overcome this would be to have correspondingly more sensitive detectors, which I do not believe is the case. Even if they gang together many small flash lidars that look at narrow FOVs, those lidars would probably have to be close to one pixel wide to compete on SNR while staying eye safe, in which case you end up losing the "scales on a chip" economics. This might be one reason why Ouster still spins a pixel wide array rather than strobing many.
You think that Zhang odometry paper is good, you should see the stuff his grad student came up with for his thesis[0]. The results look almost as good as the figures from the Ouster blog post! ;-)
Amusingly, the question of "where to set the threshold" is actually a problem for pulsed lidar in general. What constitutes the pulse returning, and how do you know which pulse is dominant? In any case, my point was that I don't think they are implying that 20% is "the one true threshold" that determines if a LIDAR is sensitive enough. Indeed, many OEMs specify the bottom bracket at 10% already, and there will always be other variables such as weather and texture that will ruin your day no matter what threshold you chose.
As with software performance, it's all about reasonable benchmarking. If you're in some lidar application, for example building a self driving car, and you currently use velodyne HDL-64 sensors that can register returns from 10% targets at 80m, then Livox's specifications give you a clue as to how their unit might compare in a similar circumstance. That's all. Past that, you have to rig up a test with the unit yourself and profile, it's the only way. I'd also add that many objects would appear different in brightness if you looked at them under a pure wavelength like 905nm, rather than the while light your eye sees.
All that said, your concerns aren't misplaced. One of the leaders in the 'new wave' lidar OEMs is Luminar, and one of their original value propositions was that they went to a different wavelength (1550nm) which has a higher eye-safe power limit. This means that they could pump out higher energy pulses, and thus get more photons back from low reflectivity targets such as tires and dark cars. The jury is still out on what works best to cover the real world range of reflectivities, largely because there are just a lot more variables at play that a simple thresholding would imply.
If you're talking about how the human eye perceives light or dark objects, then yes it can be more complicated. Especially when colour is involved. That said, what they're talking about here when they say 'reflectivity' is the ratio of the power returned from an object to the power you shined onto it with your laser. The reflectivity will depend on the object surface texture, material, wavelength of light etc., but it only loosely corresponds to what you perceive as bright or dark.
The metric really just reflects (:-D) the signal-to-noise ratio and dynamic range of their sensor. Max range, min/max reflectivity, SNR, accuracy, and everything else are all intertwined, so it's very difficult to compare things on equal footing unless you know exactly how it was measured. LIDAR OEMs seem to have settled on a 10%/80% rule of thumb.
The problem with Musk's argument is that there isn't any indication so far that the machine learning has tricks up its sleeve that are sufficient resolve all of the ambiguous situations drivers come across. Having direct, accurate measurements of the environment serves as a ground truth that you don't have with just cameras. Humans don't have LIDAR, but we do have a different ground truth: we have a mental model of the world, and can reason about it. It's not just that we know things like 'fast cars take time to stop' or 'he looked at me so is probably aware of me', but rather being able to synthesize based on really complex behaviors we've never seen before, and in many cases, direct communication. All that is to say, there is a lot more to human drivers than their eyes, and for the moment there is nothing showing that we're on the cusp of developing real AI that can address those concerns. I don't think it's just a matter of labeling more data and GPUing bigger models.
So while Musk might be right if we get such AI, it's not clear that it's about to arrive, and even if it does, we can still use LIDAR. In fact chances are that if you have such great AI, additional sensor inputs will turn it from 'Level 5 Autonomous Pilot' to 'Ultra-super human pilot who can preemtively react to situations you didn't even realize were possible in the moment.'.
Of course there are questions at hand:
1. Is Elon right and I'm wrong? Maybe strong(er) AI is right around the corner. 2. Is current LIDAR tech good enough to reliably provide the ground-truth I spoke about?
Amusingly, Xilinx makes dev tools that are so unbelievably bad that it's almost impossible to do any of the best practices for development that you would hope for in safety critical systems. No source control, code review, reproducible builds, integration testing, centralized code review, etc.
Presumably you can sort of brute force it if you have defense level budgets, but it's a seriously bad situation.
Heh, or perhaps we could say that it's simply a short hand colloquialism for "on the order of 10 years"? ;-) As somebody with physics and engineering degrees, as well as 20 years of CS experience, I'd very much enjoy it if we'd stop perpetuating the idea that nobody without a PhD in CS understands asymptotic complexity.
In principle it can be done, of course, but it wouldn't be economical. The abrasive sludge that accumulates in the bottom of the machine is full of large and small bits of various different materials, which complicates filtering. Even if you only cut a single material, you end up with significant amounts of abraded metal from the machine parts (slats, fittings, clamps, etc.). You would also have to spend a significant amount of energy evaporating and drying the sludge.
In any case, the main problem is that the abrasive garnet particles become decidedly less abrasive once they've been smashed into a piece of steel at 75000psi. Think of it like one of those tumblers you use to smooth and polish stones to make them pretty.
EDIT: As someone else mentioned, it's also a QC issue. Even with brand new abrasive, you sometimes get the tiniest bit of something the wrong size or weight and the solenoid feeder gets jammed and has to be take apart. Recycled sand and who knows what else would be a nightmare. Waterjets are enough work to keep running as it stands ;-)
Source: ~7 years of using an Omax waterjet cutter.
I opened this thread in the morning, got to that '100 page' remark and belly laughed. Then my day took over, and I just refreshed and saw your comment, and belly laughed again. I'd say it's been a successful day. Thanks ;-)
The comparison to breaking out the PCB software is a touch misleading. You'd certainly also find it to be an onerous task to break out the PCB software and design a board for the Sitara SoC that sits on the Beaglebone. Realistically the comparison would be to use an FPGA devboard. Modern FPGAs often have an ARM processor build right into them, and if not you can use a Microblaze/NIOSII softcore processor in conjunction with the programmable logic. Such a setup will happily run linux, do your real-time tasks, and use all the typical peripherals that one of TIs soc's will.
I'm not saying that using an FPGA would be easier necessarily--indeed, likely not just because the tools a so terrible--but there are many options. Last I checked the documentation for the PRUs was pretty bad. Mostly a smattering of wiki pages and a couple powerpoints. And even that is a huge improvement over even just a year or two ago.
Also more possible haha. It's all fun and games until you predicate the success of your project on trying to collimate a laser beam from here to alpha centauri, so that it can manually assemble a (dielectric!) robot one piconewton at a time.
Sky's the limit.
Until you get a bigger antenna ;-)
This really strongly depends on your industry/focus, and what your end goal is. Some industries are completely dominated (library/community wise) by one or the other. I used to do finance work and strongly preferred python, so I tried hard to use it. (This was also before/right when pandas was out.) I was constantly plagued by needing some fitting routine e.g. for a vector GARCH model, and there was a package in R just sitting there. I was able to get very good mileage out of the RPy2 interface, though.
On the flip side, I've done a fair swath of work in the machine learning arena, and in particular the deep learning topics before it was called 'deep learning', and it was nearly hopeless to use anything except Python or MATLAB (both strongly tied in with C++/CUDA libaries). I think this is still largely the case.
As others have mentioned here, for me the biggest pull away from R was that it's not general purpose. Hard to ship someone R code. Hard to throw a web framework in front of your code. Hard to build a rich desktop GUI on top of it. I know you can do most of those things in R, but last time I dealt with it there was a massive ravine in usability/maturity. I'd also be insincere if I didn't admit that the pervasive R coding style just drove.me.fucking.crazy. That and I found that while there was a mindbogglingly large pile of libraries, documentations was usually very lacking.
/rant
Yeah the real reason you never get guides to this stuff is that when it comes down to making a successful prototype, what makes it good vs. just barely work or not work at all is somewhat of a black art. There is so much intuition and experience that goes behind decisions like what material to use, what kind of fastening, how to seal it, finish, how/where to route cables, what kind of cables, connectors, will-it-pass regulation XYZ, is it safe, etc. It's nigh impossible to really get all that into a guide, you really just have to go at it and learn (which includes reading what guides there are ;-).
Anyhow here are a few points that might be relevant to you:
- As someone else mentioned, unless you're in a money-is-no-object sort of group, usually at a large corporation like google, then you'll almost always start with some stock enclosure for testing purposes. There are tons of choices, from extruded aluminum to cast steel, bent sheet metal, ABS weather proof housings. The list goes on. No, it's not a custom box designed by Dang from Silicon Valley, but trust me there's crap you didn't think of yet for the stuff inside the box. One step at a time, and remember, Compromise is the Hypotenuse of the Conjoined Triangles of success.
- Next stop: Proto Case[0]. They will use your CAD, or you can use their custom 'box cad' package. They will do sheet metal, solid machined metal, powder coating, fasteners, everything. Not ultra cheap or anything but still a good deal if you value your time. I can't tell you how many hours I've spent fixing/remaking sheet metal enclosures when I accidentally bent a flange 2mm too long, or screwed up dimension scaling while waterjetting it. It takes time to become proficient, even if you have the tools.
- For 3D printing and such, there are tons of 'Maker' shops that have popped up over the years. I've used Ponoko[1] before, and while slightly slow and again not ultra cheap, the parts are nice. They do 3D printing of many sorts (ABS, PLA, sintered metal, powder ceramic, UV resin), as well as laser cutting. Note: Laser cutters are REALLY awesome for prototyping things. I use a laser cutter constantly when developing prototypes.
- For machining, check out the First Cut[2] service from protolabs. You send them a CAD model, they analyze it and then you use a flash plugin to select materials, tools, threading, etc. and click go. Last time I used them they did single approach 3-axis parts in Stainless, aluminum, mild steel, various plastics, and brass. They also do CNC turned parts (on a lathe). The parts are very high quality for the price. Beware: The tolerances are not super tight, and they won't make any guarantees about mating parts! They made parts that mate for me and it worked, but it's a bit of a gamble.
- Protolabs also does 3D printing, as well as small run injection molding[3]. I haven't used this service so I can't say much about it, other than that their advertised prices are significantly cheaper than getting tooling made and certified anywhere else.
- Locally vs. China? Well if you mean getting a production run done in Shenzen, then if you have to as the answer is probably 'local'.
Anyhow, this is just based on my experience. I'm by no means a manufacturing or design expert. But I've made and worked on countless prototypes for all sorts of applications (nuclear medicine, MRI imaging, thoracic surgery, industrial microscopy, POC blood testing) and what I've said has held true in my arena. One final hint: If you're thinking of taking some hardware device 'to market', stop and think HARD about who your market is, how big it is, and how much it will cost to get there. It's quite possible that a traditionally 'production run' isn't necessary to get started. Lots of hardware projects started small. Also, in my experience investors aren't too keen to accept risk of the 'will the prototype work', or 'do you have the expertise to scale the hardware' variety. So bear that in mind.
[0] http://www.protocase.com/products/electronic-enclosures/
Indeed, Broadcom doesn't even allow you to buy their proprietary SoC (at least, last I checked), so you can't make a knock off RPi board, or integrate the SoC and peripherals into a custom application board. You need to use an RPi directly or get some other Cortex-A53 chip with a comparable architecture.
That's really the crux of the whole idea, in my opinion. Even if IoT hasn't really materialized in any meaningful way yet, the fact of the matter is that the way current internet technologies work, there will be multiple parties inserted into the process, and none of them will be working for you. I just look at how blindingly difficult it is to even understand what my phone is doing, let alone control it, and that's all I need to know that I don't want _anything_ to do with IoT.
It probably sends somebody 'tips' about you ;-)
Indeed. The curvature of my humor might have been too subtle. Easily mistakable for a troll. Luckily I'm often too late to threads--as you can see--to be subject to getting mobbed with down votes ;-)
I dunno, the prize might be a little overblown. All-in it seems like a pretty marginal improvement if you ask me.