Jump to content
Stray Fawn Community

Steering and Stability


corona_wind

Recommended Posts

This is the biggest barrier to succeeding in the racetrack.  I've tried so many approaches, none of which work...

  • Screw it, Don't Bother - Lots of little contraptions win races by bouncing or spinning with little regard to fine steering.  You can get good speeds with a very small drone.  But with 50% dead weight they can only go so fast.
  • Direction Indicator Steering.  Engines hooked directly to the direction indicator.  Like above, your engines spend 50% of the time not working, and if you hit the dead spot, your ship just ... stops.
  • Inverted Direction Indicator Steering.  Instead of turning one engine on to steer, you turn one engine off.  This sounds better and isn't.  You spend all your time bouncing with one engine disabled anyway.  Feel free to move your engines inward for less torque until you slam into walls.  Alternately, you can increase the dead zone until you slam into walls.
  • Drift Steering.  Same as above with careful angling and placement of engines relative to center of mass to supply lateral acceleration.  This helps avoid the walls, but promotes understeering, and can oscillate like anything else.
  • Steering Compensation - Killing that oscillation by any means, including but not limited to:
    • Springs - Lets you isolate oscillations to certain parts.  Doesn't stop oscillations, but hey, at least you're pointed the right way more frequently.
    • Pulse engines to stop your turn.  This takes so much dead weight.  I've seen racers that are 50% sideways pulse engine.
    • Variable Speed Engines - I'll never run out of ideas for them, none of which ever work since they're SO LAGGY!  Even just on/off has horrible lag.
    • Byzantine Logic Arrangements - Delays, et cetera to reverse steering pre-emptively and halt overshoot.  Still exploring this but even logic is slow at ramjet speeds.
    • Rube Goldbergian Mechanical Arrangements - My specialty.  I've made feedback loops of direction indicators and powered joints to manage over/understeer.  Faster than digital logic.  Maybe one day I'll find an arrangement that works in narrow turns.  Not today.
  • Brute Force - Make your ship so big oversteer is less of a problem and/or losing parts to impacts matters less.

I've been able to think my way around most problems but this has me close to beat..

  • Like 3
Link to comment
Share on other sites

Great overview of ideas! I think the width&curves are a bit too narrow for the speed we allow with the afterburner, so you can't really use the full potential speed without a lot of trickery.

Maybe we need to tweak the tracks a bit (make them wider) or have parts which react faster or have parts which lets you somehow better control drag/angular drag. Do you have any ideas / suggestions for parts which make racing more interesting / give you more control?

Link to comment
Share on other sites

I think the drag model is really wrong right now, pianos steer like feathers and vice versa, but that's another thread.  Waking up to my wrong assumptions has helped, and just talking this over has given me more ideas.  I think I can make an angular accelerometer, just one more use of  the gimbal.

  • Like 1
Link to comment
Share on other sites

So far the most capable racer design I've found is that of Wing Wraith by Gorggeron (cycle through the hard designs versus racing and it'll turn up eventually). It combines the best of max speed (all thrusters point forward and fire on straightaways) with the ability to turn sharply (all thrusters can potentially participate in turning).

If you're not familiar with it, here's a wraith-based design I spent a bit of time working on for Cygnus.

421772487_WraithRacerControl.jpg.0665ca3d4eeef6d41861092fb2a96951.jpg

Each 'eye' controls the opposing wing. While the waypoint is more or less centered, both wings activate. If the waypoint moves off to the side of the midline of the drone, the eye controlling the corresponding wing shuts off causing the entire craft to rapidly torque back toward the waypoint. If the balance of torque, angular momentum and the eye deadzone angle is right, the inactive wing reignites fast enough to prevent oversteer and the fishtailing that entails.

669599747_WraithRacerOp.gif.8efef994602cb0b6fe903cc732ff79fb.gif

----

I also made a functionally similar, but conceptually simpler control scheme with the eyes creating a parallel center channel, where the width and angling of the channel can be easily manipulated by merely moving the eyes themselves. Here's a design I made for Picses, that tries to stay to the right, inside track for that course.

1732326761_ParallaxRacerControl.jpg.d2d7a4cd75057aa5e61f57f514d77498.jpg

---

Having worked with wraith designs, I'm still frankly a bit perplexed as to how some players have managed to navigate hydrus in so little time. Even wraith-types have real trouble with turning that fast at afterburner speeds.

The only thing I can figure is that they're possibly using some combination of fuel dragging for better turn handling (shown below) and selectively decoupling spent fuel cans, but I've yet to actually come up with a successful amalgam of all these elements and I'm not sure if a viable hybrid is possible.

987602204_draggerOp.gif.c6548df7d5d57184778ecd815f5bce47.gif

  • Like 2
Link to comment
Share on other sites

If Markus and company are really looking for a way to make tracks more afterburner friendly, rather than completely overhauling the tracks, I would just have the waypoint shift farther ahead at high speed. Right now, afterburner drones have only a small fraction of a second notice before they enter a turn, the only way to really deal with that is insane angular speeds.

 

If the waypoint position was customizable or at least linear speed dependent, we'd have a lot easier time making drones that can adequately anticipate an upcoming turn and behave appropriately.

  • Like 1
Link to comment
Share on other sites

Can now confirm. Fuel dragging a wraith gives +10 steering and an unforeseen +25 motion sickness induction.

1908264748_WraithDraggingOp.gif.6684bcacf06dfc3a24e31d4906e7766c.gif.

-----

A similar design using only one direction sensor for a more conventional control scheme had similar, but slightly worse performance. So wraithing even at the small scale has its perks.

  • Like 1
Link to comment
Share on other sites

20 hours ago, Markus said:

Great overview of ideas! I think the width&curves are a bit too narrow for the speed we allow with the afterburner, so you can't really use the full potential speed without a lot of trickery.

Maybe we need to tweak the tracks a bit (make them wider) or have parts which react faster or have parts which lets you somehow better control drag/angular drag. Do you have any ideas / suggestions for parts which make racing more interesting / give you more control?

When I say digital logic is too slow, I'm not kidding.  One gate delay is the difference  between steering and hitting walls.  The same craft, without the gate delay but with equivalent dead weight, steers well.  Perhaps several ticks of logic could happen per game tick, so a detector could fire and an engine could activate in the same tick?

Link to comment
Share on other sites

I'm not entirely sure what the point is you're trying to make about there being no brake. I never said or intended to imply there was any special breaking going on. Many if not all wraith designs, especially without careful refinement -will- oscillate to varying degrees. Indeed there's some minor oscillating visible in the last few frames of the first wraith GIF above.

The main advantage of wraithing over one-sensor designs is that it has 3 active states (A , B and AB) instead of the 2 (A and B). That third state enables the drone to maintain it's current orientation at 100% thrust, something a one sensor design can't match (at least not without multiple* logic gates). A badly balanced and calibrated wraith will wildly swing from A, thru AB to B and back. Going to 100% thrust for only a small fraction of the travel time. However, the one-sensor design, no matter how well balanced, has to go straight from A to B and back, never hitting 100% thrust at all. As I tried to explain originally, in the right circumstances, due to the right mix of forces (yes, including drag) and sensor settings, the wraith drone will not swing thru the AB portion, but come to rest there and stay at a full 100% thrust until the waypoint moves relative to the drone. The wraith's advantage isn't that it never oscillates, it's that the third state allows it to achieve a higher thrust and maintain a preferred orientation even if somewhat crudely.

My last comment about the wraith narrowly beating the one-sensor was just the result of me doing my own little analysis of whether the additional mass and drag of a second sensor is compensated by the slightly higher thrust and control, which I felt was still an open question. At least in that case, the trade-off is worth it for about 2 or 3% additional speed overall. That isn't to say wraithing is always a good (or the best) idea.

-------

*I just thought of how one might do an A-B-AB scheme with a sensor and a single logic gate. I haven't tested it, yet, but I'll revisit the subject if I get it to work sometime.

Link to comment
Share on other sites

Would you mind going into a little bit about you understand to be the fundamental issue of 'steering and stability' and the distinction between the two.

Your opening post doesn't actually address what you see as an optimal or ideal case of steering and/or stability, so it feels like we're having a conversation about something I can't see.

Link to comment
Share on other sites

Very interesting discussion here :)

Quote

If Markus and company are really looking for a way to make tracks more afterburner friendly, rather than completely overhauling the tracks, I would just have the waypoint shift farther ahead at high speed. Right now, afterburner drones have only a small fraction of a second notice before they enter a turn, the only way to really deal with that is insane angular speeds.

I think this could be a useful setting for the VTOL / Directional sensor. UI wise I think this might be a problem currently, because we're running out of space. But generally I think it's possible to set the distance for the waypoint technically.

Quote

When I say digital logic is too slow, I'm not kidding.  One gate delay is the difference  between steering and hitting walls.  The same craft, without the gate delay but with equivalent dead weight, steers well.  Perhaps several ticks of logic could happen per game tick, so a detector could fire and an engine could activate in the same tick?

This is a bigger problem currently. We already have some problems with logic gates which don't react 100% deterministic (if I recall correct) depending on the frame rate, even though we have something which is frame-rate independent (the unity physics step function). I'm not sure if we're able to squeeze in more ticks there. I agree with your problem, but I'm not sure if we can solve it this way.

 

Maybe tweaking the track still is the right decision. The tracks were designed before the implementation of the afterburner, so ideally we would simply adjust the tracks properly, instead of making workarounds. But the idea about the custom waypoint distance is a nice way to micro-optimize your design I think.

Link to comment
Share on other sites

11 hours ago, corona_wind said:

Stability:  Stopping once you're there.

I was thinking perhaps what we're missing here are reaction wheel parts to soak up excess angular momentum. I'm still trying to figure out how exactly that might work, so that it's powerful enough to be useful, but not so much that it makes rotational thrusters obsolete.

 

-------

12 hours ago, Hex7 said:

*I just thought of how one might do an A-B-AB scheme with a sensor and a single logic gate. I haven't tested it, yet, but I'll revisit the subject if I get it to work sometime.

I got it to work. It's fairly simple to do an A-B-AB scheme using a single direction sensor and a NOR gate, so it's A-B-norAB. The thrusters just respond to either A or B (depending on their side) and a norAB tag.

Although having done it, maybe that was obvious all along and I'm just being daft.

Link to comment
Share on other sites

1 hour ago, Hex7 said:

Although having done it, maybe that was obvious all along and I'm just being daft.

If that can console you, know that learning how to sew and knit with some experienced person gives the same kind of feeling: what one thinks is an achievement, has existed as a basic technique for centuries. It does make one feel humble, which is at least something.

I suppose this is how learning goes anyway. Congratulations on having figured it out ~

  • Like 1
Link to comment
Share on other sites

5 hours ago, Hex7 said:

I was thinking perhaps what we're missing here are reaction wheel parts to soak up excess angular momentum. I'm still trying to figure out how exactly that might work, so that it's powerful enough to be useful, but not so much that it makes rotational thrusters obsolete.

Consuming lots of power would be a good tradeoff.  But if we had the logic to drive a reaction wheel, why not just hook it up to rockets?

Throw away the flywheel and you're left with...  well...  another wheel, a gimbal.  In this case the direction indicator indicates gravity and controls its own pivot to constantly point down.  This means it only twitches when you're turning.  It works, but isn't exactly elegant (WIP).  If the position indicator had gimbal settings, I could throw away the wonky joint and make something much faster and more stable.

13 hours ago, Markus said:

This is a bigger problem currently. We already have some problems with logic gates which don't react 100% deterministic (if I recall correct) depending on the frame rate, even though we have something which is frame-rate independent (the unity physics step function). I'm not sure if we're able to squeeze in more ticks there. I agree with your problem, but I'm not sure if we can solve it this way.

Are my drones supposed to win/lose the same sumo match pixel-perfect identically every time?  They're nondeterministic but never "wrong" exactly.  Sometimes it'll lose one part, sometimes another, but never anything I wouldn't have expected to happen, nothing absurd.  I thought that was quite clever and wondered how you did it!

If that's unintended, I'll wild-guess that something in damage processing or garbage collection is monkeying with the order of your data trees.  We know the order of equal depth things is arbitrary - we tweak fuel flow by altering that order just by touching things.  Memory management especially is quite nondeterministic and liable to move things this way and that depending on what memory is handy.

If that's all that's happening, does it need to be fixed?  I kind of like it.  I haven't seen any logic errors I couldn't put down to propagation delay and part ordering.

  • Like 1
Link to comment
Share on other sites

And I have progress of a sort!

TyPBHhl.png

The forward eye controls the outer pair of engines in standard fashion.  The back eye controls the inner pair of engines in swapped fashion, with a little delay between them, so for an instant you get full-force turning, which rapidly becomes slow turning with only one inner and one outer engine active.

xGqtTXh.gif

Wraithlike steering without the drag.  I might be able to simplify it more.

  • Like 2
Link to comment
Share on other sites

As of this post, the majority of the dominant racing drones are using almost no propulsion other than forward facing afterburners after a jump start in the starting area. If drones are successfully navigating courses with nothing but afterburners, I don't think courses need to be easier, I think they need to be harder to encourage more build diversity. 

At some point, I'll post all the crazy stuff I've made that touches on this topic.

  • Like 1
Link to comment
Share on other sites

Big drones are easier to control!  They just stop, balloonlike, whenever you stop pushing them, in defiance of logic and physics.  Small drones, meanwhile, careen around like speeding pianos.

It's totally backwards and bonkers!  Am I really the only one who sees this!?  😅  Come on...  Take my community challenge if you doubt this.

Link to comment
Share on other sites

22 hours ago, Garheardt the Black said:

Balloons stop the way they do because of air resistance. Drones are also resisted by air. They don't have to defy logic or physics 😅

Planes in real life are rather big, and they do not "stop, balloonlike, whenever you stop pushing them" -- thankfully so. A ball made of foam, while small, will lose its momentum quickly. In Nimbatus, planes stall and balls speed down tracks.

It might be that air resistance applies to all components of a craft however they are arranged, or that inertia is low, I do not know the details; but large ships do feel sluggish, stopping in their tracks the moment their means of propulsion shut down. That is both counter-intuitive because it seems to work another way on earth, and annoying because smaller almost always means faster, and in that situation I fail to see any much interest in larger designs.

Link to comment
Share on other sites

All I can add to the discussion is that the Unity physics engine is not really correct and uses tons of tricks to run smoothly with that many objects. It does have a drag / angular drag value, but I have no idea how that is applied when there are a lot of interlocking joints. So it's very likely that drones don't behave like in real physics. Unfortunately that's not something we can fix :/ But we still try to balance it in a way that it's enjoyable to interact with :) 

Link to comment
Share on other sites

On 4/15/2019 at 1:57 AM, Garheardt the Black said:

Balloons stop the way they do because of air resistance.

Not in Nimbatus, they don't.  They fly around like cannonballs.  Only large, heavy things fly like balloons, a bug people exploit and abuse on the racetrack.

11 hours ago, Markus said:

So it's very likely that drones don't behave like in real physics. Unfortunately that's not something we can fix :/ But we still try to balance it in a way that it's enjoyable to interact with :) 

I realize it would have to be a kludge, but I still hope something can be done.  The situation right now is a mess -- not "kind of off" but completely wrong.  Could you adjust drag according to drone size just before launch?  Not by rewriting Unity, just by fudging numbers inside the parts themselves.

Link to comment
Share on other sites

20 hours ago, Ookami-sama said:

That is both counter-intuitive because it seems to work another way on earth, and annoying because smaller almost always means faster, and in that situation I fail to see any much interest in larger designs.

Small racetrack drones have some advantage in speed per weight, but suffer a minor disadvantage in slamming into walls and exploding.

It takes 2.5 to 3 extra tons of sensors and gates for me to make a "small" drone that can steer at all, and it's still nowhere near as stable as six hollow bricks.

The Wraith is nothing but engines and tanks, and needs nothing more due to drag.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...