I do have one, but it has no speed control I did you a drill to put screws in, but with these tiny wood screws I needed to be too careful or I stripped the head Its a careful balance thats solved by just doing it manually
Wooo! Meltybrains! Your non-circular melties inspired my latest robot design. It's basically a box with two wheels and mounts for heavy weapons on the far ends. I competed in the last NHRL event in Norwalk 2 days ago, but failed to qualify for the Prime Time events with "the arena floor", a 3-lb melty. The first fight tore the shaft and can out of the motor. Even though the meltybrain code and the unarmed robot will both work with one motor, about 600g of extra steel for my weapons meant I couldn't spin up. ;[ In my second fight a wiring screwup meant i could only "fake" melty with tank mode, coz one wheel was plugged in inverted. (my tank mode reduces throttle to 20% of melty mode so it's controllable.... which meant not only couldn't I translate, I couldn't spin up to a decent speed. )I lost that too... I've written my own meltybrain code called "melontype" (an anagram of "open melty"). There's links to it in a couple of of my recent videos. It works... a little, most of the time. It might be cool for a starting point if someone ones to write their own or understand how it works. I used ChatGPT to help write it, and have the transcript of that session linked as well to show how I did it. (A lot has been changed since the initial version, but it's all on github.)
The box on wheels style really simplifies the design in my mind, I do have a ring weapon for this design but didnt have the weight for it Congrats on getting a melty there, they are not easy to build or fight! Too bad about your second fight, its always annoying when a fight doesnt pan out for a hardware/software reasons I've been meaning to release my melty code but honestly its such a mess I dont think it would do anyone any good Great work releasing yours I'll have to take a look at it
1:09 - How do you design those parts such that they lock together like that?? Do you dovetail the tabs and/or the slots, or is it simply a friction fit? I'm often asked to design cheap and simple boxes out of sheet plastic for my product design job, but it's consistently difficult to assemble them in a way that holds them together without glue and excessive clamping. Also great video! Subscribed today :)
Its a simple friction fit, aided by the fact that its multiple pieces locking together, often with a number of tabs being constrained from all sides Boxes are difficult to get right consistently, I was recently shown this: en.makercase.com/#/ I havent used it to make an actual box yet, but I've generated a few and they look very similar to what I've been CADing by hand for a while now
I look forward to hearing how the gears work out. I have been thinking about switching Project LiftOff's heavy hub motor drive with a lighter gear driven wheel. My current plan is to use custom 3D printed nylon gears (very light and very strong), and have also thought about using a timing belt. I don't think any added play in the gears/belt will be an issue. I have done enough testing to know that the motors/wheels can break traction in the 10ms to 20ms pulse window when given too much power (even when the Bot is spinning at 2000 rpm)... And my testing with AM32 and blheli32 has shown that if the motor power isn't increased in a large enough delta, you won't see an ESC/motor response within 20ms. So many subtle interactions! My current thinking is: gearing down the motor's speed and using higher kv will enable the bot to spin faster while operating the motors at the optimal 50% power point. There are several other factors we can debate/discuss, but discord would be a better forum. As always, thank you for the great video, and thank you for sharing your knowledge! P.S. It does look like a platypus.
My first suspect would be backlash in the gears, or the flexibility of them absorbing the tiny adjustments needed for translation. A stiffer plastic would probably mitigate this, and may help avoid the chunking. That will be because of the large difference in stiffness between the two gears, ideally keep them the same material and/or both fairly stiff unless it's for weapon drive where you don't really care about precision
Nothing, if you want it to survive and do well N20s will push a beetle around but will die to any half decent hit Brushless weapon motors from an ant might be the right size for a brushless drive system, but you'd need to get different kv motors and attach them to gearboxes ESCs from ants will be under powered and burn out Batteries from ants will be under powered and likely go flat before the match is done It would be an interesting challenge idea, but any Beetle build with Ant parts would be a glass cannon and I'd doubt it would survive a full tournament
depends on where you live If you are in the states theres a few good places that make and sell components designed for combat, they are pricer then DIY but they are battle tested and pretty plug and play from what I've seen If you arnt in the states, direct parts from china is likely your best bet A lot of people start with 25mm diameter brushed motors and gear boxes for drive And 28-34mm brushless motors to run their weapons You'll want to belt drive your weapons in beetles to save your motors
Sorry for so many messages! In your translation testing, is 11:20 is when you're trying translation? How does your code do the speed adjustment? does it do a step function type "go high speed for this segment, go low speed for the other segment, and otherwise go medium speed?" or does it does do like a cosine modulation function where it smoothly changes over each revolution? (I found the smoother change worked over a slightly wider range of rotation speeds, but it also screws with the phase when you are translating, so it displays wrong. ) I think I can see it doing some pulsing in different directions, and it is wobbling around on the circle (kinda drawing a star shape) when the motors speed up. The problem could be when pulsing the motors is you are adding more forces to the bot which the accelerometer picks up, but even those aren't centrifugal forces... they're effectively tangential, but all it gets is the acceleration. (I use the same accelerometer chip.) Are you filtering the accelerometer inputs? After the attempted translating the lights seem more stable, but the offset phase has changed a little too. Do you have a potentiometer on your transmitter for tuning the aim offset and rotation speed? That can help compensate for having your batteries not exactly balanced, or if it moves (or something else falls off) after an impact. (It makes me so happy to see your robot doing the same things I was doing with mine during testing, like testing without the weapons.)
My code does speed adjustment by just speeding up each wheel inside a set arc I did have it speed up one and slow down the other but had issues so I dropped back to just the speed up code I'm hoping its a bug in my code and I just moved over a section of code from the teensy 3.2 code incorrectly I havent had a chance to look yet a cosine modulation function for the speed is an interesting idea! I'll look at implementing that in future I have a pot on my controller I use to trim the heading light already and I do use it, but it only helps for the static rotation heading
Normally I would have done this, but I could not find 4s lipos small enough I run 450mah batteries in my melties and I get them from one specific supplier who has smaller form factor packs their lowest mah 4s battery is 450mah and thats what I've run in all my melties up until this point. It is too big to fit into this bot, hence going with the 2s packs Its not ideal but its the best solution I could find The wire size from the batteries is fine and equivalent to packs with xt30s on them It was my female plugs that had dodgy wire and burnt out, but thats fixed with better silicone wire
@@TeamPanicRobotics Yeah, that does make sense. I only know 1 manufacturer who makes 120mah, 180mah and (IIRC 240mah?) 4S Lipos, but I forgot who. I also remember they were red JST, not XT-30
It seems that your robot knows its heading but cant command translation effectively. I think the best troubleshooting would be a high speed video. Some troubleshooting ideas: 1) Does it translate at low speed but not at max speed? Is your accelerometer close enough to the center of your robot to stay under it's maximum g limit? 2) Mark your smaller gear and brushless motor with a sharpie to see if the smaller gear is slipping on the shaft. 3) Is TPU hard enough to make into the larger gear? Could you be skipping teeth, or adding so much compliance in the gears that they absorb the commanded change in speed by deforming rather than actually slowing down? Try with a harder hub material. 4) Gearing your motor gives it more torque but it also amplifies the effective inertia of the wheel. It could be enough inertia to cause unintended behavior. Can you try again with very lightweight wheels?
Have you ever considered making a Melty Brain like Bladerunner from the OG battlebots. Basically thagomizer with no spinning weapon, but built in dual pick axe sort of weapon. It also had a ground scraping narrow wedge down the middle of the weapon end, not sure if a Melty could drive normally to use this function ever with the wheel speed. But basically, one tooth is best on a spinning weapon for more bite.
true, single tooth is more bite But its also more difficult to get balanced I did think about it when designing teeth, but was in a rush to get the order in so never completed a good counter balance Also I'm not sure how vital bite optimisation is for a melty Weapons store more energy the heavier they are, or the faster they spin For a conventional weapon, you are limited in weight by needing a robot and armour so you get the most energy by spinning as fast as possible. The downside to this is that the faster you spin, the less bite you have and hence bite becomes a big issue worth considering in the weapon design Conversely, melties have a large mass spinning so have a good amount of energy from the jump, but (typically) spin much slower then a conventional spinner. This also leads to the fact that they have more bite the a traditional spinner by virtue of spinning slower Which is a long winded way of saying two teeth is easier and I'm happy doing the easy thing until I can prove I'm going to get a significant benefit out of doing the hard thing
@@TeamPanicRobotics I'm also surprised that the melty chip being level is so important. It seems like there should be enough quality data still for software to figure out what it needs to one way or another to at least be good enough for the precision that a full body spinner desires.
Building question about the comment of tying the two 2S lipos together. Did you just solder them both to the powerboard separately or did you string them together somehow like building a 4wd brushed motor red to red then that like to the board? Thinking about doing this in my ant but don't want to start a fire. Any help would be appreciated.
I think the translation problem is the gears, wheels and motor changes you did I’m guessing there’s some lines in the code for configuration that ask for the size of the wheels and what motors you have so look for that and change that to what you’re using
The meltybrain uses an accelerometer, so it only needs to know the distance from the center of rotation of the robot to the sensor chip. From there it can convert the acceleration it experiences into a rotation speed. Those values are typically configurable by meltybrain software both in the code and using the transmitter. Unless you are using wheel encoders (he isn't), the wheel size doesn't matter. And for "what motors you have", all the meltybrain software I've read (or written) works with either 1 or 2 motors. (You can do it with more, but after 2 wheels there will always be more drag from at least one of the wheels being sideways across the motion -- with traditional wheel etc .ymmv)
This version of the code doesnt have any idea what the wheels are doing, its using accelerometer data only to try and set a heading Honestly I think I've just got a bug in my code somewhere
because I'm a software engineer and part of the reason I'm even trying this in the first place is to write my own code Also openmelt is old, it runs on old, slow hardware and uses old, slow communications protocols to talk to ESCs You can get much better performance out of a melty using teensy's and dshot or other high speed communications protocols
Pretty cool, but get an electric screw driver just for removing them :) Perhaps the fact that the wheel now turns the opisite way due to the new gearing from the motor is causing the issue? Can you not simply invert the data/code somehow for the accelerometer?
When it spins up it's initially spinning around one wheel rather than the centre of the robot. Makes me think one of motors wheels is lagging for some reason
It happened a night before our first 8kg fight also first fight a week ago wire fused together got scared that esc blew😢😢 also buy a electric screwdriver 😂😂
very fair, when I saw the melted wires I was super scared I'd shorted everything and killed my batteries I do have one, but it has no speed control I did you a drill to put screws in, but with these tiny wood screws I needed to be too careful or I stripped the head Its a careful balance thats solved by just doing it manually
So what happens when you 1v1 a melty opponent that lacks the ability to translate towards you effectively, but you’re not moron enough to just drive into it at full tilt? Melties should have to demonstrate some level of reliable translation during safety checks, which I’m confident the small number of successful melties would be able to demonstrate.
If the melty cant translate it gets counted out Spinning on the spot is not controlled movement outside of the bots radius, which is what most rulesets use to determine an inactive bot Had the wires not melted, I would not have run the bot in the tournament, because without an ability to translate I would have lost every fight
I think the gear reduction is a mistake, if you need more tourqe just use a bigger motor, you have your entire robot mass to dedicate to batteries and motors if you so choose.
I have used bigger motors, in all of my other melties I wanted this bot to be as flat as possible and have more "coverage" by the weapon teeth, i.e. less vertical space that an opponent could hit the frame as opposed to a weapon This meant going for smaller diameter motors, in brushless terms, most smaller diameter motors are also faster To keep the robot under the tip speed limit I needed to gear the motors to slow them down Do I think the gears as built in this version where a mistake? yes Where they the most logical choice for my current design goals? yes Do I think different gears would work better? yes Will I try gears again and not just run bigger motors? yes
I absolutely love your commitment to the melty! This looks to be your most polished version yet. I look forward to seeing your future iterations
I think this one needs to be called the Platypus
Perry the platypus
Two Headed Death Platypus
@@WorldofWoodrow perry the two headed death platypus
I was thinking that exact thing
haha I like Two Headed Death Platypus
It would need to be hot pink if I called it that
9:40 sounds like someone needs an electric screwdriver!
I do have one, but it has no speed control
I did you a drill to put screws in, but with these tiny wood screws I needed to be too careful or I stripped the head
Its a careful balance thats solved by just doing it manually
Wooo! Meltybrains! Your non-circular melties inspired my latest robot design. It's basically a box with two wheels and mounts for heavy weapons on the far ends.
I competed in the last NHRL event in Norwalk 2 days ago, but failed to qualify for the Prime Time events with "the arena floor", a 3-lb melty.
The first fight tore the shaft and can out of the motor. Even though the meltybrain code and the unarmed robot will both work with one motor, about 600g of extra steel for my weapons meant I couldn't spin up. ;[
In my second fight a wiring screwup meant i could only "fake" melty with tank mode, coz one wheel was plugged in inverted. (my tank mode reduces throttle to 20% of melty mode so it's controllable.... which meant not only couldn't I translate, I couldn't spin up to a decent speed. )I lost that too...
I've written my own meltybrain code called "melontype" (an anagram of "open melty"). There's links to it in a couple of of my recent videos. It works... a little, most of the time. It might be cool for a starting point if someone ones to write their own or understand how it works. I used ChatGPT to help write it, and have the transcript of that session linked as well to show how I did it. (A lot has been changed since the initial version, but it's all on github.)
The box on wheels style really simplifies the design in my mind, I do have a ring weapon for this design but didnt have the weight for it
Congrats on getting a melty there, they are not easy to build or fight!
Too bad about your second fight, its always annoying when a fight doesnt pan out for a hardware/software reasons
I've been meaning to release my melty code but honestly its such a mess I dont think it would do anyone any good
Great work releasing yours I'll have to take a look at it
1:09 - How do you design those parts such that they lock together like that?? Do you dovetail the tabs and/or the slots, or is it simply a friction fit?
I'm often asked to design cheap and simple boxes out of sheet plastic for my product design job, but it's consistently difficult to assemble them in a way that holds them together without glue and excessive clamping.
Also great video! Subscribed today :)
Its a simple friction fit, aided by the fact that its multiple pieces locking together, often with a number of tabs being constrained from all sides
Boxes are difficult to get right consistently, I was recently shown this: en.makercase.com/#/
I havent used it to make an actual box yet, but I've generated a few and they look very similar to what I've been CADing by hand for a while now
@@TeamPanicRobotics I have used makercase for simple laser cut boxes, it works great, much better than CADing it by hand
Thank you Ben for all the work you do!
I was just doing research for my next robot by watching your past experiments and you posted a new video.
I look forward to hearing how the gears work out. I have been thinking about switching Project LiftOff's heavy hub motor drive with a lighter gear driven wheel. My current plan is to use custom 3D printed nylon gears (very light and very strong), and have also thought about using a timing belt.
I don't think any added play in the gears/belt will be an issue. I have done enough testing to know that the motors/wheels can break traction in the 10ms to 20ms pulse window when given too much power (even when the Bot is spinning at 2000 rpm)... And my testing with AM32 and blheli32 has shown that if the motor power isn't increased in a large enough delta, you won't see an ESC/motor response within 20ms.
So many subtle interactions! My current thinking is: gearing down the motor's speed and using higher kv will enable the bot to spin faster while operating the motors at the optimal 50% power point. There are several other factors we can debate/discuss, but discord would be a better forum.
As always, thank you for the great video, and thank you for sharing your knowledge!
P.S. It does look like a platypus.
My first suspect would be backlash in the gears, or the flexibility of them absorbing the tiny adjustments needed for translation. A stiffer plastic would probably mitigate this, and may help avoid the chunking. That will be because of the large difference in stiffness between the two gears, ideally keep them the same material and/or both fairly stiff unless it's for weapon drive where you don't really care about precision
I think using the same material for both is definitely a good idea
Maybe I should try some cf nylon for the next set
A meltybrain with flames would be kinda cool!
Interesting idea using the 2 lipos. I have only built Ants, A video on what you could use from "standard" ant builds to make a beetle would be cool!
Nothing, if you want it to survive and do well
N20s will push a beetle around but will die to any half decent hit
Brushless weapon motors from an ant might be the right size for a brushless drive system, but you'd need to get different kv motors and attach them to gearboxes
ESCs from ants will be under powered and burn out
Batteries from ants will be under powered and likely go flat before the match is done
It would be an interesting challenge idea, but any Beetle build with Ant parts would be a glass cannon and I'd doubt it would survive a full tournament
@@TeamPanicRobotics recommendations for a beetle weight parts starter?
depends on where you live
If you are in the states theres a few good places that make and sell components designed for combat, they are pricer then DIY but they are battle tested and pretty plug and play from what I've seen
If you arnt in the states, direct parts from china is likely your best bet
A lot of people start with 25mm diameter brushed motors and gear boxes for drive
And 28-34mm brushless motors to run their weapons
You'll want to belt drive your weapons in beetles to save your motors
Sorry for so many messages! In your translation testing, is 11:20 is when you're trying translation? How does your code do the speed adjustment? does it do a step function type "go high speed for this segment, go low speed for the other segment, and otherwise go medium speed?" or does it does do like a cosine modulation function where it smoothly changes over each revolution? (I found the smoother change worked over a slightly wider range of rotation speeds, but it also screws with the phase when you are translating, so it displays wrong. )
I think I can see it doing some pulsing in different directions, and it is wobbling around on the circle (kinda drawing a star shape) when the motors speed up. The problem could be when pulsing the motors is you are adding more forces to the bot which the accelerometer picks up, but even those aren't centrifugal forces... they're effectively tangential, but all it gets is the acceleration. (I use the same accelerometer chip.) Are you filtering the accelerometer inputs?
After the attempted translating the lights seem more stable, but the offset phase has changed a little too. Do you have a potentiometer on your transmitter for tuning the aim offset and rotation speed? That can help compensate for having your batteries not exactly balanced, or if it moves (or something else falls off) after an impact.
(It makes me so happy to see your robot doing the same things I was doing with mine during testing, like testing without the weapons.)
My code does speed adjustment by just speeding up each wheel inside a set arc
I did have it speed up one and slow down the other but had issues so I dropped back to just the speed up code
I'm hoping its a bug in my code and I just moved over a section of code from the teensy 3.2 code incorrectly
I havent had a chance to look yet
a cosine modulation function for the speed is an interesting idea! I'll look at implementing that in future
I have a pot on my controller I use to trim the heading light already and I do use it, but it only helps for the static rotation heading
@@TeamPanicRobotics Good luck with finding the bug.
If you have a spare channel I definitely recommend adding a fine tune for the radius on a pot.
I feel your pain from "too many screws to get inside" syndrome.
I would recommend two 4s Lipos in Parallel instead of two 2s Lipos in series. That way if one battery dies or catches on fire, you have a spare.
and choosing batteries with an XT30 connector means the wires are going to be much thicker... thicker wire, less fire.
Normally I would have done this, but I could not find 4s lipos small enough
I run 450mah batteries in my melties and I get them from one specific supplier who has smaller form factor packs
their lowest mah 4s battery is 450mah and thats what I've run in all my melties up until this point.
It is too big to fit into this bot, hence going with the 2s packs
Its not ideal but its the best solution I could find
The wire size from the batteries is fine and equivalent to packs with xt30s on them
It was my female plugs that had dodgy wire and burnt out, but thats fixed with better silicone wire
@@TeamPanicRobotics
Yeah, that does make sense. I only know 1 manufacturer who makes 120mah, 180mah and (IIRC 240mah?) 4S Lipos, but I forgot who. I also remember they were red JST, not XT-30
Man, one day we'll both get working melty's to an event and have that melty off! (or actually manage to gang up as Triple Cheese Melt)
It seems that your robot knows its heading but cant command translation effectively. I think the best troubleshooting would be a high speed video. Some troubleshooting ideas:
1) Does it translate at low speed but not at max speed? Is your accelerometer close enough to the center of your robot to stay under it's maximum g limit?
2) Mark your smaller gear and brushless motor with a sharpie to see if the smaller gear is slipping on the shaft.
3) Is TPU hard enough to make into the larger gear? Could you be skipping teeth, or adding so much compliance in the gears that they absorb the commanded change in speed by deforming rather than actually slowing down? Try with a harder hub material.
4) Gearing your motor gives it more torque but it also amplifies the effective inertia of the wheel. It could be enough inertia to cause unintended behavior. Can you try again with very lightweight wheels?
Ex-screwciating
Have you ever considered making a Melty Brain like Bladerunner from the OG battlebots. Basically thagomizer with no spinning weapon, but built in dual pick axe sort of weapon. It also had a ground scraping narrow wedge down the middle of the weapon end, not sure if a Melty could drive normally to use this function ever with the wheel speed. But basically, one tooth is best on a spinning weapon for more bite.
true, single tooth is more bite
But its also more difficult to get balanced
I did think about it when designing teeth, but was in a rush to get the order in so never completed a good counter balance
Also I'm not sure how vital bite optimisation is for a melty
Weapons store more energy the heavier they are, or the faster they spin
For a conventional weapon, you are limited in weight by needing a robot and armour so you get the most energy by spinning as fast as possible. The downside to this is that the faster you spin, the less bite you have and hence bite becomes a big issue worth considering in the weapon design
Conversely, melties have a large mass spinning so have a good amount of energy from the jump, but (typically) spin much slower then a conventional spinner. This also leads to the fact that they have more bite the a traditional spinner by virtue of spinning slower
Which is a long winded way of saying two teeth is easier and I'm happy doing the easy thing until I can prove I'm going to get a significant benefit out of doing the hard thing
@@TeamPanicRobotics I'm also surprised that the melty chip being level is so important. It seems like there should be enough quality data still for software to figure out what it needs to one way or another to at least be good enough for the precision that a full body spinner desires.
Building question about the comment of tying the two 2S lipos together. Did you just solder them both to the powerboard separately or did you string them together somehow like building a 4wd brushed motor red to red then that like to the board? Thinking about doing this in my ant but don't want to start a fire. Any help would be appreciated.
I think the translation problem is the gears, wheels and motor changes you did I’m guessing there’s some lines in the code for configuration that ask for the size of the wheels and what motors you have so look for that and change that to what you’re using
Theres also gonna be backlash/compliance in the gears, which could throw the code off.
The meltybrain uses an accelerometer, so it only needs to know the distance from the center of rotation of the robot to the sensor chip. From there it can convert the acceleration it experiences into a rotation speed. Those values are typically configurable by meltybrain software both in the code and using the transmitter.
Unless you are using wheel encoders (he isn't), the wheel size doesn't matter. And for "what motors you have", all the meltybrain software I've read (or written) works with either 1 or 2 motors. (You can do it with more, but after 2 wheels there will always be more drag from at least one of the wheels being sideways across the motion -- with traditional wheel etc .ymmv)
This version of the code doesnt have any idea what the wheels are doing, its using accelerometer data only to try and set a heading
Honestly I think I've just got a bug in my code somewhere
Now that the robot is more like a conventional melty brain, are you able to run openmelt, and what is the reason you don’t?
because I'm a software engineer and part of the reason I'm even trying this in the first place is to write my own code
Also openmelt is old, it runs on old, slow hardware and uses old, slow communications protocols to talk to ESCs
You can get much better performance out of a melty using teensy's and dshot or other high speed communications protocols
Pretty cool, but get an electric screw driver just for removing them :) Perhaps the fact that the wheel now turns the opisite way due to the new gearing from the motor is causing the issue? Can you not simply invert the data/code somehow for the accelerometer?
Can it run upside down or does it it get hung on the bolts that hold on the teeth?
9:44 ex-screw-tiating... lol
When it spins up it's initially spinning around one wheel rather than the centre of the robot. Makes me think one of motors wheels is lagging for some reason
you are correct, one of the wheels was hitching a bit, I think because I over tightened the bolt, it certainly wasnt as free
@@TeamPanicRobotics would that explain poor translation?
It happened a night before our first 8kg fight also first fight a week ago wire fused together got scared that esc blew😢😢 also buy a electric screwdriver 😂😂
very fair, when I saw the melted wires I was super scared I'd shorted everything and killed my batteries
I do have one, but it has no speed control
I did you a drill to put screws in, but with these tiny wood screws I needed to be too careful or I stripped the head
Its a careful balance thats solved by just doing it manually
So what happens when you 1v1 a melty opponent that lacks the ability to translate towards you effectively, but you’re not moron enough to just drive into it at full tilt? Melties should have to demonstrate some level of reliable translation during safety checks, which I’m confident the small number of successful melties would be able to demonstrate.
If the melty cant translate it gets counted out
Spinning on the spot is not controlled movement outside of the bots radius, which is what most rulesets use to determine an inactive bot
Had the wires not melted, I would not have run the bot in the tournament, because without an ability to translate I would have lost every fight
Naked melty.
try machined plastic gears
Unscrewing ASMR vid?
I think the gear reduction is a mistake, if you need more tourqe just use a bigger motor, you have your entire robot mass to dedicate to batteries and motors if you so choose.
I have used bigger motors, in all of my other melties
I wanted this bot to be as flat as possible and have more "coverage" by the weapon teeth, i.e. less vertical space that an opponent could hit the frame as opposed to a weapon
This meant going for smaller diameter motors, in brushless terms, most smaller diameter motors are also faster
To keep the robot under the tip speed limit I needed to gear the motors to slow them down
Do I think the gears as built in this version where a mistake? yes
Where they the most logical choice for my current design goals? yes
Do I think different gears would work better? yes
Will I try gears again and not just run bigger motors? yes
Removing the motor from direct shock of wheels being hit is a good by-product