The second major issue was the the UcoSlam algorithm was written in C++ while the rest of my code was written in Kotlin (JVM). First, the camera was attached to the robot, but I could not run vision on the robot without severely slowing down its processing speeds. Implementing this issue had two primary difficulties. This process was far harder then anticipated so strap in for a tale. We are doing this through an algorithm called UcoSlam. The other major half of the project I have been working on is implementing our vision localization system. Also allowed units to retain dimensions across multiplication and division.
Additionally, I implement a TravellingSaleman class to find the fastest path to get through a series of waypoints. This means that all of the code I have been working on for this robot can easily be reworked to use in future robots. These have now been moved out of the main robot code and into kyberlib. Modular Automaticĭuring a previous post I talked about implementing my pathing and navigation algorithms. The end result is that the coder is able to write code for a typical robot, and then seamlessly run the simulation with no adjustments. All sensors (ie gyroscopes) and motors will automatically detect if they are in a simulation and will automatically adjust. One of the nicest features I added into kyberlib is clean, hidden support for the simulation. A lot of the code needed to be specifically written to allow for the simulation to work.
Using this new feature, however, was a bit clunky. This feature allows you to run the robot code on your laptop and simulate the effects of your robot code on a virtual robot. One of the coolest features added into WPILIB in the past couple of years is simulation.
Like KBasicMotorController, KMotorController has full support for debugging and dashboard widgets. It handles linear to rotational conversion so that you can instruct it to move a linearVelocity (ie 2 meters per second instead of 2 radians per second). KMotorController also provides getters and setters for important values about position, velocity, setpoint, and more. KMotorController abstracts away most of the math while also allowing flexiblity to tune PIDs, add Feedforwards, or even add your own custom control algorithm. Tweaking these voltages in optimal way is a very math heavy topic known as Control Theory. With this angular velocity, we can tweak our voltages to set speed we want to make the motor move. Encoders are devices that sense how fast a motor is spinning. This class wraps any motor that an enoder. In addition to KBasicMotorController, there is the more advanced KMotorController. There is currently examples for both WPI’s SpeedControllers and VictorSFX. It is both Sendable & Debuggable meaning that the voltage information can easily be sent to, and set from, the Dashboard. It has accessible open variables to set inversion & brakeMode. It control all motors and can control via voltage, percent, and follow. This class is the parent of all motor controllers. I took the initial premise and got it fully working.įirst, there is the KBasicMotorController. Previous years had started work on creating motor control classes, but I don’t think it got very far or was ever tested.
The first major upgrade has been entirely reworking the motor library.
It creates useful functions that execute common tasks, includes examples of how to create certain mechanisms, and lots of other useful libraries. Kyberlib is the backend library for team 6502 that makes all of our other work easier. This past month has been primarily focused on kyberlib.
It has been a busy couple of weeks, but I have made a lot of good progress! Let’s get into the details. I apologize for not keeping up with the blog.