Swerve has a problem we can't solve :(

Hi CD community, I need a lot of help right now.

We switched to a new Swerve chassis with our team. Since our old software team was disbanded, we are in a kind of relearning phase with a new team (Since I am not a software developer, I cannot provide complete information.)

Last season, we were controlling MK4I swerve modules with Cim + Neo motors connected in reverse (Cim; Rotation, Neo; Drive) and we were running rotation only with cancoder data and although it was prepared in a short time like 1 week, it was very stable and did a good job. Now our motor and motor drivers have arrived, we started working on a swerve chassis with 8 neos.

OLD CHASSIS


don’t pay too much attention to the electrical system :smiley:

NEW CHASSIS

We use in the robot;

  • navX2 MXP
  • Full Neo + Spark Max
  • CanCoder
  • SDS MK4I Swerve Module

At first, everything was going well and our team took care of the software part in 1 day. Although we had a lot of problems in our first trials yesterday, we are in a much more acceptable position in the last trials today compared to the first trials. But we still have some critical problems to solve.

As far as I can see, our biggest problem is setting the angleoffset. Normally it is a very simple process, we set it manually and transfer it to the software according to CanCoder data. But each time, although we test it many times, it does not adjust itself according to the angleoffset we give according to the cancoder data. We don’t have any problems in the drive part or rotation part (except that the motor forward and backward movements are wrong), it seems to be working very stably. But since the robot has problems in adjusting the angleoffset, even though each wheel turns in one direction at the same rate, they turn in different directions because their starting angles are different.

I think the main reason for this is a disproportion between Navx2 - CanCoder - Neo Encoder. When I try the engines manually, every data looks as it should. They are all pointing in the right direction at the right angles.

Here is the github link; GitHub - WoXy-Sensei/moonstar2024

We have no idea what to do now because we have tried all the variations. Even the smallest idea can help us a lot. Thanks in advance :pensive:

6 Likes

What is your procedure for setting the offsets? Make sure you set them all to zero, deploy, and then get the values. I’ve forgotten about setting them to zero before and then it’s a losing battle.

2 Likes

A not answer to your questions…

You may want to look at adopting an existing swerve library… There are several threads on CD regarding them and especially if you are “starting fresh” you should consider.

A likely answer to your question…

The CTRE/CANCoder configuration calls are asynchronous. So, it is likely that they have NOT finished when you are are pulling data back from the CANCoder to seed your offset into your steering motor.

I only briefly looked at your code, but this was a common challenge during last season and CD has several threads on attempts to address this… you can delay, you can specify a timeout, you can map a button to “try again”, you can loop until it looks successful…

I hope this helps!

1 Like

Great point! If you’re starting fresh, I highly recommend using Phoenix 6 now that it’s freemium. The problem with the CANCoders not being ready has likely been solved. There is no solution with Phoenix 5, only workarounds.

1 Like

Thank you for your help :heart:
@gdefender @Hollisms

Yesterday, while doing some research, I found this github link;

Looking at the articles and videos, the problem seems to be very similar. I will examine a little more clearly and check our code again (for the 100th time)

You can check the link if you want, it will help you understand our problem better. I hope we will solve it as soon as possible.

1 Like

Yup! Very familiar with it! (My comments are in the issue… :wink:)

1 Like

Again, I highly recommend switching to CTRE Phoenix 6 because this problem is solved. If you need more details, please ask.

1 Like

You should check: your first chassis had the motor above. The new chassis seems to be the 4i configuration. That probably means you need to invert all the motor directions in the code.

If the code commands the module to turn in the positive direction (counter-clockwise) and it goes the other way, the whole control system will be hopelessly confused.

2 Likes

We will try this as soon as possible. Thank you very much for your help :smiley:

As far as I can see, our biggest problem is setting the angleoffset. Normally it is a very simple process, we set it manually and transfer it to the software according to CanCoder data. But each time, although we test it many times, it does not adjust itself according to the angleoffset we give according to the cancoder data.

Are you seeing the wheels unexpectedly change their rotation simultaneously, about 10 seconds after initialization?

1 Like

In fact, it does the first offsetting process well, but after using the robot idle for a while, when we turn it off and on, it does not come to the old offset values.

It may not be obvious, but when you write the CANcoder offset in your robot software, it overwrites the value stored in CANcoder flash. If you read the offset, modify it, and write it back, you’ll end up with a different position each time you restart.

1 Like

This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.