But, seriously, please don't. I have responsibilities. Also seriously, I've implemented some of the stock ESC desiredYawRate code, although some of the ESC characteristicSpeed settings are baked into my script because I got fed up trying to get the boilerplate code to work. I'll give that some time later. Also baked in is the extremely basic PID tune, which is purely proportional control at this point. I'll add this to a jbeam at some point so it can be tuned from the vehicle tuning screen. I think that would be a nice feature. And finally I've added understeer/oversteer logic, although I have to say after giving it some attention I think those are seriously misleading terms. My code doesn't look at the steering wheel direction when considering it, it just looks at the steering output from the PID loop and compares that to lateral Gforce and decides what to do from there. This means you don't have to consider countersteer among other things, and it also means sidehilling for a hypothetical future rock crawler will also be automatically adjusted for. It's still got an edge-case when you're deep into a reverse-entry drift, but I'm sure I can figure that out with a bit more noodling. Anyway, even without spending any real time on the PID tune, this has effectively tamed all versions except the 2500 with the stock body. So this is for when you absolutely positively have to snap turn 90 degrees at 450kph: I've attached the current WIP, I'm calling it version 0.1 at this point. I'll upload it to the repository when it's a touch more polished.
The hardest(and only hard) thing about those wheels is getting them stable with a low weight . They will need a ton of nodes to work decently. I'm kinda tempted to make it --- Post updated --- You have to disable the printing though, it lags really bad
I saw that other post, that's pretty dang cool. And I forgot about that. I was checking the understeer/oversteer logic. Oh well, here's 0.1.1. No more prints and it also has reverse now, which is fun. drifting around West Coast and winding up with my nose stuck to an obstacle got old fast.
Hey everybody! I just uploaded 0.3 to the repo as a beta and it's awaiting approval, but if you want it right now I've attached it. Also apparently if you strip away the aero and fit the 2500 hp motors then this thing can donut around the outside of the high-speed ring. Don't believe? See:
Mkay, got a few more things going, like for instance when you pull the handbrake while the car is in gear, it will go into skid steer mode at low speeds. At higher speeds there's just a yaw rate boost. I find it functions pretty similar to a handbrake but adds the ability to rotate on the spot. It's pretty neat. Also I'm trying to get a smooth response at all speeds without compromising control authority or power output. That happens at high speeds when too much control input bleeds away overall power and you can't reach top speed. At lower speeds it happens when too much control input can result in wheels spinning backwards and negating the throttle. But I have to normalise the throttle values so you don't wind up with maxed-out motors that do nothing until they suddenly do everything, which is bad for both control authority and smoothness. So I've been doing a lot of work to try and apply shaping to the normalisation, as well as shaping how much oversteer/understeer control applies, and so on. I've come up with something that sometimes works and sometimes doesn't, and I've got an idea for something better. I'm just kind of rubber-ducking here, which basically means I'm explaining my thought-process so I can understand it better. So when the throttle pedal is at zero, I'm applying a squared shape to the output signals, which gives a response like this: This is good for smooth onset of power, which reduces the oscillations at low throttle pedal values. And at full throttle-pedal values, I'm applying a square root to the output signals, like this: That's much better for top-end power output because it ensures that one wheel will tend to drop off in power before the others, and hopefully that will be the most influential wheel, so the overall power output is higher. However the shape at 0 and -1 for this is not terribly useful and will probably result in less predictable behaviour. Also because I'm adjusting between these curve shapes, that means that when the throttle pedal is at 0.5, the result is linear: This linear behaviour at half-throttle is hot garbage. So I think what I need is to change the way the curves are applied, so that at half-throttle we get this response: And then at full throttle we get this response: Now this will mean applying the shaping and normalisation and so on in a different way, but hopefully this will provide a more consistent response, as well as needing less ad-hoc hacky intervention which I've been doing up until this point. So there you go, a little peek at my process. If this works I should be uploading a new version soon.
The original eSBR torque maxed out when stopped, even with 1% throttle. Does it gets solved in the Saber?
Hm, I think I know what you mean, where the torque visualiser shows full torque at basically every throttle level. I think that's to do with how the visualiser works, I think it scales the torque values according to the recent maximum torque or something. I don't think it's actually maxing out the torque available to it.
An update has been posted! Most important here is the Debugging UI App, so now you can see the throttle values directly. I basically got sick of trying to divine what was going on using nothing but print statements. The UI app will get a lot more info in it but for now I'm stuck with just reporting values that exist in the electrics stream. @Diamondback, could you help me out with a better way to pass variables to the UI app? I don't want to overload electrics with variables that aren't used for anything else. Is there a way for the app to subscribe to a stream that comes directly from the script? Also obviously the throttle values that are reported are only positive, and I'd like to be able to report negative values too. Also I've implemented skid-steer. It's pretty simple, just pull the handbrake and it'll turn on the spot, or it'll get a boost to its desired yaw rate. Finally the throttle shaping was a bit of a non-starter in the end. I finally got all the bugs worked out only to discover that it still worked best with a linear adjustment. However in the process of trying to get it to work I refined how the two different types of vectoring were applied. I've got more control over them, and I've added a "maxThrottleDivergence" value, which basically means that the cross-axle vectoring can only deviate from the user's throttle inputs by up to 50%. That's basically cured the problem where the wheels would go into reverse at low speeds and the car would just rotate on the spot rather than go forwards. So it's an improvement. One of the things I was trying to accomplish was better straight-line stability, but I think I'll need to incorporate some traction control in order to get that to work, I don't think it's going to happen without taking that into account. Got a bunch of other stuff on my to-do list: - ESC Tuning Loading - ESC Mode Button Integration - Airborne Wheel Detection - Aerial Attitude Control Also some minor stuff, stock ESC is now not included by default on any vehicle, hillclimb variant wheel offsets are fixed and they now have race suspension and brakes installed, so they're proper hillclimb configs.
The problem is the ESC in BeamNG does not correct understeer at high speeds, if you put the ESC onto the Hillclimb and turn sharply at high speeds, the ESC will belive you're oversteering even if you're acturally understeering.
That's because it's a stability control system, so it's not just paying attention to understeer and oversteer, it's attempting to maintain a desired yaw rate. If you look in the code, you'll see that it has a yaw rate on the basis of steering angle, but also a yaw rate on the basis of g-force, and it takes the minimum of the two. So at high speed if you're turning the wheel hard, the ESC knows you can't turn that hard and maintain grip, so it creates understeer to limit sideways g-forces. It's overriding the user who's turned the wheel too far, according to how it's programmed. You can tune the ESC to allow higher g-forces if you want to, and it should allow you to slide out a lot more easily. So for instance the standard SBR ESC allows 10 ms^-2 and the sport mode allows 12 ms^-2. My system doesn't limit the g-forces, so it allows sliding. The reason I've turned off the stock ESC is because they're both doing similar jobs and they're fighting with each other so it makes no sense to have them both enabled. I've basically made a drift ESC. I will enable a more sedate version, but I'm not going to do that until I also have traction control working.
Good explanation. Therefore it's possible to manipluate the code of g-Forces to delibrately induce a controlled powerslide. --- Post updated --- Please do the following experimemt. Spawn a stock eSBR 800 Use the "engine info" UI app. Use a wall, another vehicle or simply nodegrabber to prevent the eSBR from moving Shift into D and apply 1% throttle. Read the engine torque maxed out.
In fact you don't need to even code, you can just change some numbers. If you go to <Beamng folder>\content\vehicles\sbr.zip\vehicles\sbr\sbr_esc.jbeam you can find all the numbers that are used to tune the ESCs for the different versions and mode. You'll find the line "maxSideAcceleration":10, and you can change that to whatever you want. You'll need to put it in a mod folder to overwrite the existing ESCs, but that's something you can play with if you want. --- Post updated --- Okay I did that, at 1% throttle I see the torque oscillating between ~200 and ~600 Nm, occasionally spiking higher. If I increase to between 2% and 4% it stabilises at ~800 Nm. Then as I increase the throttle and the wheels start to spin it drops to ~600 Nm. What that is showing is that the torque is not the same thing as power output. So at very low values it oscillates a bit, although it's hard to know how precise I'm being with the throttle. Then it increases as it reaches the limit of torque that the tyres can create. Then when the wheels break traction the torque drops off a little bit because sliding friction is less than static friction. So I think what you're seeing there is a result of the fact that the torque delivery cannot be more than what the tyres can resist. The only reason you don't see this with ICE vehicles is because they can't give torque at zero RPM. However getting that same torque at high motor RPMs equates to more power output, and that's really what you're requesting when you push the throttle pedal. EDIT: Another experiment to show you what I mean - if you remove all the wheels and try the same thing, you'll see that the torque only exists as the drivetrain components are spun up, and at full throttle with the motor spinning at full speed, you'll only get ~4Nm of torque. That shows that without any physical resistance, there is no motor torque. The torque you're seeing there is just the resistance created by a few of the drivetrain components.
Okay, latest update includes a proper rally config with its own suspension. This is something I've wanted for a while, and I was impressed with how easy it was. I just copied the tunable variables from the Sunburst rally suspension and tweaked the values a little bit, and it was handling offroad extremely well. The key addition is fast bump damping, which enables rally cars to handle big bumps without losing their composure. Also I've increased the travel, but past about +0.1m it seems to hit a physical limit in the struts somewhere. It can't quite manage the ground clearance that the Sunburst can. And after driving that version a lot - because I'm a rally fan and it is hands-down my favourite way to drive - I finally understood what was going wrong at low speeds. I've now scaled the cross-axle vectoring with throttle input. This cures so many problems that I feel like it's a fundamental part of how the system should work. The problems it cured include: - getting stuck in low-speed low-throttle turns where the car wants to just endlessly spin around - excessive lift-off oversteer at high speed - over-intervention in off-throttle slides causing the car to slide to the outside of the turn - wheels spinning up without limit during jumps, causing the car to rotate and popping tyres on landing - ABS getting confused and completely ruining the car's braking ability So yeah it's massively improved and generally handles much nicer when off-throttle now. There is still some intervention to allow the car to be controlled a bit during off-throttle slides, but it's only 10% of what it was and it gives the driver a lot more control I think.
so, the one thing that i noticed is that the car is really unstable until it gets up to speed. i was able to fix this (somewhat) by using a part (modded SBR4 retractable spoiler, to be exact) from a configuration pack (CJD). basically, that modded spoiler allowed me to put more downforce on the rear tires.
Oh man that spoiler adds a few kph at the top end by allowing the motors to work without the computer constantly needing to pull them back. Thanks! Also I've tweaked how the vectoring is applied and it should be more stable at all speeds now.
I found some inconsistencies between throttle value and the wheel torque, sometimes it's ok, however irregular torque is quite often Also it's very hard to maintain a 10mph speed even with 1% throttle
Okay thanks for the feedback. With the torque values, they are not necessarily intended to be directly related to the throttle values. The torque at the wheels can be affected by how much traction there is, how much the car is leaning on one wheel vs another, whether a wheel is spinning, flex in the driveshaft, momentum of the motor. Ultimately all these factors register as noise in the system, but the control loop in the software is designed to basically filter through all that noise and get a good result regardless of outside disturbances. With maintaining a low speed, I see the issue. Once I've got the system integrated with the ESC mode button I might make the standard driving mode work better with this, like at low speed & throttle combos it seeks a given speed or something. If I'm going to make a Hopper version I'll need to have something like this for a crawler mode anyway.
@Diamondback I'm trying to get the ESC configuration jbeam system integrated with my ESC script, and I've discovered a few things about it, but ultimately it won't load the ESC jbeam unless the saber esc file is named "esc.lua". If I name it for instance "saber_esc.lua", the configuration doesn't load. Looking in the esc jbeam, I'm changing this line whenever I rename the lua file: Code: "controller": [ ["fileName"], ["esc"], ["twoStepLaunch", {"rpmLimit":3500}] ], So I just rename ["esc"] to match whatever lua file I'm using. I'm at the point where only changing the name changes whether or not the config loads properly. What can I do about this? If I use the name "esc.lua" then it will break all the other SBR configurations, and I obviously don't want to do that. EDIT: Specifically, when loading the configuration from esc.lua I run a function to print out escConfigs and I get this: Code: 2875.84565|A|libbeamng.lua.V.print|actionedWheels 2875.84568|A|libbeamng.lua.V.print|1 2875.84570|A|libbeamng.lua.V.print|FL 2875.84571|A|libbeamng.lua.V.print|2 2875.84573|A|libbeamng.lua.V.print|FR 2875.84575|A|libbeamng.lua.V.print|3 2875.84577|A|libbeamng.lua.V.print|RR 2875.84578|A|libbeamng.lua.V.print|4 2875.84580|A|libbeamng.lua.V.print|RL 2875.84582|A|libbeamng.lua.V.print|slotType 2875.84584|A|libbeamng.lua.V.print|main 2875.84586|A|libbeamng.lua.V.print|skinName 2875.84587|A|libbeamng.lua.V.print|electro_c 2875.84589|A|libbeamng.lua.V.print|partName 2875.84591|A|libbeamng.lua.V.print|sbr 2875.84593|A|libbeamng.lua.V.print|cid 2875.84594|A|libbeamng.lua.V.print|4 2875.84596|A|libbeamng.lua.V.print|fileName 2875.84598|A|libbeamng.lua.V.print|esc 2875.84599|A|libbeamng.lua.V.print|defaultConfig 2875.84601|A|libbeamng.lua.V.print|1 2875.84603|A|libbeamng.lua.V.print|isDebugMode 2875.84605|A|libbeamng.lua.V.print|0 2875.84607|A|libbeamng.lua.V.print|configurations 2875.84608|A|libbeamng.lua.V.print|Sport ESC 2875.84611|A|libbeamng.lua.V.print|brakeForceMultiplier 2875.84613|A|libbeamng.lua.V.print|1 2875.84616|A|libbeamng.lua.V.print|skewStiffnessRear 2875.84618|A|libbeamng.lua.V.print|177000 2875.84620|A|libbeamng.lua.V.print|throttleProportionalFactor 2875.84622|A|libbeamng.lua.V.print|3 2875.84624|A|libbeamng.lua.V.print|integralFactor 2875.84626|A|libbeamng.lua.V.print|1.8 2875.84628|A|libbeamng.lua.V.print|proportionalFactor 2875.84630|A|libbeamng.lua.V.print|0.85 2875.84631|A|libbeamng.lua.V.print|escEnabled 2875.84633|A|libbeamng.lua.V.print|true 2875.84635|A|libbeamng.lua.V.print|order 2875.84637|A|libbeamng.lua.V.print|20 2875.84639|A|libbeamng.lua.V.print|brakeThrottleSwitchThreshold 2875.84640|A|libbeamng.lua.V.print|40 2875.84642|A|libbeamng.lua.V.print|brakingIntegralFactor 2875.84645|A|libbeamng.lua.V.print|0 2875.84647|A|libbeamng.lua.V.print|brakingProportionalFactor 2875.84649|A|libbeamng.lua.V.print|1 2875.84650|A|libbeamng.lua.V.print|escThreshold 2875.84652|A|libbeamng.lua.V.print|0.2 2875.84654|A|libbeamng.lua.V.print|minThrottleFactor 2875.84656|A|libbeamng.lua.V.print|0.2 2875.84657|A|libbeamng.lua.V.print|activeColor 2875.84659|A|libbeamng.lua.V.print|3096F1 2875.84661|A|libbeamng.lua.V.print|skewStiffnessFront 2875.84663|A|libbeamng.lua.V.print|142000 2875.84664|A|libbeamng.lua.V.print|escConfigurationEnabled 2875.84666|A|libbeamng.lua.V.print|true 2875.84668|A|libbeamng.lua.V.print|maxBrakingFactor 2875.84670|A|libbeamng.lua.V.print|0.8 2875.84672|A|libbeamng.lua.V.print|throttleIntegralFactor 2875.84674|A|libbeamng.lua.V.print|15 2875.84675|A|libbeamng.lua.V.print|maxSideAcceleration 2875.84677|A|libbeamng.lua.V.print|12 2875.84679|A|libbeamng.lua.V.print|desiredYawRateSmoothing 2875.84681|A|libbeamng.lua.V.print|550 2875.84682|A|libbeamng.lua.V.print|characteristicSpeed 2875.84684|A|libbeamng.lua.V.print|-1 2875.84686|A|libbeamng.lua.V.print|slipThreshold 2875.84688|A|libbeamng.lua.V.print|0.2 2875.84689|A|libbeamng.lua.V.print|maxIntegralPart 2875.84691|A|libbeamng.lua.V.print|3 2875.84693|A|libbeamng.lua.V.print|Regular ESC 2875.84694|A|libbeamng.lua.V.print|brakeForceMultiplier 2875.84696|A|libbeamng.lua.V.print|1 2875.84698|A|libbeamng.lua.V.print|skewStiffnessRear 2875.84700|A|libbeamng.lua.V.print|177000 2875.84702|A|libbeamng.lua.V.print|throttleProportionalFactor 2875.84703|A|libbeamng.lua.V.print|3 2875.84705|A|libbeamng.lua.V.print|integralFactor 2875.84707|A|libbeamng.lua.V.print|2.2 2875.84709|A|libbeamng.lua.V.print|proportionalFactor 2875.84711|A|libbeamng.lua.V.print|1.2 2875.84712|A|libbeamng.lua.V.print|escEnabled 2875.84714|A|libbeamng.lua.V.print|true 2875.84716|A|libbeamng.lua.V.print|order 2875.84718|A|libbeamng.lua.V.print|10 2875.84727|A|libbeamng.lua.V.print|brakeThrottleSwitchThreshold 2875.84733|A|libbeamng.lua.V.print|40 2875.84735|A|libbeamng.lua.V.print|brakingIntegralFactor 2875.84737|A|libbeamng.lua.V.print|0 2875.84738|A|libbeamng.lua.V.print|brakingProportionalFactor 2875.84740|A|libbeamng.lua.V.print|1 2875.84742|A|libbeamng.lua.V.print|escThreshold 2875.84744|A|libbeamng.lua.V.print|0.1 2875.84746|A|libbeamng.lua.V.print|minThrottleFactor 2875.84747|A|libbeamng.lua.V.print|0 2875.84749|A|libbeamng.lua.V.print|activeColor 2875.84751|A|libbeamng.lua.V.print|98FB00 2875.84756|A|libbeamng.lua.V.print|skewStiffnessFront 2875.84758|A|libbeamng.lua.V.print|142000 2875.84759|A|libbeamng.lua.V.print|escConfigurationEnabled 2875.84761|A|libbeamng.lua.V.print|true 2875.84763|A|libbeamng.lua.V.print|maxBrakingFactor 2875.84765|A|libbeamng.lua.V.print|1 2875.84766|A|libbeamng.lua.V.print|throttleIntegralFactor 2875.84768|A|libbeamng.lua.V.print|15 2875.84770|A|libbeamng.lua.V.print|maxSideAcceleration 2875.84772|A|libbeamng.lua.V.print|10 2875.84773|A|libbeamng.lua.V.print|desiredYawRateSmoothing 2875.84775|A|libbeamng.lua.V.print|550 2875.84777|A|libbeamng.lua.V.print|characteristicSpeed 2875.84779|A|libbeamng.lua.V.print|-1 2875.84780|A|libbeamng.lua.V.print|slipThreshold 2875.84782|A|libbeamng.lua.V.print|0.05 2875.84784|A|libbeamng.lua.V.print|maxIntegralPart 2875.84786|A|libbeamng.lua.V.print|5.5 2875.84787|A|libbeamng.lua.V.print|ESC Off 2875.84789|A|libbeamng.lua.V.print|order 2875.84791|A|libbeamng.lua.V.print|30 2875.84793|A|libbeamng.lua.V.print|overrideTCSPulse 2875.84795|A|libbeamng.lua.V.print|1 2875.84797|A|libbeamng.lua.V.print|escEnabled 2875.84799|A|libbeamng.lua.V.print|false 2875.84800|A|libbeamng.lua.V.print|escConfigurationEnabled 2875.84802|A|libbeamng.lua.V.print|true 2875.84804|A|libbeamng.lua.V.print|overrideESCPulse 2875.84809|A|libbeamng.lua.V.print|1 2875.84811|A|libbeamng.lua.V.print|name 2875.84812|A|libbeamng.lua.V.print|esc 2875.84814|A|libbeamng.lua.V.print|partOrigin 2875.84816|A|libbeamng.lua.V.print|saber_ESC_1000 You can tell from the final value that it is loading my custom esc configuration. When the file is named for instance saber_esc.lua, the output is this: Code: 4343.36164|A|libbeamng.lua.V.print|cid 4343.36168|A|libbeamng.lua.V.print|4 4343.36171|A|libbeamng.lua.V.print|fileName 4343.36174|A|libbeamng.lua.V.print|saber_esc 4343.36176|A|libbeamng.lua.V.print|partOrigin 4343.36178|A|libbeamng.lua.V.print|saber_ESC_1000 4343.36179|A|libbeamng.lua.V.print|slotType 4343.36181|A|libbeamng.lua.V.print|main 4343.36183|A|libbeamng.lua.V.print|skinName 4343.36185|A|libbeamng.lua.V.print|electro_c 4343.36186|A|libbeamng.lua.V.print|name 4343.36188|A|libbeamng.lua.V.print|saber_esc 4343.36190|A|libbeamng.lua.V.print|partName 4343.36191|A|libbeamng.lua.V.print|sbr So all of the actual configuration data is completely missing. Is this an insurmountable problem, or am I missing something? EDIT2: Okay, I've attached what I have currently, you can see some of the configuration data is being printed to the console. This is the working version, with esc.lua in the mod folder. That means that every SBR you load when this mod is installed will use the Saber esc logic, but they probably won't work. In game load up the Saber 1000 or the Saber 2500 Drag configs, they should be working because the correct ESC part is loaded. . I'd like to know if there's a way around this issue, because if it won't work with a different file name, that means the only way for it to work is to clone the SBR as an entirely new vehicle, rather than modding the SBR. That will break the interchangeability with other SBR parts, and I'd like to keep that working if possible.
Really love the idea of this mod. I would love to see one with less power tho. 400hp total or something around that. Something a bit easier to race and more manageable.
I'm sorry, really having t̶͡ro͜͞͞ubl͞ę͞ reading this reply. Like some of the words are fine but then I get this sc͡r̡e͞e͡c͞h҉i͘n̡g h̵̀͘ȩ̛a͏̵d͜ąć̴h͢e҉͠ H̢͘E̷͜͝ ̛̛́C̶͝͡͏O̸̡M̶E̛͜S̕͡ and I can't quite understand it. I'm sorry, I may have to lie down for a bit and s̶̛̛͝c͘͞ŕ̛͞a̢̛t̵̴̷̡ç̵̷̧h͢҉͞ ̀́̀͏̀o̢͏ù͜t̸̴̛͟ ̶͘͞t̛͞h̨̡͢͡͡i̧͘͟͡s̢̀ ̸̢̀́͢t̢͘r͠҉̡o҉̧̢͜͞ų́͜͢b̴̸̛͡l̵̨̕͡e̡̕s̴͞ǫ̸m̧͏e͜͠ ̡b͏̵̨̨̀ŕ̡́a̴͏̸̶í̶̶͠n̢̢͢͝.͡҉̷ Okay I just thought that was funny but I don't actually want to be a dick about this. I could halve the torque curves on the 1000hp version, which should work out to around 500hp I think, so it would be equivalent to the eSBR 500. Also the higher-power cars should be a lot more drivable once I have traction control implemented. EDIT: I should add though that I'm currently deep in the weeds trying to get the ESC configuration thing working. If I upload what I have currently it will break all stock SBR configs, so I obviously don't want to do that. In the meantime, here's a little teaser for the drag config I've figured out, which is obviously the opposite of what you're asking for: I've attached a config file, it will work as a manually installed mod, or you can extract the .pc file into your personal vehicles/sbr folder. I should point out that to achieve the posted times I detuned the controller to use the minimal intervention necessary to maintain a straight line whilst maximising power output. I also anticipated the green by shifting into drive maybe 0.3 or 0.4 seconds ahead, I'd say. It's hard to know the exact timing but it feels like I'm shifting about 1/4 of the way through the last amber light. Anyway, using the ESC tune that went out with the latest version won't get you this time, you'll get something above 6.5 if you're really lucky but more reliably around 6.7 and change. Tyres SHOULD be stock drag tyres, I try to disable all mods to test that mine works on its own before I release anything but I'm still a touch paranoid about it.
