wbthomason
Joined 13 years ago
Karma
83
Submissions
13
Member since
Jan 4
Recent submissions
Comment · 4 years ago
I have similar feelings toward ROS, but I don't have experience with industrial alternatives. Would you be willing to elaborate (insofar as you're allowed to) about what made the "step-function" level of difference between ROS and the internal systems you've used? Or on what you would want to see in such a next-generation system?
Comment · 4 years ago
One small downside of Blaze vs. Eigen for robotics is that Blaze seems to lack the highly convenient geometry types and operations that Eigen ships with. This wouldn't be difficult to build on top of Blaze (and could lead to some interesting performance comparisons), but does present some additional work necessary to use Blaze in many robotics applications.
Comment · 4 years ago
Thanks, this looks promising indeed! Especially because it similarly supports custom scalar types: https://bitbucket.org/blaze-lib/blaze/wiki/Vector%20and%20Ma...
Comment · 4 years ago
Huh, interesting - this is news to me, as I use Eigen all the time/see it used all over for robotics. Is there a good replacement for robotics-specific operations/small matrices generally (I see some people mentioning DirectXMath?)? Or is the tradeoff just between spending the time and effort to write SIMD intrinsics yourself vs. lower performance but greater convenience with Eigen?
One advantage of Eigen's approach that I haven't seen mentioned here is that its templated design makes it easy to substitute custom scalar types for operations, which helps enable straightforward automatic differentiation and other such tools (e.g. I'm currently using Eigen to make a tracing JIT for computations like FK, etc. over scenegraphs).
Comment · 5 years ago
Totally fair, yep. Thanks again!
Comment · 5 years ago
This is an interesting read, thanks!
I'm a bit surprised by https://viralinstruction.com/posts/badjulia/#julia_cant_easi... - I've been considering embedding Julia (as opposed to LuaJIT) in a project I'm working on that requires fast, mostly numerical computation.
Based on https://docs.julialang.org/en/v1/manual/embedding/, this seemed fairly simple, and as though I could avoid repeatedly paying the compile time latency cost by just calling my embedded functions at least once before the performance-critical loop (to ensure that they're compiled). Is that not the case? There's definitely still the high memory overhead to consider, but (admittedly without having tried it yet), embedding Julia doesn't seem too terrible to do. Worse than e.g. compiling a shared object library or something, but not at all unreasonably hard.
Comment · 10 years ago
Great, I hope it works for you!
Comment · 10 years ago
There's also Wmail[1], which I've been using for the past few months. It's essentially just an Electron wrapper around the web app, with all that entails. It's worked fairly well for me, though, and enables easier inbox switching.
Comment · 12 years ago
We're planning on it! We'll be doing a write-up of the whole process and stack, to be posted after the launch. We're actually using an analog transceiver designed for FPV use to transmit video to the ground, and a separate digital transceiver to send telemetry down and receive commands.
Comment · 12 years ago
What platform/browser are you on?
Comment · 12 years ago
Sorry, we meant for the text beneath the counter and the tweet feed to give details on the event. You'll be able to control where our camera points during the flight.
Comment · 13 years ago
I was one of the students in this course. If you're interested, I would recommend reading the professor's "course wrap-up"(http://rust-class.org/pages/course-wrapup.html) - it discusses his philosophy going into the semester. In particular, it addresses the most common comment I've seen in this thread, namely the rationale behind choosing to focus on general systems coding rather than kernel hacking.
Personally, I found the course enjoyable and worthwhile. It was not what I was expecting, and I was admittedly disappointed that we didn't go much into actual bare-metal programming. That said, I found it to be a good introduction to the concepts of systems programming, with a few detours. As I am interested in OS coding, I'm performing my own independent study to learn the material which might have been covered in a more "traditional" OS course, but the course did a solid job of covering concurrency, memory allocation, etc.
As for the choice of Rust: I really like the language, and plan to continue using it for personal projects. I'm not sure it was quite mature enough for exclusive use this past semester (the 0.7 to 0.8 switch midway through threw the TAs for a bit of a loop), but I've been very impressed so far, and think that this coming semester of the course (which will also use Rust) should have a much better time of it. The one annoyance I had with Rust was the lack of documentation, but the Rust community (including a fair number of those in this thread) were incredibly helpful, and I'm currently working on a project to provide an alternate tutorial, using a series of small "stepping-stone" programs to build from "Hello, World" to a MapReduce implementation. Personally, I think I might have picked either Go or a blend of C and Rust for this past semester, but Rust is becoming a better choice as time proceeds.
I was also one of the members on the student team that made the ARM kernel in Rust. Due to the timing of the project (right in the middle of preparation for final exams and the rest of our end-of-semester project due dates) and some "lazily evaluated" work ethic on the part of our team, it was fairly rushed, and is much less complete and polished than I would like. I'm planning on continuing work on it. Though I would disagree with the assertion that separating Rust from its runtime is as "painless" as it has been said to be, it wasn't terribly difficult, and solutions for that particular problem are also constantly being improved.
https://wbthomason.github.io