Activity

derek

this devlog tracks time from our second qualifier to states
we were first in qualifers at our second qualifer (basically events have qualifier matches then playoffs), we were 2nd place in the playoffs because our robot randomly turned off during our final match (:/)

my ship log will track changes made during states and the outcome there

major changes:

  • modular auto
  • on-the-fly setting changes to customize the auto
  • further automation + testing (of several different control strategies)
  • improved PID controllers

lots of bugs squashed

  • occasionally there would be different starting conditions as static variables are preserved between runs leading to some interesting behavior
  • using sequential commands in rapid succession would sometimes cause the program to crash (oops)
  • various other fixes

our robot is the one on the bottom right (red 20748)

Attachment
0
derek
  • Wrote an autonomous procedure and tested it (see attached video): the robot is controlling itself!

  • Decreased looptimes from 60ms down to 10ms (through a variety of optimization strategies, mainly caching motor powers, bulkreads, not reading from more devices than when absolutely necessary, and not writing to more devices than when absolutely necessary) + added logging for looptimes

  • Changed lots of keybinds

  • Added more automation and fixed previously broken automation

  • Refactored lots of code to prepare for autonomous control of the robot

0
derek

new methods

  • to spin to intake position
  • to spin to outtake position
  • automation for various things
  • heading lock (to auto aim at the goal)

attached is a video of the auto intake + auto shoot (it’s pretty fast 🔥)

0
derek

did some more testing in order to add some distance tracking and also did some autonomous planning

Attachment
0
derek

pretty uneventful, added some more verbose logging for a motor encoder + did some more testing around with a limit switch

Attachment
0
derek

context: my school (private) has its own closed source ios app, made by a former student but they never open sourced it. I’ve uncovered some of the api routes, and am building an android version because 1) why not 2) people with android phones can’t use it right now

started work on my app but creating default screens and basic information from my school’s api (which returns data in a very weird way)

picture of the navigation screen attached, I can’t show the profile screen (which is the only other screen I coded since it has personal information on it lol)

I also misspelled android so now I have 2 hackatime projects ‘noblesapp-anroid’ and ‘noblesapp-android’

Attachment
0
derek

worked on refactoring sooooo much, unspaghetti coded a ton of the project + did some setup for whenever the hardware catches up

also added an alliance manager component (basically in competition there are RED and BLUE alliances and you get randomly assigned). There are various things that need to update if we’re RED or BLUE, so now we can set that!

diff: https://github.com/Nobles-Robotics/20748-Decode/compare/main%40%7B3day%7D...main?diff=split&w

not very exciting but needed to be done :(

Attachment
0
derek

Shipped this project!

Hours: 5.89
Cookies: 🍪 46
Multiplier: 7.8 cookies/hr

pretty straightforward implementation of sticky messages with kotlin, a language that is still pretty new to me. generally, I think it well, ran into some issues surrounding the flow of setting a message / updating it after starting a message (and also error handling since, originally if you manually deleted the message before the bot updated it it would just…. fail in the coroutine and never post a new one woopsy!)

derek

the goal of this feature was to be able to sticky messages in channels on discord, for security concerns we weren’t able to add another discord bot but, we wanted to add it to our internally maintained discord bot

what are sticky messages?
they are messages that are constantly bumped to the bottom of the feed within channels, so that hopefully people won’t miss them!

branch diff against upstream: https://github.com/SantioMC/MinehutUtils/compare/master...DDbrother9999:MinehutUtils:feat/starlight/sticky

  • features -
    sticky command
  • subcommand start -> starts stickying a message
  • subcommand set -> sets the stickied message (or updates it)
  • subcommand stop -> stops stickying a message

manager

  • kotlin coroutines to check for messages and update them only if the last message in a channel was not the message (we want to try to limit the number of updates, and optimize where possible)

logging

  • using internal logging, to log actions in a designated channel

comments / lint

  • repository guidelines, etc

this was my first time using kotlin, from developing in java so managing null values explicitly was something new for me

Attachment
Attachment
0
derek

I am the lead programmer for my First Tech Challenge team. Our robot picksup balls and launches them at a goal. This devlog runs up until our first qualifier (I forgot to post devlogs before this, so this is insanely large, but there are VERY frequent commits in the repository + I plan to post devlogs more frequently after this, woopsy, and I needed to start somewhere so that future devlogs aren’t so egregiously large).

this devlog is accurate up to the code in the branch freeze/qual1 on https://github.com/Nobles-Robotics/20748-Decode/tree/freeze/qual1

What I worked on:
Drive (4 motors + mecanum wheels, which basically is a form of movement that allows turning while moving; however, this makes the code a little more complex)

  • A heading lock to always face one corner of the field (based on encoder data supplied by odometry wheels + onboard calculations (inverse tangent of x and y to determine angle))
  • Autonomous control using an external library

Intake (Motor + spinning wheels to pick up balls)

  • basically 3 states -> either the motor is spinning forward, stopped, or backward

Storage (Motor + space to store 3 balls)

  • 2 commands (run to intake + run to intake, using data from the motor encoder to properly calculate turns of 120 degrees (empirically measured as ~186.66 ticks per 120 degrees))
  • Challenge: the motor encoder isn’t very accurate and after a lot of thinking one way to run this was to run to intake positions clockwise, and outtake positions counterclockwise, that way the error atleast doesn’t accumulate and atleast stays constant throughout the course of a match (the intake and outtake are on opposite sides of the robot ie. offset by 180 degrees so some basic math is sufficient to determine the ticks to next position)

Outtake (Motor + flywheel)

  • 2 commands (spin up to 2100 ticks/s using a PIDF controller (Proportional Integral Derivative Feedforward and run down to let the flywheel, well, run down and stop)
Attachment
0
derek

I’m working on my first project! This is so exciting. I can’t wait to share more updates as I build.

Attachment
0