This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Messages - cjbruce
Pages: 1 ... 7 8 9 10 11 12 13 [14] 15 16 17 18 19 20 21 ... 49
261
« on: January 30, 2020, 12:47:45 PM »
Panic Attack turns fairly quickly with the keyboard if you don't try to drive forward or backward at the same time as you turn.
Okay... Now I'm confused.
I have the exact opposite problem. I can only get it to turn at a decent rate by getting up some speed and drifting it.
What is your setting for Wheel Mass Ratio? I've been using 10%.
262
« on: January 30, 2020, 08:12:30 AM »
Likewise, does anyone have any real-life experience with 4-wheeled robots? It would be nice to get some turning and driving feel feedback.
All of our robots use 2 wheel drive.
263
« on: January 30, 2020, 08:10:45 AM »
I believe that the solution for Panic Attack is to shorten and widen the wheelbase as much as possible, though I haven't tried.
The issue I have with that is twofold. Partly that there isn't really room to do that without clipping until multiple wheels can be belted to one motor, partly that the real thing - albeit with six wheels - had a wheelbase just as long as this one and handled fine.
Maybe we can play around with friction coefficient to see if we can better match reality?
I sense another slider in our future! :)
Another thing to consider is that the real life Panic Attack wasn't driven by someone using a keyboard. It was driven with a very expensive controller with high precision analog sticks (i.e. not the relatively inexpensive ones that come in an Xbox or PS4 controller). This enabled the driver to carefully control the signal to the wheels. Panic Attack turns fairly quickly with the keyboard if you don't try to drive forward or backward at the same time as you turn. I am hoping to get a Spektrum WS2000 USB receiver to pair with our Spektrum DX6 radio transmitters. This will allow me to test the RR2 driving dynamics with the actual controllers we use in real life. I am curious to put Panic Attack through a series of tests to see how the simulated robot performs compares to the real robot. Does anyone know if Panic Attack's creator is on GTM? :)
264
« on: January 30, 2020, 06:06:20 AM »
I believe that the solution for Panic Attack is to shorten and widen the wheelbase as much as possible, though I haven't tried.
The issue I have with that is twofold. Partly that there isn't really room to do that without clipping until multiple wheels can be belted to one motor, partly that the real thing - albeit with six wheels - had a wheelbase just as long as this one and handled fine.
Maybe we can play around with friction coefficient to see if we can better match reality? I sense another slider in our future! :)
265
« on: January 30, 2020, 06:05:24 AM »
I think, I found an issue with the new build. Some asymmetrical spinners, that were balanced before are now unbalanced
The COM calculation has changed several times over the past few months. Method #1 - The first iteration weighted ALL colliders based on their volume. Even ones that shouldn't have been included (i.e. invisible colliders that were used as attachment points for the Botlab). Method #2 - The next few iterations removed the invisible colliders, but assumed all colliders had the same material density. This means that selecting "steel" or "aluminum" for a collider farther out didn't shift the COM. Method #3 - One of the most recent iterations attempted to determine the COM based on the location and mass of each component (i.e. the entire shape) rather than using the individual colliders. This is the desired method, but due to a bug in the calculation it did not correctly account for non-uniform scaling of the component. In the case of Panic Attack, Method #3 placed the srimech's COM about 1.5 meters out in front of the robot. This caused the srimech to respond too slowly. Also, if broken off, the srimech would hang vertically from a point in the air. For the current 29January Alpha Build, I have reverted to Method #2 above. It isn't what I want, but at least it doesn't sometimes place COMs 1 meter outside of the robot. I would really like to get Method #3 working correctly. In the meanwhile, just be mentally prepared to tweak the balance of asymmetrical spinners over the next few builds.
266
« on: January 29, 2020, 04:43:42 PM »
We’ve got one in the art pipeline. I haven’t decided how to handle the performance characteristics. Maybe it is only usable with a belt drive? Maybe it has very little low speed torque? Has anyone built a real robot with brushless motors? A heavyweight?
267
« on: January 29, 2020, 01:38:45 PM »
I haven't said anything about it until now since it slipped my mind, but I've been having an interesting situation with Panic Attack these last few builds.
...every version still has that issue from jan 17 of having too much traction to steer properly.
This effect happens in real life too. 4-wheel tank steering can be problematic. With 2 wheels, the wheels only have to roll forward or backward when turning. Whenever you have four wheels with some wheels in front of others the wheels have to skid sideways. The longer the wheelbase compared to the width, the more pronounced this affect. The better the traction, the more pronounced the effect. I believe that the solution for Panic Attack is to shorten and widen the wheelbase as much as possible, though I haven't tried. I'm planning to set the Wheel Mass Ratio at 10-15% for future builds. Panic Attack drives best when I set it at 1%, but this makes other robots completely undriveable as the wheels skitter all over the place and aren't capable of pushing the chassis. Also: Is it possible to turn off the pink COM spears of doom on detached parts?
Done! Check out the Alpha build I just posted.
268
« on: January 29, 2020, 12:23:05 PM »
The 29January2020 Alpha build is up! https://robot-rumble.itch.io/buildsThis one fixes the crashing bug introduced in the Bleeding Edge Build. It also adds a 12V AmpFlow A28-150 motor. This is a less-powerful lower voltage motor we use for our lightweight class robots. The COMTrackers are no longer visible in this build.
269
« on: January 28, 2020, 07:10:31 PM »
Idk if the fix will fix this, but small parts tend to clip into opponent. Lets say a small spinner tooth hits an opponents, the tooth will most likely get stuck and it will be that way until it breaks off
Nope. That is something that happens with compound colliders and discrete physics like we are using. I tried switching to continuous physics a few times, but it made wheels bounce all over the place so I switched back. The blur cylinder completely eliminates the problem if we set it to turn on at a low enough speed. Maybe I can play with this a bit. It will only work for spinner weapons though.
270
« on: January 28, 2020, 04:11:34 PM »
Ok so this sawbot crashes the game when it hits something at high speed and force.
Crash fix coming soon. It was a stupid mistake that was easy to spot and fix.
271
« on: January 28, 2020, 02:54:58 PM »
WhamettNuht found a crashing bug. I forgot to account for the case where the rigidbody has zero mass (all of the components are broken off). This caused a divide by zero condition which would crash the game to the main menu. The fix will set the affected rigidbody's COM to the origin point of the object.
Bug fix coming soon.
272
« on: January 28, 2020, 02:50:11 PM »
Okay, so my bot RIPtear mk2 looked like this:
Is this good or bad?
EDIT: The image attachment system broke for me  .
It looks like there is a COM sphere that is slightly to the right of a bar. That's weird. It looks like you have a COM that might be outside of the bounds of the robot. Can you send me the .RR2Bot file?
273
« on: January 28, 2020, 01:42:05 PM »
Imma just post these pics here as I saw this on Twitter:
More to come on this soon! 
274
« on: January 28, 2020, 01:41:21 PM »
Ok so a quick test, and i can tell that driving didnt really improve. 420-500 tick is still way to go without jitter
One thing i did notice is that there is no more weird oscillation where the bot feels like its too light and has next to no gravity, which is a good thing
For most heavyweight robots there shouldn't be too much difference. The bad COM calculation only caused the following problems that I am aware of: 1. All robots with wheels attached directly to motors (rather than through a gearbox) had COMs that were farther out along the axis. This was pretty much unnoticeable for heavyweights, but crippling for beetleweights. 1.5 kg Beetleweights couldn't steer at all, and often had wheels floating above the ground. 30 kg robots were still drivable, but they suffered from severe steering problems. 2. When parts broke off, there was no change to COM of the remaining robot. 3. When parts broke off, they would sometimes have a weird COM that caused them to suspend awkwardly in the air. Under the new build, please check to see that the COM of your rigidbodies are always inside the robot. You shouldn't see much, if any, magenta on your robot. If you see a big magenta line then I did something wrong and need to take a look. Please send me the .RR2Bot file.
275
« on: January 28, 2020, 09:55:28 AM »
Sorry about that!
RR2-Windows-28January2020-BleedingEdgeTestBuild.zip is up now.
276
« on: January 28, 2020, 09:32:09 AM »
The new 28January2020 Bleeding Edge Test Build is out: http://www.robot-rumble.com/bleedingedgebuilds/This build is designed to help solve the problems we are having with driving and other physics weirdness like robots spontaneously deciding to lean over on their side for no apparent reason. The root cause has been an improperly computed location of the center of mass, particularly for wheels that are attached directly to motors. This problem has made beetleweights completely impossible. Beetleweights appear to be driving correctly now. For this bleeding edge build I have included COMTrackers that visualize the location of the center of mass of each rigidbody. Any time you add a motor and attach something to it, you are adding an additional rigidbody. Please give it a try and let me know if you are still seeing issues. [Added] Added COMTracker.cs to track the location of all the centers of mass of every rigidbody on a robot. [Added] Added COM_Controller.cs. This script should correctly compute the COM of a rigidbody based on the center of mass of each of its Component_Info components. This can be done repeatedly at runtime. I still need to do extensive testing to make sure the script works in all cases. If it does, then it should be possible to apply the script to things that have lost parts due to damage, as well as broken pieces lying around the arena. [Added] Added COM_Controller to rigidbodies spawns when a component breaks off. [Added] COM_Controller.recomputeCOM() is now called on the original rigidbody when a component breaks off. [Added] Added more hotkeys (now hotkeys can be shift/ctrl + key): -close pause menu, hotkey screen and help screen with the same keys for opening those screens. -Toggle workbench with B key. -Toggle music with N key. -Cycle through music tracks with ctrl + N. -Confirm on popups is enter, cancel in popups is backspace or escape. -You can move through the botlab sections using the right and left Arrow. [Removed] Removed the makeup mass code from SpinnerMassReducer. By using the COMTracker spheres, I noticed that the center of mass was not in the right location, and could completely throw off the balance of a robot. [Changed] Set the axle mass of various motors to 0.000001 kg: AmpFlow A40-300 37 mm Geared 37 mm Ungeared 22 mm Geared
277
« on: January 28, 2020, 06:19:22 AM »
I think I finally found and have a fix for the center of mass issues!
I'm planning to upload a bleeding edge build today. This one will include a COMTracker that will show the local of the center of mass of all rigid bodies.
You guys are going to love the COMTrackers. They are an obnoxious magenta. :)
Team Lightning, I concur with the direct attachments issue. With this new build, the COM should be recomputed correctly immediately after the robot spawns, and whenever parts fall off. You should be able to see if the COM is in the wrong spot right away.
278
« on: January 27, 2020, 01:55:59 PM »
HP for custom parts is currently based on the mass of the component. I’m not sure if this helps.
279
« on: January 26, 2020, 05:09:55 PM »
Working on it. I’m trying a million little things to solve the problem at its source without luck.
In the end I might have to go back and manually fix the center of mass of wheels after the entire assembly is created. I know this will work for wheels but would not fix any similar problems that might arise for weapons.
280
« on: January 24, 2020, 07:36:01 PM »
I believe so. We won’t know until we have a fix in place.
Pages: 1 ... 7 8 9 10 11 12 13 [14] 15 16 17 18 19 20 21 ... 49
|
Show Posts