PDA

View Full Version : Starting a quad build - A couple questions



sdfgeoff
06-11-2018, 02:15 PM
For a couple years now I've been wanting to build an entry for MechWarfare, so far as coming up with various designs, building a prototype chassis, implementing some simulations (of various realism), and few other bits and bobs. Now I finally feel I have the skills to start on an actual build.

Mechanical Build
In the regulations, it mentions that the legs should not obstruct the target plates in any way. However, the mechanical design of my robot means there may be issues complying with this. The mechanics is designed such that there is no static load on the servo's motors, which should help reduce power consumption and thermal issues. In rest post everything is OK:
https://s33.postimg.cc/50you82u3/normal-composite.jpg (https://postimg.cc/image/50you82u3/)

But when the legs have moved, the side target plates may become obscured:
https://s33.postimg.cc/6g09j9gvf/move-composit.jpg (https://postimg.cc/image/6g09j9gvf/)
(hopefully first-post doesn't preclude images)

There isn't really any way around this with this leg setup unless I move the target plates onto the turret, and the mech isn't intentionally designed to block the plates. Heck, due to stability requirements the legs may not move very far from the rest pose! However, I thought I would ask before committing to this mechanical design.
A video of a similar design walking is available here: https://www.youtube.com/watch?v=EmRlHRKC2Gg
Is there any reason why this leg layout isn't more common?


I'm planning this mech as a medium mech with full-size plates, but if it comes in with a low-enough weight, it may end up being a light mech and be able to use half-size. My goodness those normal-size plates are huge compared to those legs.


Communications
What systems are you using to communicate to your mechs? I seem to recall seeing somewhere around that some of you are using Xbee systems. What other systems are people using or is everyone using the same? I can understand the warning against wifi as I've also experienced reliability issues in crowds.... (for one of my uni projects we were forced to use it on our [more-car-like] bots)

Where I'm currently living, 5.8Ghz systems are limited to 25mw power. I see the regs limit it to 250mw. What output are people actually running on their bots?

Weaponry
I haven't managed to find a good source of just AEG gearboxes, and those I have found tend to be high-power units close to 300fps. Admittedly, getting to the point of arming this bot is likely many months away, but where are people getting their guns? I threw together a couple designs for a diy-variant, but I know I won't be able to achieve the necessary reliability or power.

Location
I'm in Eurpope. Robogames is in US. Have any of you traveled with your mechs through airport security? Is there anyone else in Europe building these things?
Honestly, there's probably little chance of me actually competing, but it should be a fun build anyway.

Electrical
I threw together some approximate power calculations and concluded that I need about 3Ah at 7.4v for my bot to get a 20min runtime (the servos draw up to 1.2A, I'm assuming about half of that continuous, and then some change for other on-board gear). But... how does this power estimation line up with what you guys measure?

Other electrical things of interest:
- Servo's are planned to be dynamixel XL-320's - the only smart-servo's I can get locally(!)
- On-board processor will likely be an ESP32. I think I can compress everything down to run on an embedded system.
- On-board camera will possibly a gopro hero2 that I've used for FPV cars before. This both outputs analog video and can record it (so hopefully there will be some highish-quality on-board footage)


Software (no questions, but open for comments)
As mentioned previously, it's running a microcontroller on the bot. After the bot is assembled and walking, I'm looking at doing dynamic leg placement at low-speeds to increase bot stability while aiming. I whipped together some algorithms for this and have achieved some success in (minimal) simulations.

I plan to use the ESP's on-board wifi to sent back (unreliable) telemetry, and possibly expose some low-level control there as well so I can do the base development on a normal PC and just use it as the hardware-interface.


Reliability
My biggest concern on every robot I build is always reliability. Any advice on this other than thread-lock all bolts?

jwatte
06-13-2018, 09:55 PM
I would build the bot such that the panels could be mounted higher than the legs. Mounting them on the turret might work, too (I had previous bots that did that.) For the front, you may be able to use a split panel, with camera/gun in the center and two half panels apart. I know the previous scoring panel designs included these, but I don't know if there are still split panels for the current crop.

For control, I used Xbee 900 MHz, and the worked well. They're only 20 kbps, and Xbees don't like turning around the channel in the air, so plan on just sending data to the mech over this channel, not receiving anything back. (You can use WiFi for receiving telemetry back, using UDP, so that loss doesn't matter/block things. Just don't use WiFi for camera or control!)
A PC can easily talk to an Xbee using a Xbee USB adapter. I typically write some simple C# WinForms app to talk to the Xbee for part of development, although for "deployment" I ended up writing a controller program in C++ for a Raspberry Pi with an embedded 5" display for telematics, and a USB Xbox controller for input. A Windows laptop would have worked just as fine, though :-)

There are plastic AEGs that are pretty weak that I've been using; "Double Eagle" spare parts. Something like this: https://www.airsoftstation.com/replacement-gearbox-for-double-eagle-m82-aeg/
However, a metal AEG will work too, if you shorten the barrel, or make the barrel oversize, or de-tune it in some other way so that the exit velocity isn't too high.

25 mW is probably good enough for a 5 GHz video system, especially if you use a diversity receiver. You could also plan on receiving something from Amazon while you're in the states if you want to push it up while here, but I don't think it's necessary. The power allowance is higher if you hold a US amateur radio operator license than if you're un-licensed; typically there will be some operators at Robogames that might qualify you to use the higher power -- check with particular volunteers for details.

I have traveled with a 'mech. You should remove the LiPos and put them in a protective case that you pack in your carry-on, whereas the mech itself goes in checked luggage. I highly recommend getting a padded Pelican case, and perhaps dismounting the turret from the body, for transfer; stuff it full of padding! The Pelican cases are somewhat pricey, so make sure you include that in your budget. The 20x20x20 inch cube is small enough to check without paying oversize fees; larger ones may not be. And, whatever you do, don't take the airsoft BBs in your hand luggage; the US inspectors will confiscate them considering they are "ammunition." (If you read the rules for the definition of "ammunition," they don't actually qualify, because they don't have propellant, but TSA agents don't give a shit about that.)

Even with full IK on the legs, embedded CPUs can run a gait engine just fine. I don't know how to hook the ESP32 up to the TTL bus of the XL-320 servos, but it sounds like you have already solved that bit.

The GoPro may be heavy to put on a turret. I've used much smaller cameras. However, most cameras have glass or acrylic lenses that crack if they're hit by BBs, so you need to get some thin polycarbonate to put in front of the camera.

Oh, and thread-lock all bolts :-)

GhengisDhon
06-18-2018, 11:34 PM
7239

As usual, jwatte was pretty thorough. Few things I would add:

Most of the mechs shield the target plates with their legs to some extent as they it and we can let you know if its an issue. Your pics above look acceptable.

XBee Pros also work good (as do the Xbee 900Mhz) for the comms. You can always test out with the overseas lower power versions and we can get you some loaners if you do make it over to Robogames in the states. We have club members with HAM radio licenses for the higher power ones in the states.

AEG gear boxes, we usually get from Amazon or Ebay. Don't know where to get them in Europe. But if you do find some, we have some breach/hopper design we to get you started int the right direction. (A reliable accurate gun is no trivial matter..)

Shipping.. we've had people put them through airport security locally in the states but don't know about international travel. However, this year, one of the teams had half their luggage lost by the airlines so they only got 1 of 3 mechs operational for Robogames. We have had international competitors in the past and there's a lot of international competitors in other events, so it must be able to be done. One year, I know one of the European teams shipped it to a local friend they had in the US. You could probably ship it to one of the R-Team members and we could haul it out there for you.

XL-320 are pretty low on power. We have several people in our club attempting to build light weight mechs with them. You have to be very conscious of weight. We have yet to find a reliable, light weight weapon/gun for them but are still working on it... We use very small micro cameras as well.

Batteries: I use 1Ahr 11.1V LiPos. Lasts about 15 min for my mech. If your using Xl-320s you can't afford the weight of a big battery. We've been using 400mAhr 7.4V LiPos for our Light weight mechs.

Reliability: Clean connectorized harnesses. Draw schematics of your wiring. May seem obvious as you putting it together but you will forget at a later date. Plan ahead an make it so you can replace components easily and don't have to tear apart the whole mech if something goes down. Make a pre-match checklist... you would be surprised on how many people forget to reload their gun. Extensive testing of your mech before Robogames. Don't wait till robogames to test for the first time. Put as many hours on it as you can to find the weak links.

sdfgeoff
06-19-2018, 11:23 AM
Thank you both for the input.


I was looking more into the Xbee's, and it looks like international regulation differences will be a bit of a pain. Here in Europe we can't use the 900Mhz variant, and in the states you can't use the 868Mhz version. So I think it will be best to use the Xbee Pro on 2.4Ghz, and if needs be we can do some last-minute-orders-when-there so we can swap it out at the actual event. Telemetry will be via the ESP's internal wifi. The video RX we have on order has diversity. I plan to run both an omni and a directional antenna on it (though I have not yet ordered them). So with luck™ it should work.


That is a good suggestion to ship the bot rather than fly with it. I think it would be significantly easier and avoid most issues with travelling with a combat robot.


I'm hoping XL-320's will be powerful enough because the mechanical design places no static loads on them. If needs be, I'll upgradw to bigger servos. To me the appeal of the XL-320's is the local availability (the low cost is also appealing). I'll be building a leg when some parts arrive in about a week, which should allow a decision on them to be made.
I tested and the gopro can run on external power without it's battery present, which about halves it's weight. It's still far heavier than one of the ultra-light micro-cameras, coming in at about 60g.


Hmm, those batteries are a lot smaller than I was expecting. I'm surprised you're getting sufficient runtime out of them! Of course, my power calculations are currently estimates and I tended towards the pessimistic. I'm also aiming towards 20 minutes, but if your bots can run for 15mins off 10Wh of power, then it sounds like my estimate of needing 30Wh is far too high.






----------------------------------------
Designing for maintenance is a good bit of advice, and something I already plan to do. A checklist is a fantastict idea, and something I hadn't thought of. I also think a policy of "don't work on it past 9:00pm" is probably a good idea, but unlikely to be achieved.....


Even now, schematics and diagrams are being constructed:
https://s8.postimg.cc/sfzcgvidd/communication.png (https://postimg.cc/image/sfzcgvidd/)
https://s8.postimg.cc/51rd56ddd/power.png (https://postimg.cc/image/51rd56ddd/)

But I am fairly sure that in the end, they will no longer be maintained and I'll end up figuring out what is on the bot by measuring with a multimeter....

jwatte
06-19-2018, 01:30 PM
A reliable accurate gun is no trivial matter

This is the truth! I feel that my design gets a C+ -- it gets the job done -- but the R-team feeder spring design has less dry firing (because of the compression tension on the BBs) and lower center of gravity, and gets approximately an A :-)

sdfgeoff
06-23-2018, 02:17 PM
And we have a simulated robot walking - albeit with self-collisions and over-extensions of the limbs. No proper turning yet, only linear movement (the turning happens because there seems to be some difference between front and rear limbs when strafing. I need to hunt down what's causing that).

https://www.youtube.com/watch?v=6Ys9SE3WhL8

I wonder how closely it will match the physical hardware? Even though the values for torque and maximum speed I've fed into the simulated motors match their real values, I think there's something missing. I think the inertia of the gear-train of the servo is significant, so I'll have to throw some acceleration slew limits onto the simulated joints.

Control and telemetry are being sent to/from the simulated robot. Both currently happen over UDP/wifi at the moment (I was driving it from my laptop while the simulation was on my desktop).

jwatte
06-23-2018, 07:42 PM
I think the hardest parts to simulate are the flex and backlash in the legs and gears, and the slip/friction of the ground contact.
Also, with proper IK, you should be able to stand still even when the legs go up and down. Although that's probably harder when your leg contact is based on a vertical rotation rather than an actual "lifting" of the legs.

GhengisDhon
06-25-2018, 08:26 PM
Out of Curiosity, what did you use to do the simulation?

sdfgeoff
06-26-2018, 01:27 AM
@jwatte:
The side-to-side sway I added because otherwise the robot would topple on to the leg that was most recently lifted. I think this is a problem that is worse with this robot's leg mechanics as compared to most other mechanics.

Reducing friction is easy enough to do in the simulation (at least at a simple level), but as you say, flex and backlash are pretty hard. Maybe I can introduce a deadzone into the simulated motors

@GhengisDhon:
It's blender game engine (https://www.blender.org/), and it uses bullet for physics (https://github.com/bulletphysics/bullet3). It has the advantage of running python as it's scripting language, has a fantastic model workflow (integrated with the top open source modeling tool), and I've spent the past couple years doing game development with it.
The running python is a particular advantage because the ESP32 supports micropython (https://micropython.org/), and I've written a hardware abstraction layer that will allow me to run the same gait/control system on both the simulated robot and the actual hardware.


------------------------------------------------
I don't think I mentioned before, but there are three of us working on this robot. I'll be focusing on the control systems and system integration, and the other are split with one doing the mechanics and the other on electronics/embedded software. The simulation will allow the control systems to be developed before the hardware is developed, and without risking damage to the mech.

Some parts arrived yesterday, so we started work on talking between the ESP and the dynamixels. Something seems to be wrong with the CRC's we're sending them (sending known good packets works, but our own generated packets don't), but the level shifting is turning out to be more of a pain than we hoped. It turns out the XL-320's do respond to a 3V signal, but transmit back at 5V. The shared TX/RX line means that the trivial solution of a resistive divider isn't quite suitable. There's another simple passives-only circuit that we could do, but we'll probably use a level shifter to increase the noise immunity.

sdfgeoff
07-04-2018, 08:44 AM
Things are progressing nicely. We've 3D printed some mounts for the servos, and should hopefully have a leg fairly soon. We can also talk to to the servos from the ESP32, although working in micropython for the communications has a lot of overhead, and would restrict the mainloop speed significantly. So we're probably going to write the dynamixel protocol handling as a C module. We did some strength tests and it seems like the XL-320's don't perform at their rated spec. At 7.4V, with a 1.5kg load on a 2cm arm (theoretically requiring a maximum of 3kgcm torque) the servos shut-down. Theoretically the servos are rated at 3.9kgcm. Of course, it is likely due to dynamic load and trying to accelerate that mass to fast. Fortunately they successfully move (at full speed) 700g on the same 2cm arm (~1.5kgcm), and some back-of-envelope approximation says this should be adequate. In a few days we'll have a prototype of a complete leg, and then we can make the final decision on if the servos will do the job.
I can see why people at the R-team club are having issues building mechs with these servos. They are weaker than I was expecting, and if you are trying to run them "safe" with static loads <1/5 stall torque, then you're in for a challenge getting a mech light enough. Fortunately our mechanical design has no static load, so we hopefully won't hit thermal issues.

There are also some interesting challenges to do with level shifting. At 1Mbps, the level shifter we are using struggles to drive the three servos we have with a good waveshape. By the time 14 of them are connected, the servos will almost certainly have issues. So the plan is to use a quad-level shifter, and have each leg use a different channel. (all channels are connected on the low-voltage side so it will still use a single UART from the microcontroller).

I was looking into power systems recently, and I hope to power the robot using 18650 li-ion cells as opposed to more typical lipo packs. In theory this allows cells to be obtained anywhere (cellphone power banks), but they may have some issues with sourcing the current. Even specialized cells struggle to provide more than 5-6 amps without their temperature getting pretty high. So that's another question that will need to be answered soon: how much current do the legs actually draw? On one hand I'd rather not have fans on the mech for simplicity, but on the other hand, it may look cool.....

The video gear (RX/TX) "arrived" a few days ago. By which I mean the RX arrived, but the TX box was emtpy. The RX is a eachine rotG02, which is special because it connects over USB and appears as a standard webcam. The RX seems to work, and successfully displays static on my laptop screen. I developed a telemetry/camera-feed app, and using a normal webcam I measured the cam->screen latency at about 80ms. Not fantastic, but "good enough" for now. I am pretty sure it can be reduced further, as there are many places where I can identify inefficiencies in the drawing of the view. I am completely confident in being able to achieve < 100ms end-to-end (allowing for the gopro's and eachine's latency, which I have not measured), and fairly confident that with some more work, <50ms should be achievable. I wouldn't fly a drone with it, but for a ground-based vehicle, it should be OK.

Anyway, new diagram of the electrical hardware (as always, still WIP):
7247

And a picture of the command/control app with the simulated robot:
7248

For the observant: the "bullet_id" is a safety system. Instead of sending a boolean for "shoot" it sends an ID. As long as the ID is changing, then the on-board software knows it should shoot. If it stops changing, the on-board software knows not to. This should hopefully prevent runaway shooting robots. It may still run away, but at least it won't be shooting anything.

jwatte
07-04-2018, 04:13 PM
The ratings are for "stall torque," and the "continuous torque" is typically 20-25% of the "stall torque" rating.
This is generally well known among mechanical engineers working with motors, and I think it's also mentioned on the Robotis site.
But more than one robotics beginner has been fooled by this, it's certainly not obvious until you've learned it!
Also, the thin wires used for the XL-320 servo connectors may have non-zero resistance when you pull current through them. Measuring the voltage at the connector, you may see a lower voltage under load than you'd see at the source (battery.)

The standard batteries that come with the Darwin Mini bot (the XL-320 humanoid) are 18650 I think, inside a small plastic shell with some charging circuitry. The OpenCM 9.04 has connectors for two of those, to drive the DXL bus.
The XL-320 servos don't draw a full amp each, though, so current capacity should be fine, as long as you use quality batteries.


This should hopefully prevent runaway shooting robots.


That's a good thing to prevent! A serial number is fine. What I do is cycle once when I receive a "high," and then I wait for a "low" (zero) before allowing the next cycle. It's approximately the same thing, with a single-bit counter :-)
Most of the time, though, when I've suffered a runaway gun, it's been because of latch-up or other electric problems in the control of the gun MOSFET. The inductive noise from the gun is sometimes high, and a single snubber diode plus capacitor may not be enough (!).

sdfgeoff
07-16-2018, 06:20 AM
Look at what we have:
7250
Thanks for your input jwatte about the voltage drop on the cables. We've decided to route all the cables along the top of the leg (as seen in the image to a distribution board near where the leg mounts. In this way each leg only has the voltage drop on the wire leading to it.

Unfortunately, the leg hasn't "walked" (hopped?) anywhere yet, as we're fluffing around on the software side. We loaded up the "brain" onto the ESP32, and after an evening of playing, it all ran. However, it ran slowly, with the garbage collector was playing havoc with the timings. So it looks like the development will end up being in C. Not that I mind too much, but we'll have to see about getting it to talk to the simulator.

Another interesting development is on the communications side. As mentioned a couple times in this thread, you guys suggest the Xbee Pro or the 900Mhz variant. Now, our microcontroller (the ESP32) has an inbuilt wifi system, and while we don't want to use wifi as-is due to the difficulty of maintaining a connection in a noisy environment, another interesting opportunity presented itself. The ESP32 supports both packet sniffing and packet injection. After another evening of learning to construct 802.11 packets, we can now send data from one ESP32 to another without needing a wifi connection - it just splats data packets blindly into the ether.
After about 20m in an office environment with other devices and multiple walls most of the packets are still getting through. We plan to do some more tests before settling on this approach.
It is still in the wifi frequency bands, but so is the XBee pro. The ESP32 claims to be able to transmit at 100mW, while the Xbee pro 2.4ghz is listed at 63mw. So with luck™ we won't need any extra hardware for communications. Additionally, because it's a wifi radio, it can turn around mid-air without any issues, so we should be able to handle sending telemetry back using the same set of radios.

The next step is to write the servo protocol interface in C, which shouldn't be too hard as we have a functioning python version...

jwatte
07-16-2018, 09:42 PM
Good luck on the "blast it without caring about other transmitters" approach! It's certainly seems to be used by some remote keyboards I could mention ...

sdfgeoff
08-05-2018, 01:17 PM
We're still waiting on testing the wifi in a crowded environment. We want to use an OLED to display the statistics so we don't get funny looks wandering around a shopping mall with laptops and cables going everywhere. There's a nice ESP32 module with display that we've got two-of on hand, so hopefully this week we'll a minimal interface working.

In the between time, the code that handles the wifi at the low level has been improved to allow multiple packet types and easy packet decoding. I also discovered how to set the power level, so now we can transmit all the way up to 100mW (limited by local regs to 25mW, but I did do some tests at 100mW and was pleased with the result...). I started looking into FHSS between wifi channels, but will wait for positive results in the crowded-environment tests before I spend that time.

On the mechanics front, we tested the leg using this contraption:
7260
We loaded it centrally so the load was (probably) distributed equally on the three wheels and the leg. The leg could sucessfully roll the robot back and forward with 1.5kg mass, and the leg mechanics hit structural issues (the clips came unclipped) at 2kg. This means:
1) We need to buy some bolts so we aren't relying on the clips
2) The servos and this servo configuration are adequate for a light mech.

Time to order another 12 xl-320's. We may change the last joint slightly to allow cleaner leg-lifting over a wider workspace.
Anyone know how heavy a set of target plates for the light mech class are?


From the software side, we are hoping to use micropython (as mentioned before). After loading the code from the simulator onto it (and fixing a few compatibility issues) we got a mainloop speed of ~20Hz, and the garbage collector was running all the time. Most of the GC-heavy work was in the packet parsing, so when we change to using the onboard-wifi directly from C, it should be less of a problem. It took a fair while to figure out how to write modules for micropython in C, but it's now figured out, and isn't too hard. Both the interface to the servos and kinematics are now implemented as C modules, but the performance hasn't yet been re-tested (slightly different interfaces). I think performance should be adequate with the communications and kinematics done in C, and the supervisory logic (and gait engine) in python.

giantflaw
08-05-2018, 03:15 PM
Anyone know how heavy a set of target plates for the light mech class are?

A complete set of light mech target plates weigh 121 grams. They are half size plates and can be mounted vertical or horizontal with velcro. The full size plates and the half size plates are self powered by a small 3.7V lipo. The normal size plates contain the one battery in the rear plate with the transponder and radio. The half size rear plate only contain the transponder and radio. The battery for the half size plates is mounted at the discretion of the host robot with a pigtail wire connector that connects to the rear plate.

sdfgeoff
11-10-2018, 05:06 PM
Thanks giantflaw, 120g is lighter than I was expecting.

-----------------------------------------------------------------------------------
Been a while since I posted here, so I thought I'd drop by with news.

On the communications front, there are some interesting limitations with the ESP's internal radios that took a while to figure out, but that's almost all sorted now. Looks like we'll be limited to about 30 packets per second for control and 30 packets per second for telemetry. The size of the packets doesn't seem to be too important, but the radios sit in RX mode and then take 1-2ms to switch into TX mode. I'm still not sure if this is correct, or if it's just something I'm doing wrong. The error is a rather cryptic "out of memory" error, which is reported to be in the queue of packets to be sent - indicating that they aren't sending fast enough. Unfortunately there isn't any way to investigate further. That said, 30PPS should be plenty, although the game developer in me likes everything to run at 60FPS.....


The weapons side has also turned out to be a bit more of a challenge than expected. After throwing around some proof-of-concept maths, the planned weapon proved unfeasible - needing a solenoid that could exert some 3 tonnes of force over a 10mm stroke. A couple alternate designs have been thrown around (including some with electrostatics....), and it looks like we'll be developing something similar to the "twin wheels" autocannon (http://forums.trossenrobotics.com/showthread.php?8373-Autocannon). It turns out you can get 10,000kV brushless motors of 1cm diameter, which, when driven at the battery voltage of 7.4v, should be able to achieve enough velocity to get the maximum projectile velocity permissible within a very small physical space.

We've made the decision to have the gun contain a separate microcontroller. It will appear as a "servo" on the dynamixel bus, and this will mean that all the wiring around the robot is "power + dynamixel bus." This also means that additional logic can be run on the gun (Eg counting shots fired, measuring shot velocity), and queried by the main processor. The legs require a significant chunk of the 1Mbps bus, so it may be that the entire turret (pan, elevation, weapon) is run on a second bus.

tician
11-10-2018, 07:30 PM
The weapons side has also turned out to be a bit more of a challenge than expected. After throwing around some proof-of-concept maths, the planned weapon proved unfeasible - needing a solenoid that could exert some 3 tonnes of force over a 10mm stroke. A couple alternate designs have been thrown around (including some with electrostatics....), and it looks like we'll be developing something similar to the "twin wheels" autocannon (http://forums.trossenrobotics.com/showthread.php?8373-Autocannon). It turns out you can get 10,000kV brushless motors of 1cm diameter, which, when driven at the battery voltage of 7.4v, should be able to achieve enough velocity to get the maximum projectile velocity permissible within a very small physical space.


I'd love to see that maths. A standard 0.2 [g] BB at 180 [ft/s] (55 [m/s]) is barely 0.3 [J] of energy, while 3000 [kgf] over 0.01 [m] is 30 [J].

As for 10,000kV motors, I've never seen one; only 10,000Kv motors.

From that bit of pedantry...
Oddly, I have recently been giving serious thought to building an array of 1nF 100kV capacitors made from ~1.6mm Al plates covered with a paint-on layer (paint, epoxy, rubber, etc.) to neutralize any sharp edges, wrapped in ~4mm of polyethylene film, stacked into a brick with terminals on opposite ends, wrapped in another 5~10mm of polyethylene film to finish insulating plates from surroundings, slipped in a steel box, and finally vacuum potted with epoxy. Lots of possible uses for that, but magnetic pulse welding is the least likely to get me on any more watch lists.

<VENT>
This stems partly from off-the-clock work on a ~1.2kV power supply and transimpedence amplifier board/stack to fit inside a <80mm length of 30mm-ID tube, which in turn stems from the intense desire to strangle a certain boss with the high-voltage carrying PMT cable and ridiculously expensive/uncommon/annoying connectors we have to use because of legacy designs that place the third-party Cockcroft-Walton generators in a PC case full of other horrible in-house legacy designs (most poorly created in 1980s and 1990s, and almost none newer than, or modified since, ~2003). I die inside a little every time I have to build any of these ghastly abominations. We also had severe/costly issues on a project recently because said boss and his superior still think TTL signaling is relevant today, where most everything is actually built around CMOS (a <2V 'high' pulse from a position sensor is not even close to meeting 5V CMOS input requirements; and why the fuck are we still using BJTs on everything, damnit!).
</VENT>

jwatte
11-10-2018, 07:56 PM
There are only two kinds of systems: Dead systems, and Legacy systems.

jwatte
11-10-2018, 07:56 PM
That being said, how about a 0.2g carbon steel BB with a hollow-core solenoid accelerator? Can we get it up to 55 m/s?

sdfgeoff
11-11-2018, 04:22 AM
I'd love to see that maths. A standard 0.2 [g] BB at 180 [ft/s] (55 [m/s]) is barely 0.3 [J] of energy, while 3000 [kgf] over 0.01 [m] is 30 [J].
It goes something like this: the world isn't perfect, and solenoids are horrible.
The hope was to accelerate a solenoid to a low speed, and use the impact of it with the bb to accelerate it the rest of the way. Unfortunately, momentum transfer can only maximum double the velocity - even if the impactor is a hundred times heavier than the bb. So to get a bb at 50m/s, you have to get the impactor to 25m/s.
From there you can do the required calculation for force over the distance. To get to 25m/s in 0.01m, you have to accelerate it extremely fast. Assuming a constant acceleration (and thus an average velocity of 12.5m/s, you only have some 0.00083 seconds along the 1cm stroke. To achieve 25m/s in 0.00083s, you need some serious force.
I couldn't find my original spreadsheet, and I recall taking a different approach to solve it, so when doing the math the way mentioned above, I now get some 125kN of force:
7340
Very comforting to know I can't get the same answer twice with different approaches. I'm more convinced by my previous one than this quick-and-dirty approach, so let me know if there's something I'm overlooking (It's probably obvious, but I can't see it at the moment).

Then there's the fact that a solenoid does not provide linear force, far from it. A solenoid rated at 1kg provides barely 200g of force at the far end of it's stroke. One idea we had was to use a neodymium magnet to increase the force without needing to add more electrical energy. However, I'm still not convinced you can get within an order of magnitude of enough force.

Unfortunately this math applies to every direct acceleration method - you need a crazy amount of acceleration. Either this can be done using air to turn a very low velocity spring into a very high velocity air-stream (as in a normal AEG), or using a spinning mass with enough angular momentum to not take too much of a velocity hit when the bb gets accelerated (ie the mass of the spinning bits needs to be several times the mass of the bb).


Hahaha, yes, a 100kV motor may be a little hard to power on a mech of this scale. However, we were considering using electrostatics for one of our weapon ideas: charge up the bb with one polarity and have the other polarity at the end of the barrel (or somewhere else in the barrel). However, none of us have enough knowledge about electrostatics to say if this would work for certain. Either way, two spinning wheels is easy to compute and easy to build. No high-voltage sources to disrupt your onboard electronics....

----------------------------------------------

Legacy hardware is worse than legacy code, and we've been fighting code rot at work already, despite our systems barely being more than a year old. Looking at you, docker [non enterprise version], with your 6-month support cycle, looking at you solidworks, with new files being unreadable in last years version, looking at you, ubuntu, breaking the nvidia drivers on a system with updates seemingly disabled [it did a kernel security update that borked nearly all the machines in our office for several hours at various points over a few weeks], and then there was one machine that died when daylight savings shifted time backwards for an hour....... It seems like neither the open source or proprietary software is stable enough to build any sort of product on, at least not one that you can expect to operate for the next ten years.
Very much either "behind by six months", "legacy" or "dead"

jwatte
11-11-2018, 11:53 AM
We have a cron job that updates all exeternal dependencies and force-commits them twice a week. Yes, sometimes shit breaks, but it's usually much easier to diagnose on a monday or wednesday morning with one or two changes, than if you go a year and then have to resolve a bunch of shit at once.


It seems like neither the open source or proprietary software is stable enough to build any sort of product on, at least not one that you can expect to operate for the next ten years.


Static stability is an illusion; there is only dynamic stability. (Also, the race to the bottom in quality, because most people most of the time would rather have buggy new features now than well-tested old features later. Market forces do the rest.)

Regarding direct impact, there's actually another problem, which is that you'll deform the BB and get jams in the mechanism/barrel. There's a reason AEGs have converged on air pumps...

tician
11-11-2018, 12:04 PM
It goes something like this: the world isn't perfect, and solenoids are horrible.
The hope was to accelerate a solenoid to a low speed, and use the impact of it with the bb to accelerate it the rest of the way. Unfortunately, momentum transfer can only maximum double the velocity - even if the impactor is a hundred times heavier than the bb. So to get a bb at 50m/s, you have to get the impactor to 25m/s.
From there you can do the required calculation for force over the distance. To get to 25m/s in 0.01m, you have to accelerate it extremely fast. Assuming a constant acceleration (and thus an average velocity of 12.5m/s, you only have some 0.00083 seconds along the 1cm stroke. To achieve 25m/s in 0.00083s, you need some serious force.
I couldn't find my original spreadsheet, and I recall taking a different approach to solve it, so when doing the math the way mentioned above, I now get some 125kN of force:

Very comforting to know I can't get the same answer twice with different approaches. I'm more convinced by my previous one than this quick-and-dirty approach, so let me know if there's something I'm overlooking (It's probably obvious, but I can't see it at the moment).

Then there's the fact that a solenoid does not provide linear force, far from it. A solenoid rated at 1kg provides barely 200g of force at the far end of it's stroke. One idea we had was to use a neodymium magnet to increase the force without needing to add more electrical energy. However, I'm still not convinced you can get within an order of magnitude of enough force.

Unfortunately this math applies to every direct acceleration method - you need a crazy amount of acceleration. Either this can be done using air to turn a very low velocity spring into a very high velocity air-stream (as in a normal AEG), or using a spinning mass with enough angular momentum to not take too much of a velocity hit when the bb gets accelerated (ie the mass of the spinning bits needs to be several times the mass of the bb).


Part of the problem is that you are using grams in your calculations instead of kilograms. Kilogram is the standard mass in SI, and gram -despite its lack of prefix- is actually the non-standard unit. One Newton [N] is one kilogram-meter/second-second [kg-m/s-s]. One kilogram of force [kgf] is ~9.81 [N] (i.e. one kilogram at one G acceleration).






Hahaha, yes, a 100kV motor may be a little hard to power on a mech of this scale. However, we were considering using electrostatics for one of our weapon ideas: charge up the bb with one polarity and have the other polarity at the end of the barrel (or somewhere else in the barrel). However, none of us have enough knowledge about electrostatics to say if this would work for certain. Either way, two spinning wheels is easy to compute and easy to build. No high-voltage sources to disrupt your onboard electronics....

Apparently you still miss it:
kV == kiloVolts - a unit of electrical potential; greater than 600V operating voltage is the realm of specialty motors because of the increased insulation requirements decreasing winding packing efficiency and difficulty/danger in actually getting access to the >600V power grid.
Kv == RPM/V - one form of the motor constant - this form relating rotational speed to voltage across the winding




Legacy hardware is worse than legacy code, and we've been fighting code rot at work already, despite our systems barely being more than a year old. Looking at you, docker [non enterprise version], with your 6-month support cycle, looking at you solidworks, with new files being unreadable in last years version, looking at you, ubuntu, breaking the nvidia drivers on a system with updates seemingly disabled [it did a kernel security update that borked nearly all the machines in our office for several hours at various points over a few weeks], and then there was one machine that died when daylight savings shifted time backwards for an hour....... It seems like neither the open source or proprietary software is stable enough to build any sort of product on, at least not one that you can expect to operate for the next ten years.
Very much either "behind by six months", "legacy" or "dead"

Still not worse than using a $500 FPGA dev board to control only two to four stepper motor drivers using acceleration profiles, because they could not get one small PIC per stepper motor driver to use acceleration profiles, because they could not figure out how to make one larger PIC control four motor drivers "simultaneously" without acceleration profiles. I'm trying to consolidate/eradicate most of the abominations with a single ATSAMD51 board and some shift registers to control all the motors, shutters, position sensors, clock lines, trigger signals, etc. they could possibly want in any of the instruments. The analog board is a bit more problematic since even a single 16-bit ADC at 1Msps dumps out more data than full-speed USB can handle. Looking at building something around a Cypress USB3 super-speed breakout board (CYUSB3KIT-003), since the existing FPGA stuff (motors and ADC) is built around a similar Cypress USB2 high-speed IC.

jwatte
11-11-2018, 11:03 PM
The Cypress stuff is what Saleae uses for their logic analyzer product, so that ought to work.

If not, make it PCI-Express and call it good :-)

(You could perhaps squeeze it into a M.2 form factor if you don't need too many lanes.)

tician
11-12-2018, 12:06 AM
If not, make it PCI-Express and call it good :-)

(You could perhaps squeeze it into a M.2 form factor if you don't need too many lanes.)
Nope. Can never be anything installed directly inside a PC and even if it could be guaranteed we were using a full PC capable of accepting any cards, PCI-Express would still be a bigger pain in the ass programming wise than plain USB or ethernet. Squeezing the buffer op-amp, ADC, microcontroller/FPGA, etc. into the M.2 form-factor would be ridiculous and pointless since it needs to accept actual wired inputs from the sensors and those slots are always inaccessible for anything except painfully tiny coaxial cables and limited durability connectors.

jwatte
11-12-2018, 03:29 PM
View M.2 more as a connector (from which you run wiring) than the full card ...

Anyway, yeah, the Saleae logic analyzers, which I love, are made from the Cypress USB 3 FPGAs, so they seem legit.

And I still think you shouldn't mechanically impact BBS, because you will distort them and jam your gun. (To bring the thread back on topic!)

tician
11-13-2018, 06:49 AM
With an impact based weapon, a long tight-tolerance barrel does little other than reduce energy. It is easiest to think of it in terms of kicking an air-filled ball. Kicking a ball down a tube won't improve things any compared to just getting the position, angle, and force of impact correct. Hell, get those wrong and kicking through a tube becomes nearly impossible.

tician
11-19-2018, 06:44 PM
Only occurred a few minutes after my last post that most of the toy guns I had throughout childhood never used a barrel for anything other than appearances, and most of these things are still damn accurate 20+ years since manufacture.
7345
Tornado is the youngest using a spring loaded sled/holder to launch a spinning rubber ring. The pink, orange, and teal NERF thingy is the next youngest and by far my favorite with long range and high accuracy; unfortunately, the plastic lip seal inside it has shrunken with time to no longer make a great seal. The little red pop-gun and the top thing are both very, very old. The pop-gun still works quite well. The pump action thing is just two tubes: a barrel/magazine attached to the front grip that holds all the balls with one end blocked off by a disk with a hole in its center and a plastic lip to seal it inside the larger diameter pumping tube at the back. It once had a rubber lip/seal that sat on the open end that decayed long ago (increased accuracy by allowing pressure to build even with slower pumping action) and the inner plastic seal has shrunken to the point it no longer produces enough pressure to force the balls out of the barrel/magazine.