2020-05-17 Meeting notes

Date

May 17, 2020

Participants

• @Annie LePage

• @Anthony Berbari (Deactivated)

• Craig Crundwell

• @Lucy Gong (Deactivated)

• Serge Babayan

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:

  • Firmware Development Environment Setup

• 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