Looks the same as all the other rocks around to be honest - it just happens to be in the direction of the sun at 2-4pm in the afternoon and so is getting some glinting going on when it's photographed.

Take the images about 5 hours earlier and I'd bet we be remarking just how 'shiny' this pile of rocks is
https://mars.nasa.gov/mars2020-raw-images/p...6_110085J01.png

This is the best I could do with the Sol 3 Mastcam Z images of the foreground.

https://sketchfab.com/3d-models/m2020-landi...7c685f31cf97c30

The entire sequence ( ncam00598 ) started at 18:34:56 LMST and finished at 19:25:36 LMST

Sunset based on local topography was 18:23 LMST

Ahh ok - they miss spoke at yesterdays thing then. This matches MSL Mastcam Left then

Jim has put out a Mastcam-Z filename decode guide

https://mastcamz.asu.edu/decoding-the-raw-p...mage-filenames/

It includes digits in there that describe the focal length in mm as three digits.

All the stereo pan images report 34mm for that - which matches the widest angle of Mastcam-Z MSL Mastcam Left.

Yes. Things should get back to normal at the weekend.

No - it isn't. The shiny rock is left of the distant mesa. The parachute and backshell are to the right of the distant mesa.

It's not great - but this is my agisoft metashape results with the Navcam images so far
https://sketchfab.com/3d-models/m2020-landi...7215aa7db2fb0c8

No - the backshell isn't in that direction.

Here is the basemap ( https://mars.nasa.gov/mars2020/mission/where-is-the-rover/ ) with hardware image ( https://www.uahirise.org/releases/persevera...ware-labels.jpg ) reprojected on to it. There is no hardware south of that distant mesa.

Turned on just before chute deploy - but behind the cover that comes off at deployment, hence some black frames at the start of the sequence

For the less technically minded among us...Ryan Kinnet has put up a page that grabs a listing with links to the PNG files that you can then use any browser-plugin-batch-downloader with

https://twitter.com/rover_18/status/1364309922167488512

I tried Firefox with 'DownloadThemAll' and it worked perfectly.

Meanwhile THIS GUY has python code to also grab the data
https://twitter.com/kevinmgill/status/1364311336000258048

I'm not sure what product you're trying to make that isn't put into the PDS with a large code base and expansive documentation in a few months time, just like HiRISE etc.

Easy test - go find the location in this map. If it's in this map - it's pre-EDL - it's just natural.

You don't mean this by any chance? This is pre-landing.

There are reasons to be critical about how things have gone in terms of getting data out to the public over the past few days. But this is absolutely untrue.

Those mosaics from Curiosity are auto-generated after images are received after every drive, and every time there are updated images to add to them. They get sent out to the MSL internal server, a thumbnail gets emailed out to the team, and it gets uploaded to the MSL public website all using the same end-of-pass script. https://mars.nasa.gov/msl/multimedia/mosaics/ . This is not ‘very secretive’. It’s about as proactively open as it’s possible to be. It happens entirely hands off - no human in the loop - automatically. If I have been on shift sequencing images ...that public website is the place I go to see the end result first thing in the morning. I would expect that M2020 will probably get to the same point in the near future.

MIPL isn’t secretive. They have posters and presentations about their work at almost every planetary science conference I’ve seen. See https://trs.jpl.nasa.gov/handle/2014/42355 for example. As for ‘conservative when it comes to releasing their code’ - most of the MIPL code base is open source

https://www-mipl.jpl.nasa.gov/vicar_open.html

I genuinely have no insider info for M2020 ECAM stuff - I'm guessing like everyone else - but it would appear....

Mars_Perseverance_RLB_0002_0667129492_604ECM_N0010052AUT_04096_00_2I3J01
Mars_Perseverance_RLG_0002_0667129481_373ECM_N0010052AUT_04096_00_2I3J01
Mars_Perseverance_RLR_0002_0667129466_057ECM_N0010052AUT_04096_00_2I3J01

Stack to an RGB image...... RLB being the Blue, RLG being the Green etc etc

Images like Mars_Perseverance_FRE_0000_0666958359_772ECM_N0010052AUT_04096_00_0LLJ01 - the E is raw and needs to be debayered ( I used Fitswork )

A is the pair connected to the A flight computer, and B is the pair connected to the B flight computer

Image from https://link.springer.com/article/10.1007/s11214-020-00765-9

Sorry to belabor this point - but they are not. I asked the EDL Phase lead. I refer you again to this paper : https://ieeexplore.ieee.org/stamp/stamp.jsp...rnumber=8742167

Yup - the 'eyes' caption is just flat out wrong - I've let them know.

As you run out of fuel you can get a mix of fuel and pressurizing gas coming through the pipelines together and bad things can happen.

tl;dr don't run a rocket dry. Bad things happen.

Shut the engines down after they've done all they need to and the problem goes away. Moreover - the longer you run those engines, the longer you need to maintain attitude to keep firing in a good direction - away from the rover. As the paper I cited earlier details - that's not trivial.

6 seconds is enough.

I think the full frame is actually the whole frame from Front Left - and the wheel subframe is from the Front Right.

It does not do this. See Mars Science Laboratory Flyaway Guidance, Navigation, and Control System Design. Behçet Açıkmeşe et.al.

The bridle umbilical device (BUD) has built-in retraction
springs to retract the now free bridles away from the rover top deck.
Once the flyaway controller on the DS assumes control, it first
holds the current altitude for 600 ms to allow sufficient time for the
umbilical to be cut. After the requisite hold time, the thrusters throttle
up and the DS ascends vertically for a predetermined amount of time.
Then, the DS begins to execute a turn to approximately 50 deg pitch.
The DS holds this attitude with the thrusters at 60% for 4 s. The hold,
ascent, and turn take place within 2 s, which corresponds to a total
flyaway time of 6 s


There is fuel and high pressure gas still onboard when this is finished. Flyaway consumes ~20-22kg of fuel. M2020 had ~90kg of fuel remaining so there were ~70kg of fuel left on the descent stage at burnout.

To burn to depletion would be to risk an explosive event at fuel exhaustion causing a debris field the rover would be well within.

https://static.uahirise.org/images/2012/det...028401_1755.jpg < The crime scene of the MSL descent stage impact. Note the explosive nature of the scar.

The descent stage doesn't have a proper flight computer. It doesn't have it's own communications. It doesn't have it's own power generation. It doesn't have its own instruments. It doesn't have landing gear. It doesn't have enough fuel to land anyway.

This is a big discussion we all had in this place 8+ years ago. The descent stage is not a missed opportunity for a lander.

That's not a map of the surface - that's a map of a plan through deep space. The spacecraft actively flies its way through entry to target the center of the ellipse. You can't translate that entry mapping image onto a surface map.

MRO will be doing bent-pipe realtime relay ( which is a new feature on MRO thanks to a software update )
MAVEN will be doing canister mode recording for later return to Earth.

See pages 23 and 43 of the Landing Press Kit
https://www.jpl.nasa.gov/news/press_kits/ma...g_press_kit.pdf

At the L-30 briefing they said yes - infact, they're going to try and do it a little later during EDL - so you'll have the powered descent vehicle flying below the parachute and backshell.

Fingers crossed.

You can thank the Presidents Day holiday for the extra sol of downlink to spend on a full frame upper tier 5x1

Yeah - I think Brave has a pretty wide swathe of WebGL issues. I'll fwd this onto the team but I doubt there's much they can do.