Saturday, October 18, 2014

Mars Time Notes

Ah, glad I signed up for this whole 'Mars Clock' thing. I thought it would be as simple.

No.

Some links:

http://www.giss.nasa.gov/tools/mars24/
Mars24, sorta kinda the source.

http://www-mars.lmd.jussieu.fr/mars/time/martian_time.html
Sol conversion applet and some milestone dates to check that things agree.

http://ssd.jpl.nasa.gov/tc.cgi#top
Another converter; Julian dates this time.

http://www.giss.nasa.gov/tools/mars24/help/algorithm.html
A conversion method with an example; this is what Mars24 implements.

What I'll probably end up doing is this:

1. A wake-up inital timing every day, where the RTC is used to calculate a Mars time (AMT? or whatever...).

2. An Arduino millis() timer with alternating counts of 1027 and 1028 ms per 'Mars Second', although there actually is no such thing as 'Mars Seconds', it's just for display purposes.

3. A 1 ms subtraction every two minutes

4. A final 36 ms subtraction every day, and it should be accurate enough.

Actually, I'm not sure about the daily adjustment... I might just let the system reset overnight during low solar power and then recalc the new start time every morning.

BTW: There are two other reasons I'm doing this:

1. Comet Siding-Spring has it's closest approach tomorrow. I'll probably forget while I'm doing errands. Boo.

2. The solar panel / charger / battery and all of the associated logic to manage power is identical to that planned for Rover6, and it's power management scheduling.

For now, that is all...

Friday, October 17, 2014

Light reading?

If you want some terrific entertainment, head over to http://marsandme.blogspot.ca.

Or, if you'd prefer one of the best bits of documentation on real Mars rovers head here instead: http://marsandme.blogspot.ca (or is that http://marsandme.blogspot.com in the USA?)

I'm not joking, that's the blog of Scott Maxwell, one of the MER Rover Planners, or 'Rover Drivers'. He intentionally delayed it 5 years, I guess because he had to play by the rules, but whatever - it's still a great read, and chock full of good info.

I'm reading it a bit late, and I'm only at Sprit Sol 338, so it's just getting good. I think I'll have to go back and re-read it again, but this time capture all the interesting technical bits in a file. There are a lot of little things I didn't know about MER hardware (like dynamic brakes), and a lot of interesting situations that illustrate why a fully autonomous rover is such a challenge.

One thing it did remind me to do before it's too late: build a Mars Sol Clock.

Soon (2020?) there will be another rover on Mars, and there are still two good rovers there - I'm not betting against Oppy - and I'd like to know which Sol they are on, and how many earth days until significant events in the 2020 mission, like launch, MCC's, and EDL.

I've just ordered the parts, and it's about $150 (a bit on the spendy side), but like MER it's solar powered, which at least doubles the price. Once the parts arrive I'll do a post and release some code for it.

Unitl next time, I'll just give you a hint.



Thanksgiving Updates

It's Thanksgiving in Canada, in case you're wondering. For reasons I don't care about, it's not on the same day as the US version, which is fine with me because it makes for a long weekend this month, and I'll get enough time off soon enough, but the break is nice to have now.

I've been super busy with my distracting day-job; it really requires all day focus and attention, and that means less rover building, which sucks. The interesting aspect of it is that the teams I work with are mix of people with wildly different amounts of technical, project, engineering, and operational experience. This makes for some interesting cross-over with the rover, since there are some basics with all of those things that are almost universal.

But I do have some free time here and there to keep on plugging away on some of the small stuff. I've been avoiding the 'big chunk' - the primary rover logic - until I have enough planned time off to get it done in one slug. So for now - small stuff.

One example I recently knocked off was the camera system, and an attempt to make thumbnail images small, and also predictably small. I'd thought about just using whatever imagemagick outputs as downsized jpegs, but I found they don't always end up 'small'. The reason for 'predictably small' is that I'd decided to split the radio communications into a separate module, and I wanted the radio itself capable of buffering a bit of uplink/downlink data without the rover being 100% powered on. There is a type of memory called FRAM, or Ferroelectric RAM, which is easy to use and fairly roomy; Adafruit has an I2C interfaced 32kB module that looks about right.

I decided to carve up the memory roughly into 8K quarters, like so:

  1. Comm Table
  2. CMD Table
  3. Engineering Log
  4. Last Thumbnail
I'll talk about the first three sections later, but I want to start with the thumbnail system; everyone likes a pretty picture.

This means that last thumbnail image can be at most 8K. I had decided that it's likely I'd use an HD webcam (or pair of them) as the primary imagers (a decision I'm re-thinking, actually). One image, at HD sizes, is huge. I wondered how small it could be, and found that in some cases jpegs of 160x90 pixels still wouldn't compress below 12K. 

So if you want something done right, you do it yourself. I opted for a representation similar to jpeg, using the red channel as an RLE monochrome image, and a second table of 2x2 pixels of blue and green offsets. Using a Run Length Encoding scheme means that at worst, the image never grows above 7200 bytes. Each byte is actually two pixels, and within that the brightness value

Here is a sample result, comparing the source to different views of the compressed data:




Some stats and info

Across the top row are images scaled to the same size:

- The 'Source JPEG' is 1280x720, a still from a Logitech 920 webcam. It looks far worse in outdoor/daylight than I expected, because it does a great job as an indoor video conference cam.

- Compressed JPEG is a 2x scaled view of what imagemagick did at a reasonable compression quality.

- The RLE+Color image is a 2x scaled view of my compressed thumbnail.

Below that is a 2x view of the red channel, which is combined with the color table info.

The next row are the same three images, all at 160x90, which is actual size for the thumbs.

The color data is much smaller; it's based on the blue and green offsets from the average from the 2x2 red channel, so it's only 80x45 pixels, or 3600 bytes.

In circumstances where the RLE red channel is compressed small enough, around 4500 bytes, the color table can go along for the ride. And if the jpeg is small enough, it can go instead, since they look better.

Here are a couple more examples:




That's all for now. The Walking Dead season opener has started, and I'm missing out :)