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 3 Next »

Date

Participants

Discussion topics

Admin: 

  • Contacted David Friday, awaiting response

    • Next steps may to be contact Teerstra or D Wright

    • Fall term… is TBD. Waiting on UW status - will the bay be open?

  • Sent one message to Mark through...messenger :o, probably - he said “hey hows coop”

  • RECRUITS

    • 1 Mech, 2 FW, 1 CV - currently sent to bootcamps

    • FW, HW, and Mech one are all relatively okay

    • CV should not be run - direct CV people to OpenCV and potentially help new recruits set it up - OpenCV has a large barrier due to language barrier/no guidance

    • Will eventually need to find a solution for building a CV team/person since CV is pretty essential for USC (previous years used human vision)

    • Should update documentation/slack to let people know CV is not super ready

Autopilot:

  • PICPilot Path management can be mostly ported over

    • Issue: single-threaded, which made it really messy and hard to follow

  • FreeRTOS should be used to create separate threads

    • Have a particular fn (function), assign a thread to that fn w/ infinite while loop

    • Issue: Cannot run FreeRTOS on PC

    • Should be able to unit test each individual thread - abstract everything into higher level fns and test those higher lvl fns. FreeRTOS should provide stubs to those fns

  • Initial Idea: 2 threads for state machine (Attitude/Path), 1 thread for managing coms, subthreads for each sensor

    • Sensor thread will update its results automatically

    • Only thing to worry abt is data syncing

    • Another thread for managing the coms

    • Ex: GPS thread fires off every 100 ms, IMU fires off every __ ms

  • Telemetry thread:

    • Downlink/Uplink thread? 

    • Could pick up Battery voltage/current measurements

    • PICPilot telemetry code is one of the more complicated ones - avoid heap allocations on an embedded system

    • MavLink option: Use standardized protocol so that anything can act as Grounstation. Would require changes to the way data is packaged.

  • SensorInterface:

    • Have sensor status report back to groundstation on bootup so that everything is working before flying

    • Sensor struct should include timestamp field to determine how new data is - or include sensor cound

  • For future debugging:

  • Unit Testing:

    • Works on MAC, Linux, Window subsystem for Linux 

    • Getting it to run on Windows could make it more accessible for future recruits

    • Get TRAVIS to run everything on Windows as well

Action items

  • WILL BE ON ASANA: List sensors needed - begin writing header files (ideally C++) 

    • Sensor class that returns a result struct (sensor status, timestamp, etc.)

    • GPS, IMU, Airspeed, Altimeter, (possible) Ultrasonic, Battery Voltage/Current

    • Add sensor PN/Datasheet link to header file :)

    • Keep sensor classes/fns generic (ex: IMU) and create subclasses for specific sensor (ex: IMU_PartNumber)

    • In header file: list which sensor PN are supported and how to select a sensor PN

  • Wait for David’s reply
  • Hide CV Bootcamp + inform interested CV recruits that there are on their own
  • Update design architecture docs - upload them onto Confluence
  • Push Unit Test framework to devel branch
  • No labels