Google Lunar XPrize

[Jonathan]

I finally realized what I did wrong with svn. Did everyone else get it working? Doesn't look like much happened yet.

[Lucifer]

It's working for me.

I've got tests and crap going on this week and next week, so we'll see when I can start doing more than writing the plan. I did answer a comment you'd written when it was still a google doc, and got it somewhat to output a decent formatted pdf.

[Lucifer]

Well then. Here ya go:

http://playerstage.sourceforge.net/

Simulator and everything. Get to work!

Edit:

Ok, I've checked out player more seriously than that drive-by posting. I'm inclined to go with it, quite honestly. It's got the first couple of stages in the plan I wrote already knocked out. Further, I'm inclined to go with Ada for the language after reading about its history and looking at a couple of tutorials. It basically has the advantages I see in python, but without the disadvantages (i.e. it's not interpreted anyway, use GNAT to compile it, and GNAT was funded by the US Air Force). Any language that's good enough to run spacecraft is good enough for me.

The preference for ada is largely due to my dislike of both java and c++ and the fact that the python library for player is out of date. We can still go with python, but that would require updating the library or starting with a new library.

Player itself is used pretty extensively for research, and I realize that says absolutely nothing about its reliability. But it does have ubuntu packages available, which is a huge plus imo. Where the rubber meets the road, we might be able to put together the entire embedded OS with ubuntu tools, and that's a big plus. Player already supports a wide variety of hardware, so we should be able to reasonably achieve a prototype rover with player and PC hardware. That's the demo prototype I think I mentioned before, intended to show the software stack and a working rover.

So, I'd like you guys to check it out and raise any serious objections you find. There is the issue of the robot stuff not running in windows, but I'm sure I can make it possible for any windows developers to run player in a simulator on a linux server, and they can probably compile their clients and run them in windows. We'll see, maybe we'll need a mechanism for uploading a current codebase to the server to build and run.

[Lucifer]

Ok, apparently there's a whole slew of robotics applications on sourceforge. Looks like player's main competitor is Orca. Orca doesn't come with a simulator, though. In fact, none of the others come with a simulator, but there are some standalone simulators available. Orca has the benefit of at least some windows support, but to be honest, I have to say I don't care if it supports windows. We're not loading windows onto a rover that's expected to run on the moon. Maybe VirtualBox can run a linux installation for windows developers. The OS issue that I'm concerned about is whether or not we can run Linux or a bsd on the hardware we're going to need to run on the moon.

On the subject of radiation, I talked to a guy today who informed me that the Van Allen belts will be a real problem. The radiation there will actually change the transistors in a microchip, meaning we may have loss of data (which we'll immediately reload) and significant loss of capability. He was more concerned about that than solar radiation on the surface of the moon, and just powering down the system for the transit won't work, the radiation hurts the hardware directly. So on the list of things to research, what radiation is actually in the Van Allen belts? (Wikipedia probably has the answer) Then, what shielding is available? If we shield against the Van Allen belts, does that constitute the ability to survive the radiation on the moon?

Anyway, for software I'm still leaning towards Player because it comes with a simulator. Orca has some interesting projects using it, but Player has a pretty long laundry list of researchers using it.

So here's a task. Everybody go pick one robotics project comparable to player and orca and write up a post telling us what's good, what's bad, how big their respective communities are (this gives an idea of how healthy the projects are), most recent release, languages supported, etc. Simulators are fair game for this, there's a few simulators there that looked very interesting but I didn't dig deeper.

Here's a link:

http://sourceforge.net/softwaremap/trov ... rm_cat=602

You might be able to google up more if you want.

[Self_Destructo]

I'll get around to reading all this, but I wanted to say that I am a very experienced solderer; from Micro D connectors to computer chips, and I can offer my help in at least that way. And who knows, in 3-4 years my business (JG Worldwide Enterprises, LLC) may actually be big enough to fund a nice chunk of this project.

[Lucifer]

Plenty of info on radiation:

http://www.nasa.gov/offices/oce/llis/0824.html

[Lucifer]

The more I learn, the more I think we should go with ada.

So, to get safely through the van allen belts, we need radiation hardened electronics. For processors, that means special processors. No idea what kind of boards we can put them on. Unfortunately, we're looking at dropping back to the 400mhz and slower range of processor. For memory, it's DRAM, but it's special DRAM. We may come up with some sort of radiation shielding after all, but I guess we'll have to see.

Laptops have been sent up and survived, anybody want to find out more about that for us?

Anyway, at the size we're looking at for what's currently in use in the embedded space market, we may not even be able to fit a python a interpreter in addition to the other things we need. Hell, we may not manage to get a BIOS (NASA's linux test required a custom bios written by nasa. Yes, they put linux on a satellite and tested it, or so one source I found indicated).

So we need to get small. The mars rovers and numerous other pieces of hardware from probes to satellites use ada for their code. Ada is also used in lots of avionics systems. So we're basically looking at a kernel, a program we write in ada, and if we're lucky, we might actually have a little bit of storage space. NASA puts everything in ram, and burns the software onto chips (presumably stuff that can be flashed for upgrades). We either need to spend lots of money to duplicate this or come up with a better solution.

So I tried to get the ada bindings for player working, and failed. Jonathan or kyle, would either of you like to tackle that? We haven't really picked player yet (meaning you guys haven't jumped in to tell me your opinions).

Since we really need to work with off the shelf stuff as much as possible, and there are numerous robotics programs that take care of significant parts of the draft plan I was working on, I think the first step is going to be evaluating and picking. We really need to wrap that up quickly, so I declare player to be the default choice and am going to experiment with it. If you guys check it out and are happy with the choice (it's not a perfect choice), then we can proceed. In the repo right now is a bot that's mostly the python example. Since I couldn't get the ada bindings working, I went ahead and started fooling with the python bindings. Maybe we'll ultimately have to come up with our own ada bindings, or maybe someone can get this guy's bindings working.

If you're not happy with player as a choice, then look around and pick something else and we'll talk. I want to put a time limit on how long we'll look at other choices mostly because looking at player has convinced me that as a default choice it'll do. We'd spend the next 6-12 months just getting to where player is already at. Anyway, I'd like to say a month. But I'd really like either agreement or affirmative quicker than that so we can start digging in for real. I might take another crack at the ada bindings, but I think it would be worthwhile for someone else to put some eyes on it and tell me what you come up with.

In case anyone missed this part, ada results in compiled binaries just like c or c++. It has a lot of built-in safety features that the others don't have, however. I'd rather pick ada over java from what I've seen of ada's syntax. It's surprisingly pythonic. (I suspect GVR took a fair amount of inspiration for python from ada) Also, building with ada is a cinch, mostly. There actually is a "standard" project format and build system, which everything else lacks.

[Lucifer]

Here's a pretty thorough discussion of linux on embedded space flight systems, but it's around 6 years old now:

http://flightlinux.gsfc.nasa.gov/docs/T ... eport.html

Also, here's a company that sells a complete board with memory and storage. No prices listed on the website, but the board looks neat.

http://spacemicro.com/index.html

Edit: I think I cracked open the radiation question.

http://radhome.gsfc.nasa.gov/radhome/environ.htm

Edit2: Couple more interesting links.

Parts search for stuff NASA's tested radiation effects (includes links to other sources):

http://radhome.gsfc.nasa.gov/radhome/Ra ... aBase.html

The real nasa radiation group home page:

http://radhome.gsfc.nasa.gov/top.htm

[Lucifer]

Ok, last post tonight, but I wanted to jot this stuff down.

I've proven to myself as much as I can without physically buying stuff and testing it that we'll have Linux available. We may wind up without linux, but with some other unix-like OS (VxWorks, more than likely). But I'm pretty well satisfied that we can code for regular pc hardware to prototype. We'll need money to do anything more than that, so the basic idea for development is still standing: code for pc hardware, build a cheap prototype with pc hardware and readily available cheap stuff, solicit funding from everyone under the sun.

I'm also satisfied knowing that we're looking at a very small computer system. I'm not satisfied with the fact, I'm satisfied with having a good idea what the target will be. It will be likely not faster than 400mhz, 32-128MB really slow ram, and if we're lucky we might get 8MB of storage space. No definite idea what communication bus will be available, so we'll need to be flexible in that area until we know what we're aiming for.

Those two paragraphs come from my research of the last couple of nights. I can't say I've put paid to what the final system will look like because we have to get much farther along in development, but we have an idea of the target.

The target will probably be able to run Player. If it doesn't, we'll have to do some recoding, but since Player provides a good abstraction, it'll be the player side of the fence we'll have to recode. So I'm willing to commit to using Player starting right now, pretty much. Linking that statement to my previous post on the subject, this means I'm willing to start coding with Player knowing that if you guys turn up something that's seriously better, we might have to throw away some or all of the player-oriented code that's written. I'm willing to do that if it comes down to it, but I'm willing to put a 70% probability that no amount of deep and thorough research is going to unseat player.

So that basically means we only have one decision to make. C++ or Ada? That's also independent of Player, really.

I'm going to sleep on this, but the way I'm seeing it, we can start up a parallel team to work on mechanical design already. Player pretty much knocks out most of the plan I was working on, but what's next is pretty obvious. Develop in parallel the rover control software and two versions of the rover itself: a cheap prototype we can start building now to test the software in the real world and the target rover we're trying to design that we may not be able to start building until we've accumulated some money.

Now I'm going to sleep on this.

[Jonathan]

That's a lot of things. I'll take a look at it in a bit.

[Concord]

So 8MB storage? Maybe?

So I guess downloading a Arma package is out. . .

[Jonathan]

The MERs had a 20 MIPS CPU, 128 MB RAM, and at least 256 MB of non-volatile memory. Why would we have a much higher clock speed (I doubt it needs 20 cycles per instruction) and much less non-volatile storage?

[Lucifer]

Here's a datasheet for the board I had in mind when I was posting. You'll notice the storage space is EEPROM and the ram is DRAM. (sdram? I forgot already)

kyle: we're already out for downloading an arma package, the rules say what has to be in each transmission.

[Lucifer]

Yay, I got the ada bindings to player to build. So there's an all clear for working on a player-based rover in ada.

Basic minimum features (to be added to the plan documentation):

* Accept and handle multiple network connections to the rover control software directly.
* Transmit internal data to interested clients. (This sounds redundant to what player already provides, but we're talking about data structures that are specific to the rover control software and can't be had from within player)
* Accept movement commands from mission control software (the connected clients)

I have a vision of one or more programs running on desktop machines that give us a HUD, visual imagery of what the rover can see, the rover's internal map, and any/all vital signs. This may result in a rover control station that requires a multi-head display or several computers stuck together or something. That's fine, we can use hand-me-down hardware to build that part. This is also largely independent of the choice of player/stage for development. I'd like these desktop apps written in PyQt4 for maximum portability and fastest development time. Probably I'll throw up a basic framework for it so you guys won't have to spend too much time learning python and qt.

So, to check out the ada rover that's there (which is a boilerplate test bot from the ada bindings), it's in rover/adabranch . There's build instructions, you'll need gnat to build, and you need to have whatever development packages are required for player (or install player from source).

We'll probably wind up with a wrapper script that starts player and the rover control software. But it's not there yet, so to see the rover working, do something like this:

In one terminal:

Code: Select all

cd simulator/simpleworld
player simple.cfg  # If you installed player with ubuntu packages, the executable is called "robot-player"

In another terminal:

Code: Select all

cd rover/adabranch
./trevor

Watch what happens in the stage window. I'm probably going to move the adabranch to the trunk pretty soon, no need to work on a python bot.

[kyle]

kyle: we're already out for downloading an arma package, the rules say what has to be in each transmission.

no once we win all the prizes we can tackle that