First impression / issues after buildup

Hexy Questions, Problems and Suggestions
#1

Finally had some time to build hexy.

Instructions are clear enough , no missing pieces , nice little “to much” of the screws provided. I had no DOA servo’s aldo some make a rather funny noise (ordered already replacement gears :slight_smile: )

I’m however not very impressed with the tolerances on the pieces… it works, but only sort of.

I was under the impression that “laser cut” meant one could make rather precise and (at least) repeatable pieces.

Things i noticed:

  • Edges are a hit or a miss, i needed to scrape some plastic of some but some seam to be “melted” more than intended , this is however a rather minor thing, it is hardly noticeable when build and that does not seam to affect functionality.

Bigger issue is:

  • some smaller pieces are “warped” in their length axis (most noticeable for the small pieces used to mount servo 7,11, 15 etc.)
  • the cutting of many of the holes is not 90* straight (compared to the surface of the piece), this is as well for the square holes as for the holes for the screws…
  • the holes on the edges of the “base plate” do not really align between upper and bottom

This provokes issue with the legs, of the 6 legs only one manages to not bump into the upper or lower frame when rotating in the axe of servo 7,11, 15 etc.
2 of the 6 even bump into the frame when rotating either side ( due misalignment between upper and lower frame holes) .

edit:

You may also need to revise the power supply part of servotor32. I just had the “magic smoke” and the voltage regulator puffed.

I had no problem using usb and 5V to the “servo” power socket, but from the moment I (with all servo’s plugged in) simply inserted the “4” battery pack (using 4 Sanyo eneloop cells = 4.8v in total) to the “servo” power socket alone (I simply forgot to insert the usb cable first in my pc) I had the “magic smoke” and the voltage regulator puffed.
The board still works with USB attached but not anymore with battery (tested with adding the 4 cell to the “servo” and 5cell pack to the “logic”.
Note that this was the first time i tried to run the board with battery’s only , not sure if having all servo’s attached mattered.

I had a look at the schema and i’m a bit puzzled how this can happen, maybe is the atmel doing something silly on powerup but i don’t see where it could sink any decent current into.
by the way, what is the regulator used? I can’t see it’s model in the schema?

edit2: send above also to replacements@arcbotics.com

#2

Apart of above issues there seam to be something strange going on with the servo’s, I first of all set hexy on a box so all legs where “free” (to avoid load and damage) and then used PoMoCo’s “set zero” to align all the servo’s. (yes, i’m using v1.7 :slight_smile: )

I did noticed however some instability, if you “trim” one servo then sometimes (not always) all servo’s “gibber”. Same if you use the slider to move one servo then often the other all start to “gibber”.

I used a (cheap -> Open Bench Logic Sniffer) “logic analyser” to have a look at the pulses (of for example servo 10 to 15 when trimming an other servo) and they seam all fine.
The used power supply was usb power for logic and 5v 10A bench power supply for the “servo entry”.

The only thing i can think of is some kind of “noise” feed to the servo’s that the cheap logic analyzer simply cannot see. I’ll see if i can get something better and/or hook it up to my scope.

it would be nice if other people could confirm above or not.

#3

Hi Guntherv,

As far as the board, we’ll go ahead and replace it for you, you can just send it as a return. We’ve had a couple of people have a plug-in issue with the voltage regulator. For reference, its this part:
digikey.com/product-detail/e … ND/1979782

We’re doing another batch of boards, and are going to be specifically testing this part with a 9v battery on both ports to make sure we’re avoiding this in the future.

The all-servo-jitter when one part moves is a known problem, which I’m 95% sure is a software issue. Still trying to find out what causes it.

#4

Also, as to the hips hitting against the body, this can often be resolved by adding a second nut to the screw on which the leg pivots.

#5

[quote=“roboalchemist”]Hi Guntherv,

As far as the board, we’ll go ahead and replace it for you, you can just send it as a return. We’ve had a couple of people have a plug-in issue with the voltage regulator. For reference, its this part:
digikey.com/product-detail/e … ND/1979782

We’re doing another batch of boards, and are going to be specifically testing this part with a 9v battery on both ports to make sure we’re avoiding this in the future.
[/quote]

cheers, no need to send a new one to me, i’m going to mod it anyway to add a decent 5v source so i can use 2c lipo’s , plenty of those around.
And i’m looking at using a rasberry Pi or so

[quote=“roboalchemist”]
The all-servo-jitter when one part moves is a known problem, which I’m 95% sure is a software issue. Still trying to find out what causes it.[/quote]

some timer re initialization going wrong?

#6

yeah, that will raise it indeed, but this is my first “plexy lazercut” kit and I’m actually a bit disappointed in the quality of the body /pieces, I did not expected so much tolerance on pieces. But yeah, on the other side for this pricepoint… :slight_smile:

by the way, Is it intended that the holes of the base and upper plate for the legs “inner servo axis” not align when you put them on top of each other?

#7

No, they should align. Most of the issues we’ve had aren’t as much to do with the tolerance of the cutter, as older files creeping into the laser cutters. We’ve gone through and cleared out all our older folders, deleted everything we weren’t actively using, etc, and this seems to have solved the problem.

Our best guess is that the jitter is resultant from how the servo timing table gets re-written after each 20ms servo timing period. Currently it does a complete refresh of the entire timing table, but it does it after every servo’s pulse gets updated to avoid conflicts. However, that doesn’t seem to prevent this ‘cross-over effect’, even though it should. I’m re-writing the backend timing engine though in a much more intelligent, incremental way. It used to just update the entire table based on the every servo’s intended postions every cycle, which would eat up ~5ms every 20ms. Now, it keeps everything pre-sorted, and just does inserts and deletes, and generates a new table each time a servo gets updated. Servo updates now happen in ~150uS. I’m also planning on not refreshing the same table over and over, but double-buffering it, and swapping pointers to whichever array is the ‘active’ one for servo movement, and the ‘updating’ one for new movements. Its fairly similar to how they solve this problem in graphics cards.