On Sol 998, #Perseverance moved farther southwest about 30m, to RMC 47.3056, apparently back toward Jurabi Point.
The map shows its new estimated location along with the (guessed) path it took and a new prediction for its next drive (green dashed line), just for fans.
This localization is based on metadata from just one image.
EDIT: The path for last drive changed to 'estimate' and is being updated as more metadata become available.
@PaulHammond51
Little Assistant gives me a number of about 9000 images that are still pending or something. It's going to take a while, if that's true.
@65dBnoise@PaulHammond51 Wow that's quite the backlog.
I wonder if the missing NAV images are just missing for us or for the team as well, it seems hard to do planning with this...
@stim3on@PaulHammond51
That's a number calculated from image reports, which are updated with a new_count as soon as new images become available in the pipeline. Usually there are small differences, but now those seem to be huge.
@65dBnoise@PaulHammond51 Thank you. Very interesting and strange revelation.
Can you please check the date_recieved_utc timestamp to see if that sheds some more light on the situation?
@65dBnoise@PaulHammond51
had to see for myself, the timestamp is "2023-12-12T01:06:56Z", so earlier today...
This image is version 01, so it's not a redownlinked version.
At the same time we know this image was available before...
Either they have a separate link to the rover where they sometimes get special images that are not archived, or the date_received timestamp is only updated when it is released to the public feed and not representative of actual downlink. `
I know the rover can downlink data directly to Earth, but AFAIK it's usually done during investigations for issues, I guess in those cases any images downlinked, may not go through the normal pipeline?
@stim3on@PaulHammond51
Not certain, but it seems that image metadata is generated somewhere between AMPCS and the "AWS Cloud" block in this diagram. Which means date/time stamps may not be coming from Mars in the form we see them.
@stim3on@PaulHammond51
I don't use the MRU utilities to fetch images, and haven't noticed a problem with the API so far. What I've noticed is that huge list of sols in the image reports which forces my code to query the database over and over to get any single new image appearing on a sol in the list. That long list being updated frequently makes the process inefficient.
Maybe I should have a look in Kevin's code for fetching images, to see if he does things differently.
@stim3on@PaulHammond51
Yes, I read the github issue, but I'm not sure the issue is with "full" vs "Full" or with "sample_type::full" vs "sample_type:full" <- single ':'. Normally upper/lower case shouldn't matter.
My fetches appear to download both SUPERCAM and NAVCAM / MCZ images without problems. I use sample_type::full, and haven't noticed an issue.
Add comment