September 5, 2022 - Software Task Sync Up

Attendants

  • Austin

  • Orson

  • Chan

  • Keyon

Agenda

  • Review and discuss status of ongoing projects

  • Plan out and scope future SW tasks for end of comp

  • Discuss recruitment efforts


Ongoing Projects

  • Fix CI/CD on GitHub

    • not important for overview

  • Review, then merge all finished-but-unmerged PRs (Keyon arm-ros-gazebo-control, Orson arm-control)

    • administrative code reviews

  • Revamp software training

    • keyon wanting to look into revising software training

    • currently there is a barrier to entry to new team members (roughly 4 mo. committed to just doing training)

    • start identifying good new member tasks that are light on ros to keep people engaged as they work through training. ensure that ros heavy tasks are still restricted from members who have not fully completed training + some smaller tasks

  • Install SSD onto Jetson upon arrival

    • no discussion required

  • Test jetson running (builds run fine, but try running the drivetrain launch file)

    • need to confirm if keyon has tried this, but we have a fully working jetson with jetpack 5 (ros2 stable currently)

  • Convert SW Assemblies to high fidelity URDFs

    • for mech team to do at some point

  • Set up CAN interface for drivetrain

    • On softwares side - one type of communication protocols required to send and receive messages from a motor/actuator (firmware also uses I2C and SPI)

    • specifically this is required to send commands to drivetrain. CAN bus is used to package and transfer commands from the jetson to the firmware team. firmware team will take this information (joint velocity/position commands, etc), they will interpret it and send it to the motors.

  • Test ROS/Nucleo integration over CAN

    • the actual can interface is the same as the one being worked on for “drivetrain”; its just one CAN interface

    • need to sync with jahnavi to know if there are any active plans to continue with the nucleo integration

  • Set up xbox controller to control the drivetrain

    • easy checklist item

      • good for new members, little ROS experience required

      • M3 but can be done earlier given proper resource allocation

  • Create cartesian arm controller

    • recently launched project - going to be quite the undertaking

    • required for more experienced members

    • first step is to understand all of our transforms and coordinate system planes

    • open ended question - is it worth getting a 6axis sim up and running just to test controls(revisit later)

  • Define homing sequence for arm joints

    • safety sequence to make sure each joint doesnt bypass physical limits

    • important for testing controls on fully assembled arm

  • Set up physical controller for arm

    • important for testing arm

    • lots of work we have to do for physical controller selection first

  • Set up CAN Interface for the arm

    • same as the DT CAN interface (its universal)

  • Build URDF for science module with ros2_control

    • this is potentially important

      • FIRST need to figure out required fidelity of control, a URDF may not be required

  • RVIZ And Gazebo

    • Need to revisit if these are actually relevant

  • Interface with and receive video footage from DinoLite microscope camera

    • Need to revisit this . Might require complexity if we cannot interface with Linux the jetson (drivers dont work)

    • may need a micro computer connected to the dinolite camera

    • most important to see if this is compatible with linux first

    • for arm wrist camera, make sure we pick a nice linux compatible camera

  • Camera Package (URDF / Gazebo / RVIZ)

    • need to revisit this to justify if a URDF is required

  • Autonomy

    • all groundwork should be done this term (planning autonomy flowchart, setting up ZED2 feed)

    • goal for this term is also to have an articulated table mounted gimbal for QR code identification, and a scanning procedure

  • Comms work

    • All very important, but nothing that can be independently started before comms shit gets running

    • Identify, publish and store rover's GPS coordinates - need to look into localization and actual requirements