We need to implement a driver for communication with the yaw encoders using PWM or I2C.

• Motors
  Probably gonna be DJI M3508 P19 but look for comparable 24v motors
• ESCs
  Probably gonna be DJI C620
• Power distribution
  • Motors
  • Power for micrcontroller
  • Power for other components (servos?)
    Thinking we do some basic octopus thing (like in robosub) and then maybe make a PCB afterwards. Also some of the DJI micocontroller breakouts come with some power distribution and regulators for 12v/5v
• Microcontroller
• Cameras?

This happens when the controller is power-cycled while the turret is facing away from the front of the robot. (It's a 2:1 belt ratio thing where the angle wraps every half turn.)

There are examples in other teams' firmware repos as well as the taproot template project.

DJI motors can use either pwm or can. Also need to think about servos and other things

• Determine flywheel
• Look at common feeding mechanisms

• Use rev bars for frame?
• Ability to rout/mill panels?
• Determine wheels
  For above we should look at other teams designs to see what's common

Currently, the flywheels are permanently on while in MnK mode. This can misfire when balls are left in the barrel after shooting.

Currently, no power is allocated to rotation when translating. This needs to be rebalanced so that beyblade does not turn off when translating.

In our auto-aim/ballistics code, there are several constants for various physical measurements currently. To accommodate multiple shooter designs and robot types, combining those measurements into a single camera-to-chassis transformation matrix inside our constants might be a good interface.

The shooter subsystem is intended to orchestrate the shooting logic between the flywheel and agitator subsystems in a single place; however, this work could be done with commands under the new system.

May require #61 before this can be implemented properly.

If we use one of the DJI breakouts they all use stm32's

This is a fail-safe to stop us from accelerating too fast and spiking our current draw in sudden movements, rough terrain, robot collisions, etc.

Needs testing, see linked branch.

So we plan to just buy a breakout for the microcontroller at first and this will probably determine which one we will use for the future. Since we can buy robomaster type c stm32 breakouts we are considering those but we also can just buy an stm32/esp32/tm4c/rp2040 breakout with a few voltage regulators and get the same thing. So look at the cost of the type c board and see if it's worth the headache to do the second option or just buy the robomaster ones.

The projectile speeds vary slightly while shooting. This makes setting the flywheel speeds harder, since we need to consider the max speed that can happen (to avoid going over speed), rather than the average speed we get.

Flywheel speeds also need to be measured for each referee system level. Again, we need to consider max speeds so we don't go over speed and take damage.

Please do so in a new branch and submit a merge request after. See this page for instructions.

Simply run pipenv run lbuild build on a Linux system, then commit those changes.

There is a bug in taproot that causes Windows-only file paths to be generated when the project is built on a Windows system. By building on a Linux system, it should work in all cases.

Currently the firmware part of the project doesn't work with the clangd LSP server. LSP servers provide IDE-like features to many editors such as VSCode (with the clangd extension in this case), Neovim, Emacs, etc. In order to work with a C/C++ project, clangd needs a compilation database file.

SCons can generate this file automatically, but it needs to be at least version 4.0. If we bump SCons from version 3.1.2 to 4.0 or higher, we could modify the SCons build scripts to generate the compilation database.

All CV components need to be installed and wired up on our robots ASAP

We have a lot of motors that are velocity-controlled by PIDs and they generally have nearly identical logic. By abstracting this out to a class, it'll clean up our subsystems a lot. We wouldn't need all those PID parameter constants, motor update functions, complicated PID initializations, etc.

We should create a container which includes all the tools needed for building this repo. It should also interface nicely with the dev container standard (mostly for the VS code extension).

Ideally this will be able to flash to the robots via USB passthrough. This will make it much more useful for development, as well as for deployment to the CV board to enable remote dev board flashing.

Currently, we don't have good build tasks, debug targets, etc., and we're typing commands in the terminal manually. It'd be a lot nicer if we setup these things.

So we're planning on use the ones that come with m3508 but maybe considering using hobby brushless escs like these. Look for other hobby escs that are 6s and fit within our current draw.

We can use this to analyze/tune mouse control and motor PIDs.

Requires #62 to be completed first before testing can be done regarding this issue.

This should factor in bullet drop, camera/barrel offset, yaw/pitch offset, and motion data from CV.

Will likely require #62 to test.

Figure out if we can find a replacement for DJI motors.
We're planning on using these for our base and then possibly gobuilda motors for our shooter and gimbal. Try to find similar motors to the DJI one in terms of torque and current draw. They can be either 12v or 24v

Set up teams and access rights, along with a repo for CV.

While power limiting will save us from edge cases, we should aim to tune our expected velocity and acceleration parameters manually for each level. This way, we're always running in optimal but controlled conditions.

The turret motors simply don't have enough power to provide quick and snappy movement, but we may be able to help the situation with different tuning. For example, underdamping yaw vs overshooting w/ oscillations.

Code needs to be refactored into a structure that Taproot supports. Currently, too much logic is abstracted into subsystems and should be moved into their own commands instead.

Now that we have the ref system, we can make a really cool UI:

Involving

• Need to know beyblading
• Chassis direction
• World direction

Our .gitignore contains an error where all ut-robomaster/build files are being tracked due to a missing slash after the folder name.

Also, the .vscode directory should not be ignored, as this contains useful project tasks, build targets, configuration, and extensions. Some files currently in this folder should either be moved to another location or ignored, as they are machine-specific.

Once all changes are made, we need to clear the cache and re-add all files to cleanup the project.
This can be done via git rm -r --cached . && git add ., then committing those changes (there'll be a ton of removed build files).

This will probably be easy once we add the code to control firing more accurately (e.g. burst fire #68).

The PID parameters currently used for the chassis wheel motors are spinning the wheels about 20x slower than they should be. These need to be reconfigured to be as accurate as possible so we can accurately determine the motion of the robot.

It might also be worth using rad/s rather than rev/min as the unit for these, since rad/s is the SI unit for angular velocity and it will be more compatible with the Mecanum math.

In theory, we can shoot eight projectiles very quickly since that's how many the agitator holds. We need to implement and test this with different fire rates. Firing them too fast may be a waste due to invulnerability time in the armor plates. Maybe there it's still worth having for spray and pray reasons? We need to consider barrel overheat for each level. We can alternate barrels with each burst.

We need to combine all the subsystems branches into develop, integrate them with each other, and figure out our input scheme.

Organizing the robot constants into categories like such as ballistics, IDs, PIDs, and physical measurements would be helpful.

Mouse input is inconsistent and jumpy from the remote getMouseX and getMouseY functions.

Other teams have reported success by increasing client sensitivity and mouse dpi, needs testing.