Week three of the GSoC 2015 BeagleSat project, a future CubeSat development platform.
Worked on:
Issues:
To be worked on:
Week four is upon us, more stuff has been done, more stuff to be done.
Finished the 2D correction algorithm in MATLAB, more about that here.
Worked on:
Issues:
To be worked on:
Midterm checkpoint on Friday. Finished checking the 2D fitting and got halfway through with 3D fitting. Unfortunately, it seems that a (realistically to long) set of non-linear equations that need to be solved symbolically to compute the conversion factors is to big of a bite for MATLAB to chew in any reasonable amount of time. Until I figure out a solution to the solver, alternatives are being researched.
Worked on:
Issues:
To be worked on:
While I thinker with a solution to my last week’s equation problem, I started working on the API design and how to put all the work in a Linux Kernel module. After failing miserably at my first attempt, I revisited my bookmarked library and found this brilliant guide to LKMs on the BeagleBone Black.
Now I just have to go from a piece of paper with my requirements to some runnable kernel code.
Worked on
Issues:
To be worked on:
Well, writing your own API is fun, after you finish a week long marathon on reading how not to screw it up. I’m at the finishing part, and starting to put it into code. Heeding all the warning on how not to screw it up, hopefully.
Worked on
Issues:
To be worked on:
Finally got some code up on GitHub, set up the proper Makefile structure to make building Doxygen documentation as easy as invoking “make doxy”. Next stop, expanding the API header to some real-life usable code. Added a LKM module to start testing sysfs interfacing next week.
Worked on
Issues:
To be worked on:
Last week’s discussion left an impression that things weren’t going fast enough while tackling the API, LKM and all other parts of the project at once. After talking to my mentors, we decided for a quicker approach to the development cycle and that means switching to a faster animal, or should I say snake.
C is the end goal for stability and portability, but for the prototyping phase Python is king.
Worked on
Issues:
To be worked on:
Last week was an interesting roller-coaster of reading documentation on and around the InvenSense MPU9250 9DOF sensor to patch up the PyBBIO driver to be fully featured. It’s practically there, but the documentation was less than helpful. Onwards to the Python API.
Worked on
Issues:
To be worked on:
The Python API got it’s basic structure and will be nearing completion before the weekend, the PyBBIO library driver for MPU9250 is feature-complete and ready for integration into PyBBIO. Next steps, integrate the solver and start documenting everything everywhere!
Worked on
Issues:
To be worked on:
Found an adequate solution to the solver using Python. The inspiration came from a blogpost for a similar ellipsoid fitting optimization. It’s gonna need a bit of fixing to work more like the Octave setup I have now, but that shouldn’t be a problem.
Next up, write ALL the documentation!
Worked on
Issues:
To be worked on: