[GSOC 2015] BeagleSat Progress Report W#1

[visnji...@gmail.com]

Greetings everyone,

Digest for the first week of GSoC 2015 coding for the BeagleSat project.

Worked on:

• Hardware setup and configuration
• Basic readouts of MPU9250 via SPI
• Testing currently available drivers and available code
• Looking into what can be reused and what should be redone
• Final touches on the presentation + Intro video (awaiting upload when the VPN is stable)
• Blog space ready for tracking progress
• Received the PNI RM3100 modules via Fedex

Issues:

• The Great Firewall of China (see intro video above)
• Hackaday.io page still pending

To be worked on:

• Getting a cohesive setup for the sensors
• Interfacing with the PNI RM3100 magnetometers
• Looking into the parameter computation ML algorithms (and how to optimally implement them in the coming weeks)
• PRU viability will be considered
• Hackaday.io page + more blogging

Thanks, 

Niko

[visnji...@gmail.com]

Hi everyone,

Second week of GSoC 2015 coding for the BeagleSat project.

Worked on:

• Hardware setup mostly done
• Finished layout graphic and added it to video and some other minor edits
• Readouts from PNI RM3100 via SPI working, more testing this week
• Writing code for both sensors to measure and store a workable amount of data for ML estimator

Issues:

• Advice anyone: Recommendations for C/C++ ML library (or any optimized computational library for minimizations), links are awesome to 
• Finals week, eg. a lot of distractions
• Uploading video to Youtube, if it doesn't work until tomorrow, I'll upload it via non google services or send it to someone

To be worked on:

• Drivers and data collector code for the sensors
• ML stuff, have to start implementing it (test with Octave, later implement in C++)
• Hackaday.io page + more blogging (still a bit to do)

Cheers, 

Niko

[Niko Visnjic]

Forgot to link to last week's update.
It lives here: http://nvisnjic.com/2015/06/16/gsoc-update-week3.html

C/P from the link:

Week three of the GSoC 2015 BeagleSat project, a future CubeSat development platform.

Worked on:

• Video is up! –> https://youtu.be/ojDqtxv9oGY
• Website just about done. –> http://nvisnjic.com/beaglesat
• Got both sensors working and polling data into files (testing only)
• Started with Octave code for parameter estimator

Issues:

• Soon to begin testing data in Octave. A possible issue is that the data should come from rotating the sensor around a stable axis, which would require building an apparatus to hold the sensors while rotating in a stable orbit. If it turns out to be a blocker, I’ll look into 3D printing such a device and rigging it to the BeagleBone
• Last weeks ML library issue should be a non issue, I’ll use a matrix computation library when porting the code to C++, it should suffice

To be worked on:

• Currently using SPIDEV for the data, transfer to drivers later in the project
• More Octave stuff in the coming week
• Hackaday.io page soon

[Niko Visnjic]

This week's update (C/P from blog)

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:

• 2D Correction algorithm in MATLAB, works like a charm
• Parameter estimator is very fast locally, will be porting to Octave to test execution speed on the BeagleBone
• Parameter estimation on simulated data yields less than 1% error on all deformations except rotation (rotation is variable in error, but less than 2%)

Issues:

• Research was helpful, but the algorithm part could have been a bit more elaborate
• Octave was super uncooperative with the symbolic toolbox, have to look i into that and move the MATLAB code to Octave (go team open-source!)
• Sensor testing complexity still unknown (last week’s issue), will be testing in the coming weeks

To be worked on:

• Expanding the 2D correction algorithm to a 3-axis one
• Adding time-variant error compensation using telemetry and additional inputs
• Currently using SPIDEV for the data readouts, transfer to proper drivers later in the project

[Niko Visnjic]

Weekly progress up at: http://nvisnjic.com/2015/06/30/gsoc-update-week5.html

Pasting for the no-links crowd :)
______________________________

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:

• 2D Correction algorithm in MATLAB, scales properly now for different field magnitude measures
• Moved both to Octave so I can test on the BBB
• 2D Octave code is quite fast on BeagleBone (~0.022s for 500 point dataset)
• 3D Octave code working, adapted from Yury’s fitting algorithm (~ 0.081s for 512 point dataset)
• Fitting code: https://github.com/nvisnjic/BeagleSat

Issues:

• Haven’t figure out yet how to get rotational matrix from the eigenvector output, scaling and centering works fine
• Solving the non-linear equations to convert from intermediate linear terms to correction parameters (rot, trans, scale) for the data proved to be impossible/takes too long; used Yury’s method for now

To be worked on:

• Solving parameter EQs with a different method
• Figure out the eigenvector rotation matrix

• Adding time-variant error compensation using telemetry and additional inputs

• Testing on real measurements (2D case ready; 3D should work as well)
• Framework design & overall systems design

[Niko Visnjic]

Weekly progress report -> http://nvisnjic.com/2015/07/07/gsoc-update-week6.html

C/P from post: 

__________________________

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

• Educating myself on sysfs and Linux Kernel Module programming
• Requirements and API design (and still working on it)

Issues:

• Tried writing an overall design and it wasn’t looking quite good, went back to read a bit on sysfs and LKMs
• Yury’s method works extremely well; still have to figure out how to get a rotation matrix from eigenvector output
• Solving the non-linear equations is currently on hold; Mathematica is a possible solution

To be worked on:

• Write API header from requirements
• Overall systems design (and put it on a graph)
• Choose a sysfs structure, start writing the kernel module

• Figure out the eigenvector rotation matrix

Cheers,

Niko

[Niko Visnjic]

Last weeks report (forgot to post it here) -> http://nvisnjic.com/2015/07/16/gsoc-update-week7.html

Summary:

__________________________

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

• More API design reading, mostly done
• Had a hangout with S. Arnold and Alexander H. about the API, got some good insights from them

Issues:

• Yury’s method works extremely well; still have to figure out how to get a rotation matrix from eigenvector output

• Solving the non-linear equations is currently on hold; Mathematica is a possible solution (working on it!)
• Running around Hong Kong too much, should be done soon

To be worked on:

• Writing the API, finally
• Overall systems design (and put it on a graph?)
• Figure out the eigenvector rotation matrix / or work out the solutions through Mathematica

Cheers,

Niko

[Niko Visnjic]

This week's report -> http://nvisnjic.com/2015/07/21/gsoc-update-week8.html

Summary:

__________________________

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

• API code, more to come
• Uploaded a basic input-output Linux kernel module, works fine for ints, have to fix cflags to get floating point in the code

Issues:

• Had trouble compiling floating point into kernel code. Tried -mhard-float got “gcc: error: -msoft-float and -mhard_float may not be used together”, tried more focused flags, and compiled a program that optimizes out sscanf()’s format to a static string. GCC not being nice.

• Solving the non-linear equations is currently on hold; Mathematica is a possible solution (working on it!)

To be worked on:

• (Much) more work on the API, got to fix stuff
• Fix the floating point thing in the LKM
• Improve LKM processing stage; add an interrupt driven processing step, with an extra enable sysfs flag or something similar

• Overall systems design (and put it on a graph?)
• Figure out the eigenvector rotation matrix

Cheers,

Niko

[Niko Visnjic]

Website page -> http://nvisnjic.com/2015/07/29/gsoc-update-week9.html

C/P:

_________________________

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

• Transferring stuff to Python
• Wrote a PyBBIO library to communicate with the MPU9250 -> code
• Noticed a second library is using the same data correction (based on Yury’s, but without the time variant part) as I do, going to be looking into the code over the next week

Issues:

• The AK8963 magnetometer sandwiched with the MPU9250 was a royal PITA to interface with via SPI (but it works now!), -1 for elaborate datasheets missing important info
• Solver for the equations? (Candidate solutions: Mathematica, expand on Yury’s work, or something third)

To be worked on:

• Add self-test functions to the MPU9250 library and other corrections so it fits nicely with PyBBIO
• Transfer API for data processing control
• Solve the solver and connect to data input in Python

Cheers,

[Niko Visnjic]

Online report -> http://nvisnjic.com/2015/08/05/gsoc-update-week10.html


C/P
_____________________

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

• Transferring stuff to Python
• Added last couple of functions needed for a full featured MPU9250 PyBBIO library code here
• Self-test works good, range setup and magnetometer all green
• Gyro and accelerometer calibration has some issues still
• Noticed the on-board AK8963 can work at 100Hz (!!!) without an issue

Issues:

• Also noticed the InvenSense documentation is beyond horrible
• Solver for the equations? Still need a fix

To be worked on:

• Patch up the remaining bugs in the MPU9250 library
• Python API
• Implement solver and connect to data input in Python

[Niko Visnjic]

Online version -> http://nvisnjic.com/2015/08/12/gsoc-update-week11.html


C/P from website
_______________________

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

• The MPU9250 driver is completed and documented, ready for general usage, code available here
• Added all the bells and whistles needed for the MPU9250 to work like a charm
• Python API structure is set up, now to finish the helper functions

Issues:

• A bug with the MPU9250 occurs only on full register reset, tried getting to the bottom of it but to no avail. It doesn’t influence the current code functionality though, will work on that one after GSoC.
• Solver for the equations? Working on that this week and integrating into Python code

To be worked on:

• Finish the Python API
• Integrate solver into Python, either via NumPy or through Matlab code (other suggestions?)
• Documentation and examples

[Niko Visnjic]

Website link -> http://nvisnjic.com/2015/08/19/gsoc-update-week12.html


Summary:
__________________________

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

• Found a proper solution to the ellipsoid fitting in Python.
• Needs a bit of fixing, but will be up and running in a couple of hours.
• Plotting the fitted data in a nice example program.

Issues:

• Good news, I found out what’s happening under the hood in the eig() function in MATLAB. Partially bad news, it’s pre-compiled FORTRAN.
• Since Python’s NumPy library uses the same solver underneath, will just go with that for now.
• Well, 48 hours a day would be nice, but probably still not enough.

To be worked on:

• Patch up the solver, and integrate it into the code.
• Split it up into a proper Python package.
• Document everything!

[Vladimir Pantelic]

copied from the website
(http://nvisnjic.com/2015/08/26/gsoc-final-update.html)

-------------------------------------------------------

GSOC Final update

Aug 26, 2015
Google Summer of Code comes to an end.

Let’s make a rundown of what has been done and what lies ahead.

The BeagleSat project has set out with the goal of simplifying small
satellite construction to a level that is approachable by anyone willing
to hack together a compact embedded system. Be they academics or
aspiring high schoolers, students or teachers, the goal is to make
something as complicated as satellite design available to individuals or
groups willing to invest the time to build them. Leveraging
open-software and open-hardware to make this process affordable and
reproducible for people around the world.

The platform is here to provide a basic set of tools and functions to
facilitate this process. Based on work from NASA, ESA and a multitude of
researchers to develop state of the art tools, for the best price there
is. Free as in Speech.

During this GSoC we’ve been focusing on the first phase of the project,
that is, developing the tools needed to get clean magnetic measurements
from a compact satellite without the local interference usually
accompanying such cost saving designs, developing software to interface
with magnetometers and IMUs and building an API for easy access to
functions developed in this design. A big part of phase one was
completed, but there is still a lot to be done going forward.

What has been accomplished during this Google Summer of Code:

Researching and testing data fitting algorithms in MATLAB/Octave and
demonstrating that they can run in real-time on the BeagleBone Black
Developing a feature complete software set to interface with the MPU9250
sensor using the PyBBIO library in Python
Converting the time invariant fitting algorithm to Python and optimizing
execution time using the linalg package
Making a BeagleSat API Python package to lower the barrier for accessing
tools in the PyBBIO and data fitting sub-modules
Testing and documenting examples for processing data in all stages of
the acquisition/processing/storing pipeline
Data visualizer for user feedback during data collection and correction
Items to be completed after Google Summer of Code:

Test code for the time invariant algorithm in Python
Continue development on the Linux kernel module and move processing into C
Test all fitting algorithms in a magnetically controlled environment and
simplify further testing
Expand the BeagleSat API and documentation as needed
All these items will be done in the near future, before moving on to
phases two and three. That’s the summary, though keep a close eye on the
project GitHub page

My biggest thanks go to my mentors, Steve Arnold, for giving me an
extremely challenging project to tackle during this summer (and beyond),
and Alexander Hiam, for keeping me running straight when focus was
needed, and to both of them for bearing with me when commits were slow.
Many thanks to all the swell members of the BeagleBoard community for
their much appreciated help and support. Finally, a big thank you to
BeagleBoard.org and Google for sponsoring this amazing Summer of Code.

While it was an astonishing program, through which 3 months of coding
have passed by faster then a summer breeze, the BeagleSat project that
was started during these eleven weeks has a long and probably bright
future ahead.

Cheers,

Niko

On 08/19/2015 04:34 PM, Niko Visnjic wrote:
> Website link -> http://nvisnjic.com/2015/08/19/gsoc-update-week12.html
>
>
> Summary:
> __________________________
>
> Found an adequate solution to the solver using Python. The inspiration
> came from a blogpost

> <http://www.varesano.net/blog/fabio/ellipsoid-sphere-optimization-using-numpy-and-linalg>

> 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/
>
> * Found a proper solution to the ellipsoid fitting in Python.
> * Needs a bit of fixing, but will be up and running in a couple of hours.
> * Plotting the fitted data in a nice example program.
>
> /Issues:/
>
> * Good news, I found out what’s happening under the hood in the eig()

> function in MATLAB. Partially bad news, it’s pre-compiled FORTRAN.

> * Since Python’s NumPy library uses the same solver underneath, will

> just go with that for now.

> * Well, 48 hours a day would be nice, but probably still not enough.
>
> /To be worked on:/
>
> * Patch up the solver, and integrate it into the code.
> * Split it up into a proper Python package.
> * Document everything!
>
>
>
> --
> You received this message because you are subscribed to the Google
> Groups "BeagleBoard GSoC" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to beagleboard-gs...@googlegroups.com
> <mailto:beagleboard-gs...@googlegroups.com>.
> For more options, visit https://groups.google.com/d/optout.