Juno: New Origins | Making complicated interplanetary probes

Over the last year or so, I've been slowly putting together a "Cylero Exploration Probe," loosely modelled on Nasa's Curiosity and Perseverance Mars rovers.

The rover was fairly straightforward, interesting challenges were: rocker-bogie suspension (I was very proud when I realised I'd come up with the same 'lever arm' differential mechanism as JPL!), full six independent wheel control to enable turning-on-the-spot as well as keeping traction in 'normal' turns, a "high-gain antenna" that always points towards Droo, and a stowed, articulated 'manipulator arm' with simple up-down-left-right controls.

For descent and landing I wanted to use a 'skycrane'. Having a liquid-fueled rocket on each corner and a load of RCS nozzles to control it didn't look as good as Nasa's, used too much fuel and was cooking my rover's wheels, so I changed to using no RCS and just 8 independently controlled monopropellant rockets... and spent a lot of time writing my own PID controllers to stabilise the craft and bring it to a halt about 50m above the surface. Phew - Getting that to work really gives insight into the "seven minutes of terror"!
The crane part was a real pain. I've added my upvote to the relevant suggestion, but in the meantime, my solution was to use a long chain of pistons, but to give them all the same initial coordinates. That let me avoid hinges, which would often combine explosively with pistons.
In fact, getting the thing to launch without self-destructing was a bit of a success. I think having a lot of loose hinges was a big part of the problem.

All the parts of the EDL sequence are working okay, and have all worked together worked once, but I'm still integrating everything which includes making tweaks and finessing. I've left the launch and 'cruise' stages manually controlled, because where's the fun in just watching an autopilot? ;-) Actually I have some code for launching to a target orbit, so I might integrate that, too. I think writing code to target a specific landing zone is more than I want to have a go at right now.

Anyway, once I have a finished rocket and have tidied up the code a bit, I won't mind sharing on here. I've also kept quite a lot of development versions, so I might put together a step-by-step guide to some of the harder bits if anyone's interested.

0 gt545

BTW, I originally came to J:NO from SimpleRockets on Android. I must have bought an early version of SR2 and then forgot about it, because when I looked again, it had moved on a little. ;-)
I've been doing this project on a touch screen Android tablet, and this is pretty close to the edge of what the device can cope with. I've become very used to it crashing while integrating the more complicated assemblies together.
Arguably, that's just life pushing at a boundary, but there may be bugs in the undo function that I can report if the devs would like. (Although I am still on an older version, so the report may not be so helpful.)
Anyway, another aspect of working on this device is it can take a full minute to e.g. switch between build and launch. That slow cycle time inevitably has some influence on the approach taken, such as not making changes in the original file recreating the sub-assembly and reimporting it downstream.

5 days ago

I also wanted to offer some thoughts, mainly to the developers, on the current model of re-use (of both 'hardware' and vizzy code) used by J:NO.
I haven't developed these into any specific suggestions, but I'm hoping something will come out of it.

So, there's a lot of separate stages to a probe like this. At the top level, there's launch, cruise, entry-descent-landing (EDL) and of course the rover itself. And some of those stages have sub-components, like the powered descent and skycrane, or the manipulator arm and suspension/steering system.

As with any big project, you can jump straight in and build it all as one, but that will be a pain for testing, so naturally you want to build separate parts, then bring them all together. That's fairly easy for the rover, as it stays on the ground, but it gets harder for things like the powered descent vehicle.

In fact, I ended up building several 'test jigs' for the various parts. For the skycrane, I built a long-legged support that held the descent module 20m off the ground so the rover could be lowered from it.
In each case, I'd ideally wanted the component to be saved in one file and the test jig in another. But I'd often want to make changes to the component under test (to both 'hardware' and vizzy code) while testing. It would be crazy to re-load the component file, change it, delete the old subassembly and create a new one, then reload the test jig and replace the old component with the new one. So I ended up with the test jig file containing a newer version of the component than the component's own file.
How do I feed the changes back to the component file, and how can I be confident that I haven't fed back unintended changes? (E.g. one option is to make the component's command pod the primary controller, delete the test jig and overwrite the component's original file with the result, but what if that has also changed the staging or activation groups?)

Later, I'd be testing two components together, like the powered descent / skycrane and rover. There's 11 interstage connections between them, so it's a pain putting them together and taking them apart, so again I'd inevitably end up with changes in that are difficult to 'backport'.

Then there's the vizzy code editor...
I won't criticise the 2D visual coding style. It's a game and while it can be frustrating it's not an unreasonable choice to accommodate a wide range of users. And even I'll admit that I've not had any syntax errors from my vizzy code! :-)
B

Making complicated interplanetary probes

Tags

2 Comments

No Upvotes