Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 27 Next »

Competition Year

2022-2023 Aerial Evolution of Canada Student Competition

Team

Waterloo Aerial Robotics Group

Architect(s)

Anthony Luo

Status

DRAFT

Last date updated

by Anthony Luo

On this page

Summary

This page describes the top-level view of the 2023 competition airframe, and contains references to sub-pages with implementation specific details. This page will be finalized as of Nov 6, 2022. Any changes after that point must follow the formal RFC proces. Ping Anni for more details.

Please make ur RFC using the following link: < link to be inserted gd it anni >

🍞 Acronyms & Links

[The Drone] - The drone as a whole, including electronic components and integrated software systems.

[(the) Airframe] - Fuselage, wings, control surfaces, & mechanical components used to connect them

[ZPSW] - ZeroPilot Software ZeroPilot 3.0 Architecture

[ZPHW] - ZeroPilot Hardware

[IMU] - Inertial Measurement Unit

[GPS] - Global Positioning System (device to capture GPS data)

[ESC] - Electronic Speed Controller, Motor Controller

[GS] - Groundstation

[Tracking Antenna][Antenna Tower][Tracking Tower] - all tracking antenna systems.

[T_Telem] - telemetry tracking tower

[T_VRX] - video receive tracking tower

[GSPC] - groundstation PC

[GS_SW] - groundstation software

[GUI] - groundstation gui (software gui for user).

[OSD] - on screen display (attitude information overlayed over video feed

[rfd900x] - RFDesign RFD900x Modem (singular)https://uwarg-docs.atlassian.net/l/cp/LPn8hwCv

[Competition Design Outline] [CDO]Competition Design Outline

[Competition Requirements] [CR]Competition Requirements

📐 Architecture

<Add diagram>

The architecture of a drone can be found in the [Competition Design Outline]. <# iterations> iterations of the drone will be created, at <#milestones>. <# final copies> of the drone will be created in “competition spec”. Our system will meet the requirements in [Competition Requirements].

Our general architecture has the following hardware elements:

Airside Components:

  • Airframe (Wings, Fueselage, tail)

Power:

  • 2 6s batteries

  • 1 3s battery

  • 2 Power Distribution Boards (12V, 5V rails clean | Vbatt, 5V dirty)

Propulsion:

Compute:

Peripherals:

Antennas

Groundside Components:

Infra Components

  • Tuning Rig

    • ready for comp drone.

  • Groundstation

    • ready by mid january

Airside Architecture

Now that we know what components are going on our drone, let’s talk about how they’re going to be laid out on the drone itself. This page will be finalized on Nov 6, 2022. After that date, any changes must go through a formal RFC process involving all subteam leads.

Airside Hardware Layout

The plane will be comprised of 5 main sections: the Passenger Compartment, wings, tail, battery box, and avionics compartment. See the scuffed diagram below for more information. The batterybox + passenger compartment will be part of the main fuselage, while the nose & tail will house more electronics.

Batteries & Power Distribution

Batteries and Power Distribution shall be mounted in front of the passenger compartment, under the same access lid as the pixhawk & various other PDB/Sensors. This should make wiring easy, and make weather proofing easy. The batteries shall be placed as far forward in the fuselage as possible to help balance the overall COM of the drone.

The battery box should be easily accessible from the top so that battery swaps may be easily accomplished during task #2, and should be weatherproof and house the PDB, Batteries, and necessary power connectors in an manner that makes upkeep & plugging/unplugging/probing connectors easily.

Avionics Compartment

The avionics compartment will house all the airside compute. The compartment should be weather sealed, but be mounted on the drone in a way such that all electronics are easily accessible and serviceable with minimal effort (ideally no screws removed to plug/unplug connectors from any of the onboard computers.

The avionics compartment should allow for airflow and cooling that can be shut (either manually or automatically) in inclement weather.

Sensors may be placed in the avionics compartment, but they should be mounted where they make sense. See below

Wings & Tail & Fuselage & Peripheral Mounting

The wings and the tail will house a lot of the RF Communication modules, such as the VN-300, rfd900 antennas, vtx antennas, and any gps modules.

Sensors

The Vn-300 receiver (red box), as well as the BMX160 IMU should be placed as close to the center of mass of the plane as possible, with the axis aligned (x is forward, refer to ZPSW Documentation for more detail). This can be done above or below the passenger compartment, but should be in a weatherproofed section of the plane.

Both VN-300 receptors & their grounding planes should be placed 1M apart, facing directly upwards, above other elements. These can be mounted at the ends of the wings, or on vertical mounts above the wings (like an AWACS disk) if airflow over wings is a significant issue. The Vn-300 is significantly smaller than what is pictured on the right, and two vertical spars on each wing could be sufficient. The vn-300 is not weather rated, and should be protected.

Both NEO M.8 GPS Modules should be placed facing upwards. There is no significant distance requirement, although a small separation would be ideal. This can be done by placing both on opposite ends of the fuselage, one on the fuselage and one on the tail, or however the mech team sees fit.

Airspeed sensors should be placed in clean air, facing forwards.

Barometers can be placed as necessary.

Antennas

The RFD900x Antennas should be placed 90 degrees apart from each other. There is no distance seperation requirement. The RFD900X transmitter itself should be placed somewhere with adequate airflow.

The VTX Antenna should be placed as far as possible from other sources of RF interference (such as other antennas, sensors, or ESC’s). The tail or the bottom of the fuselage may not be bad options. The VTX transmitter itself should be placed somewhere with adequate airflow.

Cameras will be mounted outside the fuselage, one pilot cam forwards, one pilot cam downards, one CV cam downwards. The pilot cameras will feed into a 2-1 mux switch controlled by ZP before feeding into the VTX.

Motors

Motor controller placement is decided by mech, in a way such that the push prop ESC has adequate airflow, and the quad ESC’s have airflow when in use and are otherwise hidden.

Servos can be placed at the discretion of the mechanical team, provided the servos are equally balanced and symmetrical along both sides (within a few mm of error).

Airside Electrical Layout

pls confirm Daniel Puratich (Unlicensed)

Power Architecture

There will be: 2 6s patteries in parallel, 1 3s battery. The 2 6s batteries will be referred to from this point on as the “flight battery”, and the 3s battery will be refrred to from this point on as the “clean battery”. There will be 4 power rails in total on the drone;

  • VBatt Dirty (For ESC’s)

  • 12V Dirty (For Flight Controllers & Jetson)

  • 5V Dirty (for servos, LED’s, etc)

  • 5V Clean (for VTX, Sensors, etc).

All dirty power rails will be broken out from the flight battery using a PDB (i’m a fan of this one if we need a COTS pdb http://www.mateksys.com/?portfolio=fchub-12s ) , while the clean power rail will be broken out of the 3s battery.

Wiring

All of the wires for the sensors will be pre-run through the frame in dedicated channels, with connectors left exposed ear the sensor compartments and the avionics compartment. This means that any time a sensor needs to be replaced, we do not need to re-wire the entire sensor. this also means that when we need to re-wire the flight computers, we can use the cables that are already connected to the interface connectors an simply plug in a few large connector banks to our dev interfaces.

All sensors shall be connected to the respective device owners listed in the hardware components section. There will also need to be uart connections between ZP ↔︎ Jetson, as well as multiple (at least 5) communication wires available between the PX5 and ZPHW.

Connector Standardization

Darwin Clark maybe this is something thath you can take a look at?

  • XT60 used for DC power.

  • XT90 used on batteries & solder pads for COTS ESC’s PDU’s

  • 3.0mm female banana plugs on the ESC’s

  • 3.0mm male banana plugs on motor terminations?

LED’s

For realism, we will have regular Nav lights on the dirty 5V or 12V rail, as well as a green PAX aboard light that is on a 12V or 5V relay controlled by ZP.

Groundside Architecture

On the ground, there will be a primary “groundstation” GS as well as the two tracking antennas “T_Telem” and “T_VRX”. GS Will be able to run unsupported (no power, no internet), for the competition for a minimum of 1 hour or from a standard wall outlet. Main batteries should be included within the GS Enclosure as the enlosure may be left outside overnight in inclement weather. All of GS should be weatherproofed, or be able to collapse into a weatherproofed box (it could be sitting in a mud/ or a puddle).

Antenna Towers

The antennas will use directional antennas to improve connectivity with the drone, and must be placed as far apart and as high up as possible. They can be mounted on poles, and stakes may be driven into the ground with guylines to keep them upright (much like regular 5G antennas). Grounding wires can be driven into the ground as well. The towers should be as far apart as possible (one may have to be behind the tent and one in front of the tent - hence why it is important to get them to be able to go as high as possible), so that we have minimal interference. Even though we’re using different frequencies, they are still close to each other and notch filters may help significantly in signal quality, as will antenna separation. Antenna Towers should support fully tethered & fully untethered operation.

Each tower will have a: nucleo, imu, gps, antenna all mounted on the panning & tilting head. This pan/tilt head should be able to track a drone flying ~ 70km/h at a 50m radius away while maintaining accuracy within 15 degrees of the center of a drone at a max range of 7km away. Mounted on the tracking antenna (but perhaps not on the moving head) of the antenna may be signal boosters, signal relays, excess wires, wire splitters, power, etc.

Tethered Operation

In the event of tethered operation, towers will have a USB Link from the nucleos to the GSPC, as well as a set of coaxial cables (or a single one in non-diversity operation) to the modem located within the GS enclosure. Power may be supplied along a custom cable, but all of the cables running to the tower should be wrapped up and terminate together with clearly labelled interfaces on the GS enclosure.

Untethered Operation - not strictly necessary?

The towers should be able to run self-supported and disconnected from the rest of the system (including no power) for a minimum of 40 minutes. In the event that we want the towers to be running fully untethered, the Nucleos will communicate with the PC using low-power XBEES@ 2.4ghz instead of the USB tether, and we will use a PPM Relay with lower power 443 MHz Dragonlink system to communicate from the controller to T_telem. It is also possible for T_telem to be set up as a mesh where there is permanently a third nucleo inside the gs_enclosure, which will be linked to the main antenna on T_Telem that allows data to be passed through from airside to T_Telem to GSPC. A 5.8GHz video relay will be used to distribute video from T_Vrx to the pilot goggles, as well as the DVR → GSPC. Individual batteries will be provided to each tower, but these should support the system for a minimum of 1hr.

GS_SW

The software on the groundstation inscludes the GUI, as well as all the backend processing for receiving/sendeng telemetry data. This is built entirely by the CV Subteam.

Telemetry TX/RX

messaging formats will be defined in the software architecture section.

The GSPC will receive from the RFD900x as a serial stream. This will be processed by the GS_SW before being displayed on the gui and passed to the tracking tower nucleos.

The tracking tower nucleos will also interface with the computer as serial streams (either xbee or wired). Care will have to be taken to ensure there is no crosstalk between them.

GSPC will send to the aircraft using the rfd900 serial communications port.

GUI

The gui should allow for the user to see the aircraft status, aircraft track, path, waypoints, and other relevant flight data listed in Ground Station-GUI .

The GUI will also allow the pilot to edit waypoints & command the aircraft to takeoff/land in certain modes. The Aircraft shall operate in GPS_Hold mode when being operated remotely from the groundstation.

Remote Piloting

The command of the aircraft will be done by the pilot with their choice of either a dedicated set of FPV Goggles or Monitor, connected to the VRX either by 5.8 relay or direct by split rca. The controllers used will be TX16s MKII models, and a ppm relay or output converter will be provided on a frequency other than: 900, 1.2, 1.3, 2.4, 5.8. this means we need to buy more dragonlink modules?

Two controllers will be linked together, with one controller being the “master” using the trainer port. This means that if one pilot is unable to continue flying, the second pilot can takeover simply by hitting the switch. CC: Megan Spee confirm this is ok w/u at comp?

Software Architecture

This section will discuss the computers involved, before then diving into communication architecture as well as messaging formats, different flight modes, and failsafes.

Note that in our architecture, all communication from and to the ground is going to go through either the RFD900x, or the VTX module.

The computers

There will be three computers onboard the 2022-2023 competition frame <name>. Each of these has a dedicated purpose and will function in a specific subset of our flight route.

PX5

The PX5 Will be set as a real time backup, as well as potentially act as a sensor readout. does the px5 need to be placed in the middle of the airframe for inertial computation to work? It has 3 imus, 2 temperature calibrated barometers, and will run it’s own sensor fusion algorithms and can act as a backup source of information for position, and a primary source of altitude information.

When the PX5 is acting as a real-time backup, the PX5 will be communicating to and from ZP using 3 PPM wires. 1 PPM will be from ZP → PX5, acting as 8 controller inputs, while 2 PPM will be from PX5 → ZP, acting as direct motor outputs. This retains ZPin control of communicatinos and other functions of the drone, but allows for failsafe in case of a compute error inside of ZeroPilots own attitude management system. The PPM from PX5 will either be encoded directly onboard, or the PM outputs from px5 will be converted externally by PWM → PPM converters.

Communication with barometer data may occur over a serial link such as UART, depending on UART availability on ZP.

The communication to ZP will include the following:

  • arm/disarm signal (arming before we takeoff for no errors)

  • output enable/disable signal (so that ardupilot doesn’t freak out)

  • 4 channels of input request of where to fly to (ardupilot will fly in GPS mode).

  • 1 channel configuration plane/quad/hybrid

  • 1 channel autoland/takeoff/cruise.

Jetson TX2

The Jetson will handle geolocation of landing pads, as well as the final landing-approach sequence. ZP will request information from the Jetson when ZP is ready to begin the landing sequence, and Jetson will return data on which direction to fly in. Inertial flight < 1s closed loop should be possible with centimeter accuracy. Thus, the Jetson handles the search pattern for the landing pad, as well as the process of centering the drone over the landing pad. Once landing has begun, ZP will no longer request data from the Jetson.

ZP

ZeroPilot will handle all of the inter-computer communications, as well as the air-ground communications, path planning for flying through waypoints, attitude management, as well as gathering sensor information and relaying that to other components. It is the primary driver of everything on the drone.

Flight Stages

We can break the autonomous flight modes down into: Boot, Disarmed, Ground Ops, Takeoff, Cruise, Search, Landing, Operator Override. In each of these modes, the software will interact differently to accomplish the tasks that it wants. It is important to note that at competition, the drone should be able to go from boot → ground ops with user input (physical drone arm, controller arm, software arm), and then it should be able to fly autonomously for the rest of the competition (including going between ground ops and flight).

Operator Override: This is the only mode where user inputs will translate directly to the motion of the drone. In all other modes, switches & buttons from the user may configure the drone to move to certain locations, but operator override gives the pilot the opportunity to control the control surfaces & attitude of the drone directly.

Boot

During the boot sequence, all sensors should be initialized & calibrated if required. connection between GS ↔︎ Drone should be initialized and confirmed. Any errors should be detected during this sequence and dealt with accordingly. This stage should be able to be reached using a comms emulator. The drone may need to be power cycled when going from comms emulator to rf comms. Comms emulator should verify all systems OK, and allow us to run certain diagnostic tests while on the ground (orientation, sensors, gps, etc).

Disarmed

In this mode, ALL components are disarmed. This means the drone is disarmed, the controller is disarmed, and the GS_SW is disarmed. All three must become armed for us to move out of disarmed move.

In this state, all systems should be in low power mode in order to prevent overheating. To arm the drone, the following process should be followed:

  • Arm the hardware. During this step, the hardware will ensure that everything is proper and the drone is fit for takeoff

  • Arm the controller. During this step, the pilot & flight crew should verify that they are ready for takeoff & flight.

  • Arm the software. During this step, the software should be checking to make sure that necessary links are established and ready to kick into effect.

Once all conditions are met, the drone will go into ground ops.

Ground Ops

This is a mode where the drone is armed, the props are unable to spin (for safety) and systems can be in a high power mode. No arming is necessary to leave ground ops mode - it is purely a software distinction between being on the ground and in the air. It can let as accomplish things such as hot swapping batteries, landing & loading passengers (by lighting up the PAX ABOARD) light, etc. We leave this here so that there can be future expansion as well.

User Flight Mode: Operator Override

At any point, the remote pilot can override the system and control the drone in GPS, LEVEL, or ACRO (if the quad is in fixed wing mode).

Autonomous flight mode: Takeoff

Once the takeoff command is given, ZPSW or the PX5 will take the drone from the ground to a steady height in the air. The drone will hover in the air until it receives the ACK signal from GSSW saying that telemetry & vtx are OK (making sure that tracking antennas are working). Once it receives the ACK Signal, the drone will return ACK_Confirm wait for GS_SW to send a list of waypoints and then enter into cruise mode. Takeoff mode is purely ZP based. We expect GS_SW to send a list of waypoints before we liftoff from the ground.

Should an error occur during takeoff, the drone will land itself. Should an error occur when the drone is in the air, user override can be provided to bring it into cruise if desired, or the drone will land itself within 2 minutes. is this a reasonable amount of time to debug?

Autonomous flight mode: Cruise

During cruise, the drone will continually send back healthcheck, telemetry, and position data. In cruise mode, the primary decision makers are ZP & GS_SW. Should a re-route be needed, GS will send the remaining waypoints for the rest of the route, with waypoint [0] being the current position of the drone.

Waypoints

A waypoint is a GPS coordinate paired with an ID number. The ID Number describes the sequence in which the drone is to fly waypoints. ZP will string together all the waypoints to create a flight path, where the final waypoint is the “hover” point and the transition to Search mode.

GS will send updated waypoints for the remainder of the route on a reroute, with waypoint ID=0 being the current position of the drone. This means that on a missed communication cycle, or on an updated diversion response, ZP will be able to dynamically re-route from the last known position of the drone to the next target waypoint without missing a waypoint since it can understand which waypoints it wants to hit and which waypoints it wants to skip.

Telemetry Data

Telemetry data consists of:

  • motor % values

  • Setpoints from the controller

  • current flight plan

  • attitude

  • battery voltages

  • sensor readouts

  • Mihir Gupta anything else?

GPS mode

The operator can override GS_SW to send a new list of waypoints for a custom route. ZP continues to directly pilot the drone in this mode. Once the drone reaches the final waypoint, it transitions to Search mode as normal.

Autonomous flight mode: Search

When ZP has arrived at the last waypoint and there are no remaining waypoints to travel to, ZP will request from the Jetson where to go. During the flight, the Jetson will be continually receiving position packets from ZP, and so it should be able to correlate known landing pad locations to waypoints as we fly over them. At the final waypoint, the Jetson will either direct ZP in a relative direction (e.g. 4m forward, 2m left) if it sees the landing pad, or it will build a spiral search pattern and direct ZP’s movement until it can see the landing pad.

All direction commands sent to ZP are identical and include any direction in 3D space. The Jetson is responsible of keeping track of what general locations have been swept over using the position data, which includes altitude from the barometer.

Autonomous flight mode: Landing

Once the Jetson determines a suitable landing location, it will direct the drone to be centered above the landing pad and then drop the altitude to 2m above the landing pad in a controlled descent. At that point, if Jetson sends a message to ZP acknowledging the position is good to land, ZP will use a variety of sensor fusion algorithms & the optical flow sensor to descend vertically onto the pad .using a velocity controlled curve? Gordon Fountain (Deactivated)

Flight Control Modes

There will be a few distinct flight modes, each of which handles a portion of the flight. In each flight mode, the drone will process the controls differently.

GPS

GPS mode means that the drone will fly to a position that you specify. This can either be a GPS coordinate, or it could be relative coordinates that the drone well then rest at. This is how waypoints will be handled, and this is likely how most of the flight will be conducted.

LEVEL

LEVEL Mode means that the drone will self stabilize, but it will continue flying in the direction that you specify. Generally, this means that stick inputs will translate directly into a correspondent angle on the aircraft. This is likely how pilot manual flying will work.

ACRO

ACRO mode means that the controls control rate of rotation. It is unlikely that we will ever need to use this mode with a quadcopter, but it is possible that we will use this mode when doing an emergency takeover of a fixed wing aircraft to put it into a glide slope.

Communication

Communication between all devices will follow a standardized message format over UART (or serial) with a custom payload (so that is, retaining the regular UART start, parity, stop bits). See [UART] for more information.

Communication message formats are TBD. Neha Srivastava Mika Shaw

Communication Message Formats

Message Type (Bits)

[message name] description

Expected Uses

0001

[position] Position only data

GSPC → Tracking Towers

ZP → Jetson

0010

[waypoints] Full List of waypoints

GSPC → ZP

0011

[Telemetry] Full telemetry struct

ZP → GSPC

0100

[movement request] Relational movement request

ZP → Jetson

0101

[movement command] Relational movement command

Jetson → ZP

Datatype Structs

0001 - Position Only Data Mostafa Hussein 

// could this just be the LOS_Pos struct?

0010 - Full List of Waypoints

struct TelemWaypointData {    
  double longitude; // 8 byte   
  double lattiude; // 8 byte   
  uint8_t waypoint_id; // 1 byte
};
typedef struct CommandsFromTM{
    bool start_landing; // 1 byte
    uint8_t num_waypoints; // 1 byte
    TelemWaypointData waypoints[num_waypoints];
} CommandsFromTM;

0011 - Full Telemetry Struct Mihir Gupta 

// No clue what we include in telemetry

0100 - Relational Movement Request

struct ZpToJetsonLandingRequest {
  uint8_t request;
}

0101 - Relational Movement Command

struct JetsonToZpMovementCommand {
  float x;
  float y;
  float z;
  float heading;
}

Logging on ZP

Logging will be done using an SD card. It will either be on an SPI-Based carrier board or using SDMMC on the L5 pins directly. The former will be used if we fly on a nucleo, the latter will be used if we fly on zp.

Stanley Tang maybe add some more info on how logging might work?

Logging on Jetson

Log data on the Jetson will be recorded to the SD card containing the operating system.

🚀 Deployment Milestones

Fall 2022

  • ZP flying on ACRO mode fixed wing & LEVEL mode quad

  • ZP communicating with ground fully

  • Sensors ready to work

  • !?!?!?!?!??!?!?!

  • Nov 28: initial frame delivery & initial software delivery

  • Dec 20: See software-hardware integration, put in orders for everything that we will need for the next 4 months.

Winter 2023

  • Systems Integration Begins MID JANUARY

  • Competition Mock Flight MID FEBRUARY (maybe reading week or smth)

    • this is a hard deadline for software/hardware to be finalized. Past this point, we should stop development of new things and work on fixing / characterizing current things.

  • Multiple airframes ready mid-march

    • each airframe should be characterized and tuned. Pilots should be training on some of these models.

✅ Action Items

Action

Description

Owner

Due date

Jira ticket

1
  •  

2

🗂 References and documentation

Version Date Comment
Current Version (v. 27) 2022-11-06 01:21 R D
v. 67 2023-07-05 20:20 Amy Hu
v. 66 2023-04-07 01:07 Jack Greenwood
v. 65 2023-04-04 03:45 Jack Greenwood
v. 64 2023-04-04 03:31 Jack Greenwood
v. 63 2023-04-02 04:19 Ethan Abraham
v. 62 2023-03-27 23:57 Daniel Puratich
v. 61 2023-03-26 01:08 Anthony Luo
v. 60 2023-03-24 12:31 Anthony Luo
v. 59 2023-03-24 12:27 Anthony Luo
v. 58 2023-03-23 00:59 Anthony Luo
v. 57 2023-03-22 20:42 Anthony Luo
v. 56 2023-03-14 14:34 Anthony Luo
v. 55 2023-03-13 00:15 Anthony Luo
v. 54 2023-03-08 00:40 Anonymous
v. 53 2023-02-16 17:15 Daniel Puratich
v. 52 2023-02-16 14:55 Daniel Puratich
v. 51 2023-02-16 14:49 Daniel Puratich
v. 50 2023-02-15 19:14 R D
v. 49 2023-02-15 19:13 R D
v. 48 2023-02-15 19:08 R D
v. 47 2023-02-11 01:36 Anthony Luo
v. 46 2023-02-11 01:35 Anthony Luo
v. 45 2023-02-10 02:27 Anthony Luo
v. 44 2023-02-07 23:11 Anthony Luo
v. 43 2023-02-06 23:10 Anthony Luo
v. 42 2023-01-23 23:29 Anthony Luo
v. 41 2022-12-02 15:14 Anthony Luo
v. 40 2022-11-27 16:26 Anthony Luo
v. 39 2022-11-14 15:17 Anthony Luo
v. 38 2022-11-10 03:46 R D
v. 37 2022-11-08 03:09 Megan Spee
v. 36 2022-11-07 14:18 Anthony Luo
v. 35 2022-11-07 14:15 Anthony Luo
v. 34 2022-11-07 14:14 Anthony Luo
v. 33 2022-11-07 13:18 Anthony Luo
v. 32 2022-11-07 03:42 Megan Spee
v. 31 2022-11-06 05:21 Megan Spee
v. 30 2022-11-06 04:52 Anthony Luo
v. 29 2022-11-06 01:56 Anthony Luo
v. 28 2022-11-06 01:55 R D
v. 27 2022-11-06 01:21 R D
v. 26 2022-11-05 21:12 Anthony Luo
v. 25 2022-11-05 20:50 Anthony Luo
v. 24 2022-11-05 20:29 Sahil Kale
v. 23 2022-11-05 19:38 Anthony Luo
v. 22 2022-11-05 05:32 Neha Srivastava
v. 21 2022-11-05 04:37 R D
v. 20 2022-11-04 05:26 R D
v. 19 2022-11-04 05:25 R D
v. 18 2022-11-04 04:21 Anthony Luo
v. 17 2022-11-04 04:14 R D
v. 16 2022-11-04 01:43 Mika Shaw
v. 15 2022-11-04 00:38 R D
v. 14 2022-11-03 22:10 Anthony Luo
v. 13 2022-11-03 13:12 Anthony Luo
v. 12 2022-11-03 12:43 Yuchen Lin
v. 11 2022-11-03 12:40 Yuchen Lin
v. 10 2022-11-03 03:26 Anthony Luo
v. 9 2022-11-03 00:48 Nathan Green
v. 8 2022-11-03 00:42 Anthony Luo
v. 7 2022-11-03 00:38 Anthony Luo
v. 6 2022-11-03 00:21 Anthony Luo
v. 5 2022-11-03 00:20 Anthony Luo
v. 4 2022-11-03 00:19 Anthony Luo
v. 3 2022-11-03 00:15 Anthony Luo
v. 2 2022-11-03 00:15 Anthony Luo
v. 1 2022-10-21 15:26 Anthony Luo
  • No labels