Chief Delphi

Chief Delphi (http://www.chiefdelphi.com/forums/index.php)
-   Electrical (http://www.chiefdelphi.com/forums/forumdisplay.php?f=53)
-   -   swerve drive (http://www.chiefdelphi.com/forums/showthread.php?t=153981)

Aslihanokur 20-01-2017 16:46

swerve drive
 
Hi teams,
This year we want to use swerve drive thus we tried it but there is a problem: We used the codes from team 1640. On the 1640's programme, cables are wired from encoder to analog. We cannot wire the cables to analog because cables have 8 outputs but the roborio has 4 inputs in the analog part. Therefore we searched it on the internet and found that we should wire the cables which come from encoder to roborio's dio part. We did it in this way but the code didn't work. In the programme that we used, the wheels don't move synchronously.
We cannot determine the source of the issue. Is it because of electronics or programme? What should we done? Can you help us please? Thank you :)

GeeTwo 20-01-2017 17:23

Re: swerve drive
 
I'm not familiar with 1640's code, but if it is written for analog inputs and you're wiring it to DIOs, you will need to (at a minimum) modify the code so that the tracking info comes from that source; I would also expect that some sort of rescaling would be required.

Also, I don't really know how to say this, so I'll just rip the bandage off. If no one on your team understands the control system well enough to have already realized what I wrote above, you're a long way from getting swerve working right; you really ought to reconsider putting this on the shelf until after STEAMworks is done and do a different drive chassis this year.

Ether 20-01-2017 17:32

Re: swerve drive
 
Quote:

Originally Posted by Aslihanokur (Post 1634127)
We cannot determine the source of the issue. Is it because of electronics or programme? What should we done? Can you help us please?

Apply a forward, strafe right, and rotate clockwise command and look at what speed and steering angle your code is sending to each wheel.

Look at those 4 pairs of speed/angle (one for each wheel) to see if the computation is being done correctly in your code.

And then take GeeTwo's advice in the previous post.




rich2202 20-01-2017 17:59

Re: swerve drive
 
I'm guessing there are 2 encoders per module, thus the 8 outputs (4 per encoder).

While the RoboRio has 4 labeled Analog Input ports, the MXP Port provides 4 more Analog Input ports.

If you use something like the NavX board, it will translate the i/o ports available on the MXP to traditional plug compatible connections.

page2067 20-01-2017 19:36

Re: swerve drive
 
Quote:

Originally Posted by Aslihanokur (Post 1634127)
Hi teams,
This year we want to use swerve drive thus we tried it but there is a problem: We used the codes from team 1640. On the 1640's programme, cables are wired from encoder to analog. We cannot wire the cables to analog because cables have 8 outputs but the roborio has 4 inputs in the analog part. Therefore we searched it on the internet and found that we should wire the cables which come from encoder to roborio's dio part. We did it in this way but the code didn't work. In the programme that we used, the wheels don't move synchronously.
We cannot determine the source of the issue. Is it because of electronics or programme? What should we done? Can you help us please? Thank you :)


It sounds like your encoders are Quadrature encoders - given that they have 2 outputs per. Quadrature encoders do wire to 2 DIO's each, however You want to have Analog or Absolute encoders for most swerve codes, I am pretty sure including Sabotage's code - this is also what we have
used in past. If not familiar - search on the many threads on CD on this.
Typically also with absolute encoders on a swerve the encoder is reading 1:1 the steering output - depending on your set up you may need an auxiliary gear, agin there are several CD posts that cover this that you can search on.

It is possible to use quadrature, (relative) encoders that you have - but I do not recommend. It involves different code of course to read and use the quadrature readings, and other considerations (initialization) and is not favored by most teams (at least by my informal observation) that run swerve. Though I believe 973's old off-season swerve may have used relative encoder.

Good Luck!

laura1640 22-01-2017 00:02

Re: swerve drive
 
Hello,

On our swerve modules, we use two different sensors. One is to determine the angle that the wheel is pointed to. Like others have said, this is an absolute analog sensor. This is helpful because regardless of what angle the swerve modules are facing when the robot is powered on, they will still read the correct angle. Each of these sensors gets plugged into one of the 4 analog IO ports on the roborio.

The second encoder is used to determine the distance that the pivot has moved, similar to other drivetrains. This is mostly useful in autonomous, where the distance the robot travels needs to be exact. These sensors can be plugged into the digital IO ports on the roborio.

Also, may I ask what version of our code you are looking at (as in what year)?

~Laura

Aslihanokur 22-01-2017 12:57

Re: swerve drive
 
Quote:

Originally Posted by laura1640 (Post 1634696)
Hello,

On our swerve modules, we use two different sensors. One is to determine the angle that the wheel is pointed to. Like others have said, this is an absolute analog sensor. This is helpful because regardless of what angle the swerve modules are facing when the robot is powered on, they will still read the correct angle. Each of these sensors gets plugged into one of the 4 analog IO ports on the roborio.

The second encoder is used to determine the distance that the pivot has moved, similar to other drivetrains. This is mostly useful in autonomous, where the distance the robot travels needs to be exact. These sensors can be plugged into the digital IO ports on the roborio.

Also, may I ask what version of our code you are looking at (as in what year)?

~Laura

We used the codes that you wrote at 2012-Rebound Rumble. I wonder if we can set the swerve drive without absolute encoders. We reshaped our codes and made some replacement on our electronics. Actually it worked.However, ıt got the point that start at the begining as zero so that we need to make all 4 wheels at the same position before we send codes the robot. Are there any solution except using an absolute encoder?

laura1640 23-01-2017 11:10

Re: swerve drive
 
If you wish, you can get some more recent code from https://github.com/frc1640. The past few repositories also have Java code for swerve if you are interested.

Using an absolute encoder will save a lot of trouble. You could try saving the value of the encoders to a file and use the last values to initialize the position the next time you power the robot on. However, if someone moves the pivots while the robot is off, it will cause problems. I would advise looking into adding an absolute encoder to your swerve for convenience.

~Laura

asid61 23-01-2017 12:51

Re: swerve drive
 
Quote:

Originally Posted by Aslihanokur (Post 1634775)
We used the codes that you wrote at 2012-Rebound Rumble. I wonder if we can set the swerve drive without absolute encoders. We reshaped our codes and made some replacement on our electronics. Actually it worked.However, ıt got the point that start at the begining as zero so that we need to make all 4 wheels at the same position before we send codes the robot. Are there any solution except using an absolute encoder?

Some teams use a magnet and a hall effect sensor to set the "zero" position for the module. Or, you could use a jig of some kind to align all the wheels at the start of the match.


All times are GMT -5. The time now is 21:13.

Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.
Copyright © Chief Delphi