I’ve also got my own open source Rover design if you like this kind of thing:
We aren't NASA or JPL but a non-profit based in Greece. We already run SatNOGS (a network of satellite ground-stations), UPSat (the 1st satellite with components mainly under the CERN Open Hardware License) and on the side we work on amateur high power rocketry telemetry and PocketQubes.
Recently checked in on the website and saw the building instructions have gotten better and much clearer.
I'm very curious about things like, what kind of wheels you need for regolith, how to manage extreme temperatures (electronics, motors, batteries, cameras), how communication works (could you have a remotely-operated lunar rover?), dealing with radiation (SpaceX works with consumer electronics AFAIK, but they mostly fly within Earth's magnetosphere, which ... changes things).
Any replies or emails would be extremely appreciated.
I think what you are talking about is mostly just normal engineering in the sense that the process is similar. What really makes space unique isn't space as such but that there is no real-world (real-space?) testing, no inspections after the fact or do-overs.
This is sort of true?
Spacecraft of all types are subject to a battery of physical tests before launch. This includes vacuum testing, thermal cycling and vibration (where many parts fail). There are normally duplicate components produced for different purposes. Some are just for testing the fit, others are to check that thermal expansion isn't a problem and so on. The actual flight hardware itself is usually tested as well, since it's designed to be repeatedly stressed within certain physical limits.
NASA has duplicate rovers in the lab that commands are tested on. Before a mission plan is uploaded, it's tested on the ground system to make sure that, for example, an inspection arm doesn't collide with the body of the rover. Modern rovers like curiosity are reasonably good at self-inspection, since it can take a 360 selfie. The rover is covered with calibration points, for example to measure how much dust is covering things and how far the wheels have worn down.
A lot of "testing" is gained through experience. Satellite manufacturers know what designs work based on prior designs. NASA learns a lot every time they put a new rover on Mars. Rover missions (like Curiosity, Spirit/Opportunity, etc) tend to outperform their original specs because the engineering is so conservative.
In very rare cases astronauts have done in-space inspections - for example the repairs to Hubble. The ISS is also used as a space-based testing laboratory for hundreds of different projects.
(I've worked in a space science laboratory where satellites were routinely tested, and indirectly on rover data).
This is becoming less true today as engineering problems become more complex and simulation tools become more capable. Most automotive manufacturers have virtual models of their vehicles in testing long before the first nut meets it's bolt.
If you parse the user community and external repos you will find specific code & models for some of those use cases
Do note that JPL also uses other tool chains, some open, with similar communities and repos. I'm not as knowledgeable to what extent they use these, ymmv (pun intended)
the fundamental point I would try to convey is that you can learn as they do - through trial and error via simulation.
Phil Metzger, a scientist who was at NASA Swamp Works for many years and is now in academia, has attended the competition every year. He also ended up at the top of Hacker News 4 months ago in an unfortunate situation. 
Yes. The Soviet Lunokhod program built and flew two successfully in the early 1970s. I don't know the details of how they did this, but it would make sense to use more automation today. A 2.6 second ping time is long enough that pilots who have played modern video games are likely to complain :).
These are just simple issues that came to my mind. No idea how relevant they are, and if there are more relevant issues.
I can at least answer this part of the question. (I have had NASA contracts working on radiation tech, though not in that sector currently)
You can use COTS. Just depends how reliable you want it. There's a good interview on EEV blog with one of the XPrize contestants.  He talks in detail about how they handle radiation (they basically don't and hope for the best).
If you have a mission critical design or are sending to a more extreme environment, like Mars, then you actually have to deal with radiation. Commonly this is done with rad hard chips. Instead of silicon they use sapphire. Sapphire is what is considered rad hard. Downside is that these chips tend to be older and not nearly as powerful as current technology. They will also encase more vital parts in tungsten (especially see Jovian probe designs). Good news is that there's lots of work being done to determine how to make COTS viable (also a LOT cheaper). There's plenty of NASA SBIR/STTR topics on the subject if you want to try your hand at it AND get paid! Note: many abstracts for proposals are public, so you can see what others are attempting.
As for LEO and MEO, again it depends on how mission critical you are. Companies like Planet Labs (LEO) don't really concern themselves with radiation (most cube sats don't). They will just reprogram their satellites or take the hit. Typically GEO satellites are very rad hard, because the nature of the mission is to be there a long time and it is extremely expensive to get into that orbit. Typically they go with the tungsten box and rad hard chip design.
On the ISS they do a fair amount of research testing shielding. But they are also concerned with debris. So while you may know about aluminum other materials that are good also include Kevlar and Spectra (Ultra High Molecular Weight PE: which is used in grocery bags). People are experimenting with doping these materials, interweaving, different layering conditions, and all sorts of things. Pretty fascinating (and frustrating) work. Hydrogens help get rid of neutrons but you need dense materials for neutrons AND everything else. Note: ISS is in LEO and though you'd get lethal dosages on extended stays with no shielding, rad levels are fairly low.
Btw, lots of this work can be done with only some basic understanding of particle physics and can be tested with open source tools like GEANT4! (there are better non-open source tools) Since it is one of these extremely large solution spaces, who knows, you might get lucky! You can play around with different low density materials (like plastics) and high density materials or metals. Goal is light, cheap, and effective.
 https://www.youtube.com/watch?v=nJLOZDPTp3I (3? episodes. There's a few)
 http://geant4.web.cern.ch/ (this is difficult. I do have some tutorials if anyone is interested)
P.S. I can also talk about some of the other stuff, but in less detail since it wasn't my focus. But figured this was long winded enough. Let me know if there is more interest.
Thanks for everything! There's definitely more interest! I'm now going through all the links everybody posted, and all the other resources I've found... I'd be happy to chat more, here or over email (in my profile). I'm also researching other things, like engine control, comms, etc. until I know what to focus on.
edit: the motors also are going to cost around $500
Dead laptop and power tool battery packs usually have at least some useable 18650 cells in them. A friend has built more than one battery pack for electric scooter out of harvested cells.
You do have to know what you're doing when working with unprotected cells though.
That's a little pricey for most. But I'd imagine a school class would be able to afford that if it was going to be worked on by 30 - 40 students?
The one we had at work could easily drive with a large adult (i.e. 80+ kg) sitting on it.
I mention SuperDroid because their chassis are high quality welded aluminium, chain driven wheels etc. They sell to hobbyists (robot wars) and industrial markets including law enforcement.
Most of the markup is on the frame. If you have acess to a welder and something to cut aluminium you could do it a lot more cheaply. And yes, high quality motors with encoders cost $150 each. As always, you can go cheap as a hobbyist and pay with your time.
If you want something semi autonomous you can buy a Clearpath Husky for about $20k.
I'm sure there are many other versions, created by rover-loving hobbyists around the world.
https://www.robomaster.com/ , Chinese national robot competition with almost 200 teams competing each year,
runs ~$10K bot teams, and those are build mainly from off the shelf DJI components.
NASA is a very large organization with thousands of different projects ongoing at any given time. For many smaller projects like this, it's really up to the whim of the project lead what unit system is used.
My main experience being my participation two years in a row in the Intelligent Ground Vehicle Competition (IGVC). A college competition to develop self-driving rovers and "cars" (golf carts). There were around 40 teams from various colleges (several international, not just usa) and many of the teams used xbox controllers for manual control including my team.
I am so optimistic for the future of humanity.
The real rover code is all hardcore C. Erann Gat gave a presentation on the Lisp Conference about the JPL rover code and simulation.
I have seen open source self-leveling two wheeled platforms (segway without the yoke) but I have not seen a self leveling platform on a 4-6 wheeled vehicle like this one ...
There are also some safety implications centered around determinism etc which mean interpreted languages are a bit more gray area; with a well understood compiler and language you understand what the code is doing better, and you know it will run the same every time. That may be the case with python if you understand the whole shebang, but not that many people do... And if you have that level of knowledge of python, you may as well be writing C or C++.
AFAIK critical software coding standards forbid dynamic memory allocation, so things like stack overflows, null dereference or out-of-memory errors can't happen, but array-out-of-bounds exceptions can still get you. On the other hand, static verification tools catch most of that.
The industry used to use Fortran / Ada quite extensively, and depending on company/organisation and team, might still do so. Things like the F-35 are written in C++, which is where I can see these things heading.
That being said, stack overflows and null derefs are not caused by dynamic memory allocation, so you still have to be careful about those and use some other rules / tools to protect you.
For non-earth you’d probably just want to start again.