Low Cost, Traction Swerve


#11

Here is a new video of the swerve drive. We turned on the traverse forward part of the algorithm so that it will not only turn to the target angle but also move forward at the command speed.


#12

That little wiggle the module does as the pid finds the azimuth is quite satisfying.

Just a thought for this type of drive surface indexed swerve module:

You could easily enough add a way to lock the azimuth for traverse of rough terrain, pushing, or loss of one of the motors. Menuverability would be hampered while engaged, but it wouldnt matter if a wheel came off the ground. You could also lock for known straight vectors (i.e. autonomous). Yes, complexity. But if you designed the module with the feature in mind it could probally be done for next to nothing in weight and packaging.

Using pnumatics or a servo you could engage a friction plate or some gear teeth on the azimuth frame (or saddle, or on the swerve forks, whatever you call it). If done right the force needed to be suplied by the actuator would be small.


#13

Do you have the CAD / list of parts / whatever else for that test bench? Super cool.


#14

Oops…wrong link. Here is the third video:


#15

We are still gathering up our BOM. I’ll release CAD once we have it on the ground and running around. I don’t want to release something that is not completely validated.


#16

Could you tell us a little bit more about how the encoder works?


#17

We use three of these IR sensor:

https://www.alliedelec.com/optek-tt-electronics-opb490t11z/70048620/?&mkwid=srXRkfvCR&pcrid=277167151383&pkw=opb490t11z&pmt=e&product=&gclid=Cj0KCQjwidPcBRCGARIsALM--eM5V-AiSYYdYIy8X9SXW6g6XAolNyaNIwg8wciYvFIZd4FinzMk-nIaAqFyEALw_wcB

to create a quadrature encoder signal. The 3rd is the Z channel to detect a single home slit around the OD of the encoder disc.

We 3D printed an attachment head that bolts onto the stationary mount plate. The 3D printed part spaces the 3 sensors to the appropriate depth to read the slots.

We laser cut a 0.030" thk steel disc with 180 slots slanted at about 20 degrees. The slot width is about 0.050".

We had some early issues with aligning the encoder head to make sure it was concentric with the axis of rotation. After a bunch of playing around I think we finally got alignment down to about 0.010". That seemed to be good enough to provide consistent readings.

It also helps that we re-zero every time we see the Z channel go high.

To be honest, we don’t love this encoder design. We question its durability and reliability throughout an entire season of getting smacked around. We have a version 2 that we are making now that will have a hollow bore slip ring and allow us to pass a encoder rod thru the center. We’ll use a standard CTRE mag encoder which we know is fairly reliable.

Picture of the assembly is attached, I think (I’m still getting the hang of posting on CD):

https://www.chiefdelphi.com/forums/attachment.php?attachmentid=23534&stc=1&d=1536528791

On the subject of slip rings, we are wondering if a slip ring is even necessary. With as fast as this turns, we can limit rotational travel to +/- 360 degrees via software and never need a slip ring. Has anyone ever tried that?



#18

I would not do this. You will hit the +360 or -360 limits far too often (if you are driving swervy and not tanky) and your modules will have to do a spin to reset back to 0. I would stick with the slip ring unless it is seriously constraining your design. If you are using 775s, you probably want to limit the motor power to well within the limits of the slip ring, so I don’t think the slip ring will limit you power. If you have the motor controllers on the rotating part, then you have 2 wires for power and return for each motor and the other 2 wires for CAN. So you should be all set in terms of the wires.


#19

If you’ll let me propose an idea, this is how I designed an encoder mount for my traction swerves.

The mated gear is meant to be pressed onto the rotor housing of the slip ring.

It doesn’t look like your slip ring is mechanically fixed to the rotation of the module, but depending on how tightly the wires are bound that may not be a problem. Alternately, if you have talon SRXes on the module, you can put it on the module instead with a similar design and read the encoder through CAN.


#20

Can you use a smaller module/pitch gear-set to help reduce backlash error on your azimuth encoder? The pitch looks a bit large to be for precision (IMO of course). I am taking a guess here, but is that gear a 3d-printed part? I know you can only push 3d geartrains so small…


#21

What is your slip ring rated for?


#22

We can’t totally know for sure until we run this on the ground. In the test bed, it actually looked liked it snapped to it’s heading fairly well. But, I do agree and that why we’ve redesigned to include an SRX mag encoder. Should have that prototype up and running in about a week is what we’re hoping.

The gear is not a gear but an encoder disc laser cut. Laser cutter has an accuracy of +/-0.005". It was our IR sensor that required the slit to be 0.050" wide. Thus we only got the 2 degrees of resolution.


#23

It’s a 4 channel slip ring with each channel rated for 30 amps.

We got it on Aliexpress, which is now my favorite shopping place.


#24

Yes it would be 3D printed. Correct me if I’m wrong, but I think because of the involute nature of a gear, it wouldn’t matter what pitch one chooses. I could see how practically this may not be as good as theory though. Given that there’s no load on this part, I would feel comfortable starting at 20dp at least (currently 10.)


#25

With the involute tooth profile on a large DP gear you are engaging further from the line of center. This is reduced by either:

  • increasing the dp to bring the engagement point in closer to the line of center
  • switching to a cycloidal tooth pattern (a bit passe
    ) to align the tooth engagement with the line of center

In theory this all would provide better efficiency at the cost of max torque transmittance, but if +/- 2 deg is the target window and it’s comfortably being managing that I wouldn’t worry about my little rant in this post :rolleyes:

Does this matter in practice? Probably not a whole lot, so long as you are within the “realm of reasonable” and take care in making the parts.


#26

Latest Update

Built 4 of these and put them on a chassis on the ground. Initially had 775’s with 20:1 gear ratio to a 4" diameter wheel. The gear ratio was a bit too low and we were stalling out the motor or it was spinning up way too fast. It proved really difficult to control. Still working on different control algorithms. But decided to re-gear the drive to a 80:1. Tons of torque but really slow so not really all that useful in competition but it proves a few points. Most pressing is its ability to climb over obstacles. Here is a video of the chassis climbing over 1.5" angle iron:


#27

correct me if I am wrong, but if you were on a slanted surface, could you only go straight up the surface because of the weight of the robot? I could see it working on about anything under 15 degrees.


#28

Now that you’ve got a chassis built, how well does it handle uneven surfaces? I know Stryke Force has had to implement mechanical positive traction to improve steering / create higher-performance module responses on all four corners with a fairly standard architecture - this design seems even more vulnerable to loss of traction for any reason…


#29

I’m not sure where you get 15 degrees. It seems to handle climbing over uneven terrain surprisingly well. It conforms to the terrain it seems. At least it does at low speeds. Climbing a ramp should be no different.


#30

15 is just a guess. a ramp is different because all of the modules are at an angle not just 1-2. would be interesting to get the robot on a large ramp and see the performance though.