Anyone interested in working on an open source telemetry device?

[excellrec]

I've been working on an open-source Arduino based telemetry device so I can track speed, g-forces, brake and throttle, and etc. There are some commercial options but I haven't seen any that allow for custom interface of sensors (e.g. brake and throttle) so I decided to make my own. Also, I just like tinkering.

So far I've got a very basic unit that tracks GPS data and logs it to an SD card. Once I've sorted some more bugs out of it, I want to add a 9-axis motion sensor, throttle sensor (piggyback TPS), brake sensor (either just lever movement or maybe hydraulic pressure), and whatever else I think up.

My goal is to log data to have objective measurements to improve my riding (on or off the track), and to have fun. I don't want to commercialize, make money, etc. I'm decent at hardware development but not as much at coding Arduino (I get by with basic knowledge). If this sounds interesting to anyone and you might want to collaborate and make one too. Let me know! Picture of current prototype:

 

[Junkie]

that's a cool idea. I'd love to see it work out but don't have the skills to help.

I'm trying to figure out 9 axes: x,y,z translation, x,y,z rotation... what else?

 

[Sharxfan]

This triggered a memory. Synfinatic hope I spelled that right had a similar thread going awile ago although it wasn't an open source thing you may be able to get some info from the thread.

https://www.bayarearidersforum.com/forums/showthread.php?t=489778

 

[stangmx13]

I spent some time making one. I even added Wi-Fi so it could offload data to an iPad. In the end, it was going to be way too many man hours to get use out of it. The code needed to log data isn’t too bad. But writing another program to visualize the data well was going to be way too much work. Eventually I just bought an AIM Solo and learned to use their extensive software.

Mine was Propeller based instead of Arduino. That chip was a lot faster and had a lot more I/O. But I had to write it all in C and there was a lot fewer libraries than Arduino has now.

 

[stangmx13]

I may start a new project... a roll axis “gimbal” for a GoPro. I bought a gimbal to use for track videos and am unhappy w it’s performance. It’s too shaky and slow because it does 3-axis. Building a 1-axis stabilizer might not be too hard and should work better.

 

[synfinatic]

I've been working on an open-source Arduino based telemetry device so I can track speed, g-forces, brake and throttle, and etc. There are some commercial options but I haven't seen any that allow for custom interface of sensors (e.g. brake and throttle) so I decided to make my own. Also, I just like tinkering.

Hola!

So FYI: all commercial data loggers support custom / 3rd party sensors. Some like the GPX Pro only support analog sensors (0-5V) while others like my AIM MXL support analog (still 0-5V), digital speed pickups as well as CAN bus. AIM allows you to define your own custom CAN bus protocol decoder so you can go pretty crazy.

Anyways...

Like you, I love tinkering with all this stuff... Right now I'm working on retrofitting a Ducati Panigale front wheel speed sensor onto my 1098 front end because I recently changed rotors and no longer have the TC pickups that I once did so I can't use the 1198 TC sensor anymore. I swear that makes sense to me.

Anyways, there's a lot of cool hardware out there at various price points. Personally, I enjoy the hardware side a lot more than building the necessary software to analyze the data (also I suck at UI's). Anyways, I'd strongly suggest making sure your hardware is compatible with an existing software analysis tool. The problem is most of them are proprietary and tied to the hardware. There are a couple that I know of which aren't:

Open source project by the guys at AutoSport Labs:
https://github.com/autosportlabs/RaceCapture_App

There used to be a version of GEMS GDA which supported importing CSV files/etc. Not sure if that is still true or what it would cost:
https://gems.co.uk/products/software/gda/


Edit: Almost forgot to ask: Can you give more details on the hardware components you selected. Do you have a github repository with your code to share with others?

 

[synfinatic]

This triggered a memory. Synfinatic hope I spelled that right had a similar thread going awile ago although it wasn't an open source thing you may be able to get some info from the thread.

https://www.bayarearidersforum.com/forums/showthread.php?t=489778

Oh man... I need to work on that some more. Too many hobbies, not enough time.

 

[Sharxfan]

Oh man... I need to work on that some more. Too many hobbies, not enough time.

Tell me about it. I have been without a non-work computer for some time but I am getting a new one here soon so I am going to try and get back into learning to code and doing maker stuff.


Excell what language are you going to code in for the project?

 

[synfinatic]

Looks like an Arduino Uno clone- so I'm going to guess he's using the Arduino IDE & Processsing language (which is a subset of C++).

 

[excellrec]

Glad to see there are some like-minded folks here!

I'm trying to figure out 9 axes: x,y,z translation, x,y,z rotation... what else?

It's a combination of accelerometer, gyroscope, and magnetometer. My limited understanding is that this combination provides a more stable reading, with less drift, than 3- or 6 axis solutions. Though, there are drawbacks in any case. I have a friend who specializes in inertial movement sensing who I will meet with soon. Hopefully he can get my on the best path for this aspect of the project.

I spent some time making one. I even added Wi-Fi so it could offload data to an iPad. In the end, it was going to be way too many man hours to get use out of it. The code needed to log data isn’t too bad. But writing another program to visualize the data well was going to be way too much work. Eventually I just bought an AIM Solo and learned to use their extensive software.

Hi! I am familiar with your podcast. IIRC, you rely on the accelerometer/GPS data to infer brake/throttle application? I'm curious, do you feel this gets you what you need, or would specific brake pressure and throttle position be a bit more helpful? For example, to distinguish between engine braking/brake application, or even to monitor brake fade? Any other features you feel the AIM is lacking that would be beneficial?

The code needed to log data isn’t too bad. But writing another program to visualize the data well was going to be way too much work.

I research and analyze human behavior by trade, so handling the data is the least worrisome and most exciting part of it for me. Though, I don't make UI's and fancy applications, just use software like R or SAS to sort and analyze. I think just handling the data in Excel and programming some macros would keep me busy enough for awhile.

So FYI: all commercial data loggers support custom / 3rd party sensors. Some like the GPX Pro only support analog sensors (0-5V) while others like my AIM MXL support analog (still 0-5V), digital speed pickups as well as CAN bus. AIM allows you to define your own custom CAN bus protocol decoder so you can go pretty crazy.

I didn't know the AIM allows this. Now that I think about it, I may have known some loggers allow sensor inputs -- maybe their price points deterred me. The AIM is not super pricey though. Perhaps I should get an AIM to mess with. I still, however, will continue with my project just for the fun of it, if nothing else.

Edit: Almost forgot to ask: Can you give more details on the hardware components you selected. Do you have a github repository with your code to share with others?

In true prototype fashion, the hardware is the simplest off-the-shelf components I could find. An arduino Uno clone I had lying around, a generic smart card reader/writer, a $10 USB batterypack for charging cell phones to power it, and a "Ready to Sky" NEO M8N GPS module. All this can be had for ~$50 on Amazon. I drew up and 3d printed the housing so that I can stick it in my backpack for testing. Eventually the unit will rigidly mount to the bike, but I'm not there yet. I haven't posted the code anywhere as it's rough and note notated well yet. The main hurdle at the moment is the GPS is only logging at 1hz. I would like to get up to around 5hz. That's my next coding mission.

Excell what language are you going to code in for the project?

As Synfinatic said, just using the Arduino IDE and whatever you call that
language.

 

[auntiebling]

this thread is like Schrodinger's cat... it should exist in Geek Speak and Garage at the same time

 

[synfinatic]

Direct brake & throttle (TPS) sensors are preferred over using an IMU (your 9 axis sensor) as brake/TPS are your inputs to the bike, while the IMU detects the reaction of the bike to those inputs. Direct sensors are easier to interpret and far more accurate/meaningful.

At our level, I don't know if you really can measure "brake fade" though. At least- I've never tried. Easier to just regularly flush your fluid and put new pads in.

FWIW, you may find the Arduino Uno platform a bit too limiting. It's not particularly fast at ~16Mhz @ 8 bit. If you need more performance, more IO pins, more flash or RAM, I'd recommend checking out the Teensy line. They are are compatible with the Arduino IDE/tool chain so you'd need only very very minor code changes and you'd have a lot more performance/features available. They're also reasonably priced.

https://www.pjrc.com/teensy/

Honestly, there really isn't much that I wish my AIM MXL2 did that it doesn't. There are a few things though:

- More advanced math channels in the data logger itself. Mostly so I can put a filter on the gear position sensor output to stabilize it. This is because the GPS output on the SV650 is really unstable.

- Better support for the SDS (Suzuki Diagnostic System) serial protocol. Right now AIM only really supports the GSXR SDS and the SV650 is very similar, but not 100% compatible.

- Would be nice to have a backup battery + time delay for turning off the unit. Right now when I turn off the bike, I turn off the data logger. Any data which hasn't been saved to flash is lost and that sucks.

 

[Junkie]

for brake fade, I'd want to measure 3 basic things:
acceleration
lever position
fluid pressure

I don't know how reasonably you could do the latter

on the gas I'd want throttle position, RPM, lean angle, and acceleration - to figure out how much it's spinning (with lean angle important for tire diameter)

 

[excellrec]

Direct brake & throttle (TPS) sensors are preferred over using an IMU (your 9 axis sensor) as brake/TPS are your inputs to the bike, while the IMU detects the reaction of the bike to those inputs. Direct sensors are easier to interpret and far more accurate/meaningful.

My intention is to incorporate all of these rather than either/or. In my limited testing thus far, I've found GPS alone to be too unreliable for consistent high resolution speed and positional reference, though from what I can tell it is good for time reference and general position. I'm considering the possibility of using an IMU as complimentary to GPS to calculate higher resolution speed and direction. For example, I wonder if an algorithm could be created that would reconcile GPS changes in velocity from one data point to another that disagrees with IMU's acceleration/deceleration values to create a more accurate speed and direction value than from either alone.

https://www.pjrc.com/teensy/

Thank you, I've heard of them. I will keep in mind if the hardware begins to be a problem.

More advanced math channels in the data logger itself. Mostly so I can put a filter on the gear position sensor output to stabilize it. This is because the GPS output on the SV650 is really unstable.

Is this because gear position is derived from RPM and GPS speed and the GPS speed fluctuates too much?

Would be nice to have a backup battery + time delay for turning off the unit. Right now when I turn off the bike, I turn off the data logger. Any data which hasn't been saved to flash is lost and that sucks.

That's interesting, my prototype writes ever second so I only lose, at most 1 second of data. Though, this may have to change if I start running into timing issues due to constant writing. They must be using a large buffer? Or it just doesn't ever write unless it's told to?

For brake fade, I'd want to measure 3 basic things:
acceleration
lever position
fluid pressure

I don't know how reasonably you could do the latter

on the gas I'd want throttle position, RPM, lean angle, and acceleration - to figure out how much it's spinning (with lean angle important for tire diameter).

Brake fade is not a huge priority for me, but just something I thought of that would be interesting. Speed will be measured (as discussed above), which will answer most the questions. The only thing I'm on the fence about with braking is hydraulic pressure vs just lever position. Lever position would be easy and not involve cracking into the hydraulics, but I don't know how correlated lever position and hydraulic pressure are under normal usage conditions.

 

[synfinatic]

for brake fade, I'd want to measure 3 basic things:
acceleration
lever position
fluid pressure

I don't know how reasonably you could do the latter

on the gas I'd want throttle position, RPM, lean angle, and acceleration - to figure out how much it's spinning (with lean angle important for tire diameter)

Break pressure is easy. Use a break pressure sensor: https://www.discoveryparts.com/aim-...sure-sensor-2000-psi-1-8-npt-aim-prs-839.html

XT Racing sells a manifold which makes it easy to install.

Lever position is doable of course, but you'd have to fabricate it yourself.

 

[synfinatic]

My intention is to incorporate all of these rather than either/or. In my limited testing thus far, I've found GPS alone to be too unreliable for consistent high resolution speed and positional reference, though from what I can tell it is good for time reference and general position. I'm considering the possibility of using an IMU as complimentary to GPS to calculate higher resolution speed and direction. For example, I wonder if an algorithm could be created that would reconcile GPS changes in velocity from one data point to another that disagrees with IMU's acceleration/deceleration values to create a more accurate speed and direction value than from either alone.

GPS accuracy is an issue. Systems like AIM integrate accellerometer data and software filters to make the system far more accurate than the raw GPS data allows.

Is this because gear position is derived from RPM and GPS speed and the GPS speed fluctuates too much?

Analog signal noise. Motorcycle electronic signals tend to be noisy due to the coils

That's interesting, my prototype writes ever second so I only lose, at most 1 second of data. Though, this may have to change if I start running into timing issues due to constant writing. They must be using a large buffer? Or it just doesn't ever write unless it's told to?

You want to write "blocks" the same size as the block size of your flash. otherwise every "write" is actually a read & re-write an existing block. This causes your flash/sd card to wear out faster and is slower to write.

 

[Sharxfan]

Would it be possible to somehow wire up an external indicator so you know when the last block has been written to memory say a flashing LED? I am sure there should be a way to code this into the write loop or maybe even a small LED screen.

 

[synfinatic]

Would it be possible to somehow wire up an external indicator so you know when the last block has been written to memory say a flashing LED? I am sure there should be a way to code this into the write loop or maybe even a small LED screen.

Well typically it’s not really an issue because it will flush after X seconds even if there isn’t enough data for a full block. But sometimes things happen and you have an unexpected power failure [youtube]tBbVJf9bJCs[/youtube]

 

[synfinatic]

One more thing excellrec: you can download the AIM RaceStudio software off their website and it should come with some sample data to play with. Might give you some good ideas what is possible and useful for when you write your own software.

I also recommend anyone interested in getting the most out of their data pick up the book "A Practical Guid to Race Car Data Analysis" by Bob Knox. "Making Sense of Squiggly Lines" by Christopher Brown is also good, but they both cover most of the same content. Both books are targeted towards cars and not bikes, but a lot of the content applies. Sadly, there is some M/C specific stuff that has no correlation to cars (lean angle for example) so neither book covers that.

The only content I'm aware of for data acquisition and analysis is the DataMC website by Andrew Trevitt: https://www.datamc.org/

 

[stangmx13]

hey, datamc.org is back up. nice! a while ago it was completely gone and I had to use the WayBackMachine to get data from there.