owned this note   changed 3 years ago  
Published Linked with GitHub

20220214~20220220 程式組

tags: 工作筆記 程式組

20220214

王鴻霖 Aaron Wang

Progress Summary

  1. Tele-op works normally now
  2. Trajectory following failed, currently suspecting it's due to the pose updates incorrectly

Issue Details

The solving process is as follow

  1. Adjust PID to get rid of the jittering of the motor
    initially the trajectory following failed because the PID controller used incorrect kP, kI, and kD values. I first tried to find the correct value using the sysID tool, but the returned values are too low. The robot can definitely move, but an instruction to move 8 meter only let it move 10cm. After a lot of manual tuning, we arrived at the point where it moved 30cm. More adjustment resulted in no better performance, so we moved on to testing other things
  2. Checking if pathWeaver output is correct
    We then tested if the move distance actually correspond to the pathWeaver path. It turns out that shortening the path by 50% did result in 50% decrease in distance moved, so path is probably correct
  3. Adjusting encoder
    Then, the only problem should be with the encoder. The actually adjustment process is too complicated. In short, we outputted the encoder reading onto the driverstation console to check if the value is correct. Then we adjusted the encoder velocity to actual velocity equation. The result is as follows:
motor.getSelectedSensorVelocity() * 0.8 * 10 / 2048 * DriveConstants.kWheelCircumference / DriveConstants.kGearRatio
  1. Pose update error
    Although the encoder value seems to be somewhat correct now, we found that the pose updated incorrectly. We have not yet found a solution for this, nor understand why it is incorrect.

Additional notes

The code are all updated to github. If you can, please take some time to look at it and perhaps help us find the solution.

20220215

陳伯豪

Work Progress

  1. The buttons of the big robot are fully ready
  2. Discuss how to use app " REV SPARK MAX Client " with others
  3. Motors （Except ball suction and lift） have been tested （Individual tests） and all of them are confirmed to work.

Problems and Solution

  1. REV SPARK MAX Client can't connect SPARK without CAN cables
Solution：

Because I considered that the season will come in a few days,
so I discussed this issue with the senior 
and decided to deal with it after the season.
  1. There is a problem with the motor （Upper transport ball） turning without deploying robot code
Solution：

When I tested the motor with Phoenix Tunner,
I found that the motor would have a problem of idling.
After I found it,
I asked the people from the mechanical team to help us see what
the problem was and deal with it by the way.

Reference Website

REV SPARK MAX Client download website
Spark Status LED Patterns Website
Spark Status LED Patterns translate - By LINIL

Replenish

  1. We have confirmed the lift structure with the assistant captain

20220216

王鴻霖 Aaron Wang

Progress Summary

I mainly worked on testing the new motors on the robot today. Recently the hardware team had added new motors using the SparkMax motor controller, which I'm not that familiar with. However, after some searching, I used the correct controller object CANSparkMax and was able to control one of the two motors. Turns out that certain motors and motor controllers have issues need to be resolved.

Issue Details

  1. Spark Max (CAN ID 7) doesn't move motor upon receiving signal
    Status: solved
    Solution: change to new Spark Max controller.
  2. TalonSRX (device name "Transmitter 1") unable to move
    Status: solved
    Solution: rewire connection

Additional Note

after looking at other team's code, I adjusted the encoder velocity to velocity in meter equation. Originally it was:

motor.getSelectedSensorVelocity() * 0.8 * 10 / 2048 * DriveConstants.kWheelCircumference / DriveConstants.kGearRatio

now it is:

motor.getSelectedSensorVelocity() * DriveConstants.kWheelCircumference / 2048 / DriveConstants.kGearRatio

I'm not sure if it's correct because I didn't get a chance to test yet, but I probably will test it today.

20220217

王鴻霖 Aaron Wang

Progress Summary

  1. Helped finish the tele-op shooter and transporter commands + subsystems
  2. used the sysid tool to recalculate the kS, kV, and kA constants for the robot with newly assembled parts

There isn't much to say about today. The commands are quite basic and sysid is more or less a routine process. However, we also tested the updated encoder calculation formula, which turns out to be incorrect. We will probably try to adjust it again tomorrow.

魏仁祥

今天進行了不知道是第三次還是第四次的 sysid 的測試了，但實際結果與預計結果差了非常多。目前推測問題可能出在兩個地方

  1. encoder output velocity 有問題
  2. ks kv ka 在使用 sysid 測量的情況下不準確

未來可能會人工進行 ks kv ka 的測試，但會更加麻煩且浪廢很多時間，測量出來的值也不一定準確

除此之外，學弟有提到 joystick 的值在剛開始的時候會移位，並不是剛好在 0 的位置，這個還待需測試。

陳伯豪

Work Progress

  1. Finally solved the WPILib（VS Code） problem, and I will describe the solution below.
  2. Explanation work notes with the administrative team.
  3. To understand the previous code written by Aaron.（I'm still understanding）

Problems and Solution

  1. Can't get rid of errors about code（Even if VScode asks for is given）
Solution：

I heard from the senior that he
has encountered this problem before,
and his solution is to reopen a new repo.

BUT first plug the Library in and paste the code after it.
  1. I don't not enough understanding of try catch function

黃冠穎

今天大部分時間都是在聽Aaron,Albert和魏仁祥討論機器人，有點跟不上他們的思考速度。大概寫一下

20220218

王鴻霖 Aaron Wang

Progress Summary

There's only one major progress today. However, it is certainly huge: we finally figured why the odometry was incorrect.

It turns out that due to the kinematics of mecanum wheels, when updating pose, you should use the following equation

motorFL.getSelectedSensorVelocity() * kWheelCircumference / (double) kEncoderCPR / kGearRatio / Math.sqrt(2) * 10;

The different of it from last time is that we added a / Math.sqrt(2) The reason for adding this is because the vector of the velocity of a mecanum wheel is 45 degree to the side of the robot, so multiplying by this value (sin45 or cos45) will fix the odometry update.

Here I must praise Albert for his genius. He figured out this by researching online for days.

However, although the odometry update correctly on the x-axis, it is still very inaccurate on the y-axis due to inaccuracy when the robot is moving to the side.

Apparently our mecanum wheels aren't perfect, each wheel have slightly grip on the ground, causing its rotational velocity not entirely changing into translational velocity. This greatly affected the calculation of pose, since it is based completely on the velocity reported by the encoder (which accounts for rotational velocity, then calculated to change into translational ones).

We have yet solved this problem, and we still don't know whether the correct pose will correct the trajectory tracking command. We'll test this tomorrow.

吳玠廷

1.* 今日進度

20220219

王鴻霖 Aaron Wang

Progress Summary

Today is mainly a problem identification process. (which is very dangerously close to the competition date) We tested the following things:

  1. Trajectory following (with mecanum wheel and MecanumControllerCommand)
  2. Trajectory following (with grip wheel and RamseteCommand)
  3. PID adjustment in an attempt to correct trajectory following
  4. Test differential drive with mecanum wheel
  5. Pose update issue identification

Progress Details

  1. Trajectory following (with mecanum wheel and MecanumControllerCommand)
    After a lot of testing (and adjusting of PID), I figured out a few patterns: 1. With reasonable PID values (e.g. kP<1), the robot always arrive some place at target/2. 2. With extra high PID value we can reach some where like target*3/4. However, both of these becomes false once movement on the y-axis is added. If it is added, no matter through PathWeaver or TrajectoryGenerator, everything will be messed up. The robot just won't follow the path on the horizontal axis, and sometimes even jitters.

  2. Trajectory following (with grip wheel and RamseteComand)
    This one isn't fully tested yet because I was only able to test it when I am about to leave. However, I can already see that RamseteCommand and DifferentialDrive probably is what we should go for. It is much more stable and the rotation is more easily managed. I think once I correct the encoder value for the differential drive and test it again, it should be accurate (when I left, it's still inaccurate probably because I forgot to adjust the CPR from 2048 to 4096. This is because I tested on the prototype bot that uses TalonSRX as the motor controller)

  3. PID adjustment in an attempt to correct trajectory following
    This is the slowest and most annoy process of the day. I kept adjusting the PID values, first kP, then kD, and lastly kI. However, while adjusting them does affect the result, I still feel like this isn't the real reason that the trajectory tracking fails. Although we did adjusted some close to optimal value for the large bot, it will still need to be readjusted once the repaired parts are on.

  4. Test differential drive with mecanum wheel
    Quite a strange experience to be honest. While tele-op mode seems really normal, it is just less smooth than grip wheel. Additionally, using ramsete command with mecanum wheel seems to mess up the odometry a lot, probably because of the way mecanum kinematics works.

  5. Pose update issue identification
    Because of the problem we found when testing differential drive with mecanum wheel, we probably need to change to grip wheel. However, more testing need to be done before actually changing to avoid waste of time.

Conclusion

I wouldn't call this a very exciting day, but we definitely made some progress. We'll plan carefully of what we are going to do. Currently I think changing to differential drive with ramsete command and grip wheel may be a better option.

魏仁祥

繼昨天聽到 Aaron 和 Albert 找出底盤的問題是出在因為 mecanum wheel 的運動方式與原先的 differtial wheel 不同後(運動方式和施力方式不同)，今天來到學校與 Aaron 繼續測試底盤的 pid，試圖讓底盤可以準確地進行 trajectory。

我們花了約兩個小時測試 pid，然而最終的結果大致上為底盤只能跑欲求距離的一半而已。除此之外，在速度的變化上，也沒有出現滑順的曲線，無論如何更改數值，速度斜率都很快，而且在接近目標時也沒有減慢的趨勢，有一點急煞的感覺。

圖大概長這樣

接著 Aaron 看到 Tuning MecanumControllerCommand PID Input Values 這篇，他提到在 TalonSRX controllers 上的 pid loops 是 1000hz 而 WPI control loop 卻只有 500 hz 而已，所以又改變的回傳的 peroid 讓他們兩個相符合。

然後我們在平移時發現到底盤的平移會歪掉，而這會使的在自動模式時會跑掉而不在我們預計的路徑上，所以接著討論如何處理這個部分。Aaron 嘗試使用 Ramsete Controller 跑，再分配速度給各個輪子。但這個在轉彎上會出現問題，因為輪子的受力方式不同，所以轉彎時會跑掉。

然後

痾

Bring Up: Talon FX/SRX Sensors | Confirm Sensor Resolution/Velocity

我很抱歉我寫的很亂，因為我真的不太清楚如何整理成完整的架構

Image Not Showing Possible Reasons
  • The image file may be corrupted
  • The server hosting the image is unavailable
  • The image path is incorrect
  • The image format is not supported
Learn More →

20220220

黃冠穎

進度

寫好給機械組測試的程式

額外的話

今天真的太少人來了，中午之前只有6個人來，預計要裝上的零件我15:30走的時候都還沒裝好，所以其實也沒東西可以測試。

抬升的部分

下面兩顆775寫一起控制前後擺，上面兩顆Neo寫一起控制抬升桿伸縮，按鍵另訂。

Select a repo