Robotics 501: Mathematics for Robotics • Hacker News Board

Re: Robotics 501: Mathematics for Robotics

#61

Post by melony » Fri, Jan 28, 2022, 1:19 AM UTC

BeetleB wrote: post #37

Archit3ch wrote: post #14

Earlier quoted context omitted.

> if you find a linear problem of huge size, you are just going to plug it into Matlab or whatever It depends on your viewpoint. Are you going to be the user who calls the MATLAB function, or the engineer who implements a specific iterative method, optimizes it for new hardware, and so on? I am trying to make the jump into the second category.

> Are you going to be the user who calls the MATLAB function, or the engineer who implements a specific iterative method, optimizes it for new hardware, and so on? 99% of engineers will be in the former. Of the remaining 1% who would like to be the ones implementing this stuff, about 90% will not get the job that lets them do it. Of those who do get that job, likely over 50% of them will hate it. Speaking as one who'…

Finally an honest answer.

Re: Robotics 501: Mathematics for Robotics

#62

Post by hcrisp » Fri, Jan 28, 2022, 1:46 AM UTC

biotinker wrote: post #35

hcrisp wrote: post #25

Earlier quoted context omitted.

Modern Robotics adopts the Product of Exponentials (PoE) mathematical approach (also known as screw-theoretic) over Denavit-Hartenberg (D-H) for forward kinematics . Do robotics companies use PoE in their written software or is D-H still the practical choice?

I work for Viam[0] and while all of our actual calculations are made using Spatial Vector Algebra[1], inputs can be made in a number of different ways and supporting DH is crucial for allowing pre-existing configurations to be easily brought over to our platform. SVA can also conveniently be easily used for both kinematics and dynamics. Personally I find SVA way more intuitive than DH or PoE. [0] https://www.viam.com…

Thanks for the reference to SVA. I found a pretty understandable set of intro slides [0] on Roy Featherstone's home page [1] under the Teaching Material section.

[0] zip file: http://royfeatherstone.org/teaching/IntroSpVec2021.zip

[1] http://royfeatherstone.org/

Re: Robotics 501: Mathematics for Robotics

#63

Post by pfortuny » Fri, Jan 28, 2022, 7:57 AM UTC

Tainnor wrote: post #46

pfortuny wrote: post #31

Earlier quoted context omitted.

Yes, of course, but those are not specific algorithms (except possibly the Gauss reduction method which deserves a special treatment because it is not "just a method of computing" but "a way of understanding" by itself).

Can you explain the difference between GJ as "the Gauss reduction method"? Because I haven't seen these terms used before in a way that makes a difference between them.

My bad!!!!!

I wanted to say Gauss-Seidel but got totally confused. What a mess I have done.

Sorry.

Re: Robotics 501: Mathematics for Robotics

#64

Post by ogoparootbbo » Fri, Jan 28, 2022, 7:53 PM UTC

iamcreasy wrote: post #60

neel_k wrote: post #18

Earlier quoted context omitted.

It sort of depends upon the course. This particular syllabus looks like a really standard linear algebra course (I have no idea what is robotics-specific about it), and so of course Gauss-Jordan would show up there. More generally, though, I think there are two main reasons to put algorithms like Gauss-Jordan in the engineering curriculum. 1. While it would be nice to treat linear algebra solvers as a perfect black b…

> To take a more positive view, a huge fraction of the algorithms in an undergraduate CS course -- from finite automata to parsing to relational algebra to graph traversals -- can be understood as basically doing linear algebra using modules over different semirings (rather than just the reals). Eg, for all-pairs shortest paths, the Floyd-Warshall algorithm is doing an LU decomposition, and Kleene's algorithm is doin…

https://www.semanticscholar.org/paper/Fun-with-semirings%3A-...