• Battery system updates and demoed

    Jacob Killelea04/18/2020 at 22:09 0 comments

    This is is the general setup for the battery system. I switched ICs, and I'm using the NCP1421 from ON Semi. It's tiny, and this was my first time working with 0603 caps and resistors, but things turned out great once I had all the connections solid. I used longer wires from the battery IC the first few times and it caused problems with peak current draw somehow. Anyways, it's great to see it booted! The screen is an ST7735 based LCD, and I had no idea it had kernel modules already available until after I bought it. It's pretty funny to see the boot messages so truncated.

    Here's the schematic of the voltage booster board. I'm liking this chip a lot and it'll almost certainly make it into the final design.

    The next step is going to be to get everything put together onto a breadboard so that I can start integrating it with the software, and maybe 3d print a case.

  • I think I've got the battery system worked out.

    Jacob Killelea11/02/2019 at 05:16 0 comments

    Here's the schematic currently. No display yet, but you'll see that the upper left corner includes a USB header, a boost converter, and a P-MOSFET for selecting between them. I took this design from an Adafruit Feather board (credit where credit is due), so hopefully it'll work. I haven't tested it yet, since I don't have a P-MOSFET with a low enough Rds. Another problem: The boost converter I selected is a pricey chip from Linear Technologies. They're $5 each - as much as my Raspberry Pi!

  • Goddard does a good job

    Jacob Killelea11/02/2019 at 05:10 0 comments

    It's been a few months, and this project hasn't quite been at the forefront of my attention. However, it's worth noting that a few months ago a merge from upstream deleted some makefiles and broke my build. At first, I was like what the hell! But after sending a message to the email attached to the particular commit that broke things, I was informed of a new CMake centered build system that Just Works on a Raspberry Pi, without my makefile hacks. Very good news indeed. URLs shall be updated accordingly.

  • More data

    Jacob Killelea09/06/2019 at 23:47 0 comments

    I'm nowhere close to having all the electronics integrated, but I took my laptop on a quick drive the other day and recorded this from the kalman filter.

    Red line is the filter track. Looks great, right? Well, here's the raw GPS data (in blue):

    Yep, same basically the same track. What does this mean? Well, I had a really good GPS signal on this drive, I think I just had great resolution. No major tracking errors. The accuracy meets everything I think I'd need for an actual bike trip, but I'd like to do better and add more bells and whistles, re-enable speed based prediction and include an accelerometer.


    In addition, the data ends early for some reason. I was recording this with a CoreFlight app, and whatever I wrote had some error, although it didn't crash anything. I've included more error checking in case this happens again, though an app crash/restart could overwrite the log files, which would be a problem.


    I'm seriously getting stuck on how to safely integrate an unprotected 18650 battery into this project though. It looks like I'll have to include separate charging, protection, and 5V regulation ICs to get the Raspberry Pi powered. I'll then send the data lines from the Raspberry Pi straight through to the charging port so that a computer can talk to the Pi while charging the battery.

    Next problem: I think I need a high-side battery protection IC now. Most of them are low-side, but the battery will still be grounded through the charging IC.

  • Kalman Filter merged into CoreFlight App, back to electronics

    Jacob Killelea08/21/2019 at 20:47 0 comments

    The source code is here, for those interested in what a CoreFlight application looks like.


    I'm only parsing the most generic message from the gps_reader application, which greatly simplifies the source code. In addition, I noticed that when the GPS loses a lock, the filter lat/lon quickly goes back to 0/0, so for now the filter isn't run unless the GPS indicates that PDOP isn't maxed out.

    Next up is going to be figuring out the power systems to make this portable. I have a bunch of unprotected 18650 batteries, but my cheap ebay electronics don't get all the power out of the batteries that they could. I need to research higher performance boost controllers and battery protection ICs. In addition, I don't want to overcharge these batteries by plugging a USB cable into the Pi and pushing current backwards though a boost controller and battery protector.

  • Matrix inverted, proof of concept in C

    Jacob Killelea07/31/2019 at 01:59 3 comments

    I finally got all the steps for a matrix inversion working in C. It hasn't been verified yet and I don't have any new data to work with, but so far things seem promising. In regards to inverting a matrix, which had me stuck for some time, the solution is apparently an LU decomposition and then an inversion:

    int signum;
    gsl_permutation *permut = gsl_permutation_calloc(DIMS);
    gsl_matrix *Scratch  = gsl_matrix_calloc(DIMS, DIMS);
    gsl_matrix *Scratch2 = gsl_matrix_calloc(DIMS, DIMS);
    
    gsl_linalg_LU_decomp(Scratch, permut, &signum);
    gsl_linalg_LU_invert(Scratch, permut, Scratch2);
    

    Currently, `Scratch` and `Scratch2` are actually statically allocated in order to reduce dynamic memory. Requires a little bit of indirection between `gsl_matrix_view` and `gsl_matrix`, but I prefer it overall.

    The new filter output is in green here, overlaid on the sensor data (blue) and the octave version of the filter (red).

    Velocity data is still not being used here, which is a big TODO. Without it, the filter is basically just a running average. I still need to collect more data to evaluate, and also integrate this filter into a CoreFlight app.

  • How the heck do you invert a matrix in C?

    Jacob Killelea07/15/2019 at 03:00 5 comments

    I've starting writing the kalman algorithm in a CoreFlight app. It receives GPS data messages from another application that handles the serial parsing, and this one is supposed to run the kalman filter.

    I've got most of it working right now, but I stuck on how to calculate the inverse of a matrix in C. I've been using the GSL library for the matrix math, since it supports BLAS functions and it makes it easy to write the code for an arbitrary matrix size, but I just can't figure out the inverse thing.

  • Kalman Filters, and so on

    Jacob Killelea07/03/2019 at 20:24 0 comments

    I decided to start on testing the sensor algorithms. I chose a kalman filter to experiment with first, mostly because it can handle a wide variety of input, and there's lots of resources online. My state vector is currently just the measurements from the GPS.

    I'm not including my actual filter computations because the current LaTeX embedding on this site is pretty janky and it was just too painful to try and write out the matrices and put them in the correct places. There's tons of resources online for kalman filters if people are curious. If they really want to look at what I'm doing, I'll try and post it.


    I took my laptop for a walk around the block, with the GPS module attached to a CP2102 USB-Serial converter, recorded the data, and put my filter over it in Octave.

    The result:


    Oof. The blue line is the GPS track, and the red is the kalman filter. The filtered data is even worse than the raw data, but neither is great. That blue thing is supposed to be a diagonal rectangle in the shape of my block. I've got no idea what's going on with that big loop in the bottom. In real life, that's gotta be at least a hundred meters in  the wrong direction.

    I decided to take velocity information out of the filter:


    Quite a bit better, but now I'm ignoring information from the sensors just to get a prettier picture.

  • Customer Requirements

    Jacob Killelea06/29/2019 at 06:16 0 comments

    I spent a few minutes today writing down my requirements for this device, as the end customer. Hopefully this will give people a better idea of what I'm thinking of, though it's still pretty generic.

    The device SHALL

    1. Mount to the handlebars of my bicycle
    2. Provide position, heading, and velocity information to TBD accuracy
    3. Be self contained and self powered
    4. Record cycling trips with TBD resolution
    5. Provide waypoint and track following information to TBD resolution
    6. Be operable while riding
    7. Have a display that is visible in direct daylight and total darkness
    8. Provide a human interface for easy configuration and data entry without an external computer or keyboard


    The device SHOULD

    1. Utilize flight software framework(s) such as CoreFlight
    2.  Utilize sensor fusion algorithms such as a Kalman filter
    3.  Be resistant to environmental factors such as temperature extremes, dirt and moisture ingress
    4.  Be removable from the bicycle without tools more complicated than a hex wrench
    5.  Be extensible with new software and peripherals