Are you planning to model the full rotor control system? It has full variable-pitch control of both rotors, which makes it quite unusual and much more complex than the typical R/C coaxial (which is fixed pitch on both rotors) and needs six servos total.

On the plus side, the motors and linkages are simpler than the typical collective-pitch hobby setup: https://www.helifreak.com/showthread.php?t=...483#post8120133

The team is not as sure as you are. Murphy's Law dictates that if something was going to happen, it would happen at the worst time.

Short and probably too simple answer: there's lots of N2 on Venus, just not much fractionally. CO2 was removed from the early Earth's atmosphere by formation of solid carbonates (CO2+H2O+mineral reactions). This didn't happen on Venus, perhaps due to lack of water. Titan is so cold that CO2 freezes out so it can't be in the atmosphere. Why Mars has a lot of CO2 and few carbonates (since water was present on early Mars from most evidence) is still something of a mystery.

Some may recall that a substantial part of the reason for the launch slip of MSL was the failure to get dry lubricants to work. https://www.thespacereview.com/article/1319/1 And as far as I know, they aren't used on M2020 either.

It should also be observed that while waste heat from the RTG -- which doesn't tail off very quickly -- is used to keep the internals of MSL warm, the actuators and external instruments use electrical heaters, and that can be a substantial use of energy, especially in the winter.

How Dragonfly compares as far as thermal design I don't know. But at -180C typical temperatures, Titan makes Mars look downright balmy.

The RTG charges batteries, which then power flight. Reduced electrical output from the RTG means it will take longer for the batteries to charge, which only affects flight cadence, not the ability to fly, up to the point that the batteries simply can't be charged up enough to keep the vehicle alive at all.

Minor nit: RTG useful lifetime for electrical generation is set by thermocouple degradation, not by Pu decay.

In the decades since I last worked on Magellan, full-res map products ("FMAPs") at 75 m/pix have been produced. See https://pds-imaging.jpl.nasa.gov/volumes/ma...an.html#mgnFMAP

Per the documentation,

Having spent more than a small amount of time working with the full-res F-BIDR products and even the raws back when the mission was still running, anyone who would say global coverage from Magellan is only 300m is not trying hard enough, IMHO.

Doing a more modern job of reprocessing the Magellan data would probably have payoffs for those brave enough to try it.

Thanks for diving so deeply into the ISIS problems, Jason. Anything that improves ISIS behavior for Junocam benefits not only these flybys, but Junocam processing in general.

Note that we could have the typical level of error in the first frame's start time value for each of these images, though I expect at the moment those are swamped by the error in the SPK.

Let's say that Magellan global radar has a resolution of 75 m/pix (a little bit of oversimplification but not wildly unfair). VISAR https://www.hou.usra.edu/meetings/lpsc2020/pdf/1449.pdf claims 30 m/pixel resolution globally and 15 m/pix in small targeted regions. So that's a fair approximation of what Viking gave us for Mars. It took another 10x increase in resolution provided by MOC to yield the results John is talking about.

Viking orbital imagery was very evolutionary, not revolutionary, from Mariner 9. And at least as far as orbital radar is concerned, these missions will likely be evolutionary from Magellan if the Mars experience is applicable (which I admit it may not be.)

Thanks, I'm pretty proud of that. Unfortunately I was never able to complete a color version. For one thing, the WA blue geodesy campaign coverage was noisy and incomplete. It ended up being taken at half the resolution of the red images and was even harder to remove photometric signature from.

The merged MOLA/MOC image that went into https://tharsis.gsfc.nasa.gov/ngs.html was colorized from a color global map mosaic assembled by hand by Mike Malin.

I know there's been some more recent work on the MOC WA dataset by a few people, for example https://ui.adsabs.harvard.edu/abs/2020JGRE....06231R/abstract but I'm not aware of anything like a native-resolution WA color mosaic. It would be a big task, trust me.

Exactly what "resolution" means can be debated (pointlessly, IMHO) and can be different from "pixel scale". And sometimes you can see things that are below the resolution limit if they are sufficiently contrasty.

Agreed, although the orbit period has now been reduced to 43 days.

I ran a search with the reference trajectory a while back, and the best one I found then was an 8-pixel view of Amalthea in July 2025 which may or may not be usable within other constraints.

Ganymede images now on missionjuno.

I've tried to be very patient (the mods can attest to the fact that I haven't complained about any post on this thread), but people are just not getting what I am saying, apparently.

We are working through some issues with our processing and I hope the images will be showing up on missionjuno shortly. In the meantime enjoy the quicklook product that NASA released.

Per post #16 in this thread: "All that adds up to the data showing up on missionjuno no earlier than 8 June and hopefully no later than the day after".

I'm not sure I'd call that distortion, when you fly close to something that's roundish you're pretty much stuck with a view like that.

I think you should simply wait for the data and then see what you and others can do with it.

There's nothing different about the Ganymede images and they have to be processed the same way as any other Junocam image.

The simulation was just a rough stitch of the simulated frames with the overlap removed and doesn't closely resemble either the real raw data or our map projections.

As discussed above, the earliest you can expect the data on missionjuno is sometime on Tuesday 8 June. I honestly don't know if playback will be happening between the Ganymede encounter and the perijove pass (I hope so), but checking https://eyes.nasa.gov/dsn/dsn.html to see if there is high-rate downlink from Juno will be a clue.

No idea, it depends mostly on the delta V required to trim the orbit. I didn't have the impression that it took that much delta V but I could be mistaken.

AFAIK the dose per orbit is not much different between the 53-day orbit and the 14-day orbit, you just accumulate it faster with the shorter orbit. There's no way to know how the nominal mission with the PRM would have gone.

As with many high-value Jupiter images, the plan is to take the Ganymede images with lossless compression.

We always compress at as high a quality factor as we can given the goals and constraints of each PJ pass.

My simulations of the first two Ganymede images, subject to spin phase and timing/nav errors.

We will be releasing the PJ34 data per our usual process. Recall that we can't release standard products until we get the reconstructed C kernel, and we don't release partial images until every effort has been made to retransmit them. For the Ganymede imaging, we'll be trying to generate the map-projected standard products but it's not clear how well that will work (may be sensitive to SPK errors or our software might just choke); if it doesn't work then we will just release the raw products.

All that adds up to the data showing up on missionjuno no earlier than 8 June and hopefully no later than the day after, barring unanticipated events. And note that I haven't looked at the specifics of the DSN schedule so I'm not sure when the raw data is expected on the ground.

In theory we could post the raw data without waiting for the C kernel, but that would be outside our normal flow and might preclude ever posting the map-projected images if they do work, so I wouldn't count on it for now.

Assuming the IFOV is correct, the RTE camera is mounted in landscape mode and has an FOV of about 63x46 degrees (62.7x46.5).

On the contrary, we know a lot about the global magnetic field from MGS and Maven. See https://agupubs.onlinelibrary.wiley.com/doi...29/2018JE005854 for example.

I've already said as much as I can for reasons I cite upthread. It's certainly neither of the first two.

It can be directly commanded or it can be computed onboard based on spacecraft attitude knowledge (this is described in the Junocam paper so I feel OK saying that.) It would be an interesting exercise to compare the actual attitude in the reconstructed C kernels to that in the predicted C kernels, as that would give you a sense of how well this is known in advance.

If there is, no one has told me about it. https://en.wikipedia.org/wiki/Loaded_question

I will say that many people have done a lot of work over the past few months planning this sequence. It would have been less stressful to start with a more distant encounter, but we'll see how it goes.