Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  • 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

...

  • 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