Page 2 of 3 FirstFirst 123 LastLast
Results 11 to 20 of 27

Thread: Starting a quad build - A couple questions

  1. #11

    Re: Starting a quad build - A couple questions

    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 (!).

  2. Re: Starting a quad build - A couple questions

    Look at what we have:
    Click image for larger version. 

Name:	36909853_1541825562613230_6079609998004977664_n.jpg 
Views:	44 
Size:	43.3 KB 
ID:	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...

  3. #13

    Re: Starting a quad build - A couple questions

    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 ...

  4. Re: Starting a quad build - A couple questions

    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:
    Click image for larger version. 

Name:	leg_tester.jpg 
Views:	40 
Size:	79.5 KB 
ID:	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.
    Last edited by sdfgeoff; 08-05-2018 at 02:20 PM.

  5. #15
    Join Date
    Feb 2012
    Location
    Tucson, Arizona
    Posts
    131
    Rep Power
    24

    Re: Starting a quad build - A couple questions

    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.

  6. Re: Starting a quad build - A couple questions

    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. 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.

  7. #17
    Join Date
    Sep 2010
    Location
    ಠ_ಠ
    Posts
    2,252
    Images
    27
    Rep Power
    273

    Re: Starting a quad build - A couple questions

    Quote Originally Posted by sdfgeoff View Post
    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. 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>
    Please pardon the pedantry... and the profanity... and the convoluted speech pattern...
    "You have failed me, Brain!"
    bleh

  8. #18

    Re: Starting a quad build - A couple questions

    There are only two kinds of systems: Dead systems, and Legacy systems.

  9. #19

    Re: Starting a quad build - A couple questions

    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?

  10. Re: Starting a quad build - A couple questions

    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:
    Click image for larger version. 

Name:	math.png 
Views:	15 
Size:	19.3 KB 
ID:	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"

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Similar Threads

  1. First robotics bioloid premium... Couple of questions
    By Frank1982 in forum Humanoids, Walkers & Crawlers
    Replies: 12
    Last Post: 11-24-2012, 01:24 PM
  2. Question(s) Two questions about starting with robots
    By BurningKatanaa in forum Robotics General Discussion
    Replies: 11
    Last Post: 09-16-2012, 10:41 PM
  3. Couple Questions on Trossen's stock
    By tom_chang79 in forum Humanoids, Walkers & Crawlers
    Replies: 4
    Last Post: 06-29-2010, 06:03 PM
  4. Question(s) Phoenix Kit Build Questions
    By Kai in forum Mechanics / Construction
    Replies: 31
    Last Post: 09-07-2009, 01:51 AM
  5. Project starting a dynamic running robot plus some questions
    By ragusila in forum Robotics General Discussion
    Replies: 0
    Last Post: 10-25-2008, 12:50 AM

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •