Page 1 of 3 123 LastLast
Results 1 to 10 of 27

Thread: Starting a quad build - A couple questions

  1. Starting a quad build - Leg layout and target plates?

    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:

    But when the legs have moved, the side target plates may become obscured:

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

    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?

    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.

    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.

    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.

    My biggest concern on every robot I build is always reliability. Any advice on this other than thread-lock all bolts?
    Last edited by sdfgeoff; 06-13-2018 at 06:21 AM.

  2. #2

    Re: Starting a quad build - A couple questions

    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:
    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 :-)

  3. #3
    Join Date
    Jun 2013
    Tucson, AZ
    Rep Power

    Re: Starting a quad build - Leg layout and target plates?

    Click image for larger version. 

Views:	173 
Size:	11.7 KB 
ID:	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.

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

    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:

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

  5. #5

    Re: Starting a quad build - A couple questions

    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 :-)

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

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

    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).
    Last edited by sdfgeoff; 06-23-2018 at 02:26 PM.

  7. #7

    Re: Starting a quad build - A couple questions

    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.

  8. #8
    Join Date
    Jun 2013
    Tucson, AZ
    Rep Power

    Re: Starting a quad build - A couple questions

    Out of Curiosity, what did you use to do the simulation?

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

    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

    It's blender game engine, and it uses bullet for physics. 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, 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.

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

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

Name:	communication.jpg 
Views:	176 
Size:	33.6 KB 
ID:	7247

    And a picture of the command/control app with the simulated robot:
    Click image for larger version. 

Name:	interface.jpg 
Views:	167 
Size:	53.9 KB 
ID:	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.
    Last edited by sdfgeoff; 07-04-2018 at 09:03 AM.

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, 12: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, 09:41 PM
  3. Couple Questions on Trossen's stock
    By tom_chang79 in forum Humanoids, Walkers & Crawlers
    Replies: 4
    Last Post: 06-29-2010, 05:03 PM
  4. Question(s) Phoenix Kit Build Questions
    By Kai in forum Mechanics / Construction
    Replies: 31
    Last Post: 09-07-2009, 12:51 AM
  5. Project starting a dynamic running robot plus some questions
    By ragusila in forum Robotics General Discussion
    Replies: 0
    Last Post: 10-24-2008, 11:50 PM

Posting Permissions

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