Brent Picasso is CEO and co-founder of Autosport Labs (ASL), a company that develops open source motorsports technology. Their innovations allow enthusiasts to explore and enhance auto systems and to contribute back to the community.
In this interview, I sat down with Brent and Ryan Doherty, principal at ASL, to talk about being open.
This is a partial transcript.
When did you start Autosport Labs?
Brent Picasso (BP): Autosport Labs started in 2006. We were kinda doing quasi-open hardware stuff even before we got popular. We started designing an electronic ignition system for a racecar called Megajolt. We designed it, I built it, and then I shared it on a Yahoo! group. People on the group were like, "Wow, can I have one too?"
We said, "Sure, we can make a few by hand..."
Then people got more excited, and more people ordered. We started printing boards and shipping instructions. The customers started pulling us into the business. We started selling kits of components, which people assembled themselves. Then folks asked us to assemble them and do the soldering for them. We hand-soldered the ignition systems, and then volume got to the point to consider mass production. We built up a surface mount assembly line in my garage. We started mass producing on our own.
Fast forward to like 3 or 4 years ago, and we moved into a small commercial space north of Seattle, WA.
Around that time, we were thinking, "What else can we work on that is similar in spirit to motorsports/cars?" One candidate that stuck was an open source data acquisition system called RaceCapture. The system was a project that moved along fairly slowly, and had a number of potential users interested. A friend and team member, Brian Lalor, contacted me and said "Hey, this project is cool. You should finish it. Can I help?" I was like, "Yeah yeah, OK..." Then it was like, "Oh, this guy really wants to work on this thing! I should actually engage with him!"
That is when the project kicked into higher gear, a sense of urgency to complete. Around that time, we gathered a few loose team members, and decided on, "How can we launch this thing? A crowdfunding campaign? Traditional launch?" We did an IndieGoGo for the first gen. We raised 1.5x the target, at $48K over the $30k goal.
One thing we learned while developing RaceCapture: we raced in 24 Hours of Lemons, a crapcan racing series. We added a cellular telemetry module, and made it "the tweeting racecar." The firmware was programmed to act as if it had a personality, and sent tweets via SMS. Things like, "So-and-so is driving me now! Let's put down some fast laps!" On completion, it would say "my lap time was 2:30!" and if it beat any previous lap times it would tweet that too. It was tweeting autonomously, as if it was a person.
We did some two-way communications where I sent SMS messages and it replied with its health status. We were able to control an RGB ropelight, and people could tweet at the car to change the lights. We were doing night racing, so that was visible and fun.
After that, we thought, "Wow, isn't that cool?" It dawned on us we could create an inexpensive racecar telemetry system. Legit real-time analysis. Engine health, driver behavior, anything that could be logged would get sent to cloud in real time and saved for future analysis.
We knew existing systems were there, but they were expensive and required significant infrastructure, like a 30-foot mast antenna, and all kinds of other expensive equipment.
A cellular base, we thought, would be a cost-effective solution for amateur and eventually pro racers. As we learned this, we augmented our campaign with an optional telemetry system, a separate box with the cell system inside. That was way more popular than we anticipated and hinted at the opportunities of this breakthrough tech.
Today, what we can create is open source hardware, and the open platform we're creating to share open source motorsports data.
Ryan was very excited about what we were working on and joined our team shortly thereafter.
Ryan Doherty (RD): I met Brent and Kelley (co-founder and president of AutosportLabs) at a 24 Hours of Lemons Race, racing $500 or less cars. I saw the wiki, but it was under development still. Our drivers kept blowing up engines and not looking at gauges. I knew if we had a remote system our engines would survive, even if we didn't win.
I was one of the first to put money down on the IndieGoGo campaign, and was drooling over it everyday. After the campaign finished, I talked with Brent online, and bugged him, "This is awesome, so many cool things can be done! What things can I do to help? I'm a webdev."
Eventually, he agreed I could help, which was about 2 years ago or so. Since then, I've been building out the product and adding features for the community.
What is your community like?
BP: Much of our community found us organically.
The Megajolt project showed many people that we have a lot of MK I users from the original IndieGoGo on the forums and Facebook. With the MK II, released in November, we've had an influx of users just from that launch. Right now it is probably 50/50 between the MK I and MK II users.
Is your community more racer or more hacker?
BP: There are individuals who are interested in the flexibility and the open source potential, contributing to the app and firmware. I would say we're 80% non-tech racers who can still appreciate the flexibility, and 20% who are more hardcore and can take advantage of the onboard scripting capability. Then there's a few who can build dedicated sensors and other devices—Arduinos with a CAN bus, stuff like that.
We're working to be "anti" traditional approach—which is proprietary lock-in and vendor lock-in. That is our goal and a strength we have. The people who appreciate it, notice, and those folks become the biggest advocates.
They say like 10% or less of your users will help create the things. Arduino has like 10% of their community writing the code, but the rest just tweak the existing code. Using the example code straight up or mild tweaking is like 80-90% of users.
RD: Take sequential shift lights on LED boards for instance. People have created variations on that with warning lights and other things, shared on the forums, and then people chime in and say they got it work. People love the blinky LEDs.
BP: People have done some interesting things. Active aerodynamics is one thing we did at a race. We controlled a wing to have variable downforce based on brake pressure. We use a motor to put up a wing, and act as an air brake. We did that with an output, and some Lua scripts.
RD: Yeah, that is technology that only happens on a $250K car, not a $500 lemon.
What is the mix of custom and off-the-shelf?
BP: The hardware is all our own design. We're using a STM32F407 micro-controller and freeRtos as a preemptive operating system, running RaceCapture/Pro. On top of RTOS, the whole firmware is also our design.
On top of our hardware and firmware, we're using off-the-shelf GPS modules, a built-in Inertial Measurement Unit (IMU), and a 9-axis gyroscope/accelerometer. There is an SD card slot, a number of analog and digital inputs and outputs. A big part of being auto-grade is protecting input/output/power supply from harsh electrical environment.
Some people say, "I can buy an Arduino and put $20 worth of inputs on it to do the same thing," but try vibrating it for hours, or getting it up over 100 degrees, and see what happens. 40% of our components in the system are dedicated to buffering and electrical robustness.
RD: USB does 5 volts, but cars vary from 10-18 volts typically depending on conditions. You can plug in something that outputs hundreds of volts that can really do damage, and at multiple amps.
Lua scripting runtime runs in the unit, along with the first-class features of system. People can upload scripts which read sensors, create virtual channels to combine inputs, and create new channels based on that. Users can create custom behaviors, activate switches and pumps, things like that.
For desktop and mobile app (beta) we have a Kivy app. Considering what it is doing, the amount of work it took to port from Windows to Mac was only a day or two of work. For Android, the hard part was Bluetooth hardware. All the UI stuff "just worked." I'm still pretty impressed.
Python is stupidly easy to work with, and if you need to optimize, you an drop to the metal and do cython. You have that performance escape hatch. Much of it is OpenGL2, so it doesn't even feel like you're running a Python app at all.
The Bluetooth portion was native to Android, and that is where I spent majority of my time building robustness.
We've actually pushed patches to Kivy too, since that is open source. Our next step is an iOS port. There are a number of Kivy apps on the iTunes store, and it is a night and day difference.
MK III?
BP: We can iterate fast on our products, so we try to do it in a way that makes existing customers grumpy, like: "Oh man, you just changed it, and I just bought it!" The next round of products will be an upscaled version of the unit that is more rugged, more waterproof, more designed for pro-level use. Also a lighter smaller more cost effective unit.
There will be a MK III, we'll keep with the evolution theme, maybe adding WiFi connectivity to better support iOS devices.
When?
BP: A hardware version upgrade happens about every year or so, that is a decent outline. If we did one on the MK II at the end of last year, then we could do something similar probably for MK III as a goal.
Has anyone made an epic hack?
BP: Tire temperature sensors!
RD: Yeah! And we had a person who bought a unit to work on a train!
What happens is people not looking for a telemetry system, but a datalogger system find us. Because it is flexible, they say, "we can plug in anything!" Multiple units have been connected together to log more channels. One sucking up analog, going out to CAN, and then another unit reading in CAN, and broadcasting out over cellular.
There have been raceboats in France. One team is competing in the Isle of man TT race, running our systems on an electric motorcycle. It is student run and they are hooking up sensors for temperature, battery life, and others to calculate range. Data is super important for developing a new system.
The best thing is having a customer tell you: "This thing saved our race!"
The big important question: Is anybody winning with your projects?
BP: Yes! There is the 25 hours of Thunder Hill—the longest race in North America. Technik/HQ, he had Racecapture/Pro broadcasting live telemetry, and they had an alternator failure. Driver couldn't tell while driving, but the telemetry knew that the voltage level was low and diagnosed it before pitting, and they didn't have to spend time figuring it out, just fixing it.
Another race saver is when the driver is on the paddock, and they see the car overheating before ever getting on the track. Once on the track, you are stuck there, so it is important to catch symptoms before you get onto the track.
A few races ago, one member of our team looked at data and saw we were losing oil pressure during left-hand turns. He noticed and told the driver to slow down in two of the turns on the track, to keep pressure higher, which could have prevented engine failure.
People use our system to drive faster of course too! Real-time systems are usually about $30K. Even if you don't have a pit crew watching, you can just go to your browser or pull it up on the app. It is huge to have the data waiting for you.
RD: If the difference in price between startup vs enterprise is bad in software... it is much worse in racing.
Most automotive data loggers are 15-20 years old and cost multiple thousands of dollars using their proprietary platform and tech. Our data exports as csv. You can hook up any sensors you want. OBD2 connectors are allowed. We don't charge extra for extra services, we want to integrate with as many platforms and tools, and work with customers.
BP: Our theme is to not just be open with software, but with the data format and API too. That is a big relief from the extreme lock-in from proprietary solutions that are so common in the motorsports industry.
How big is ASL? Where are you based?
BP: Seven team members are headquartered in the Seattle area, north of there in Lynwood. The team is geographically diverse and dispersed. The overriding theme is to find the right people, not convenient people. Motorsports is full of passionate people, but it is niche. People who can deliver in a particular domain (web, software, hardware) it helps to have passion about cars or racing. Finding those people, the right people, is the most important thing. We're set up in a virtual organization. It was really inspirational when I worked for the cheezburger org, where I worked with chat/video conferencing, even paired programming remotely.
We use online tools heavily to stay in touch and work and socially. I'd say we're just as productive as a traditional office environment.
RD: I agree. I think we've found those unique people. Motorsports racing is a passion project. If you look at racing cars logically, you say "this is a big expense!" so it is rare to find someone technically savvy who likes to build and likes racing. It is rare to also find folks who are passionate about openness, flexibility, and empowerment too.
BP: Hackaday.io inspired us. People posting projects, and then those projects getting updates. We want to transform our current forums to something more like that and bring them to life. Like how SparkFun does that with sponsored projects.
The Hackaday.io people post their FOSS projects, and the community votes on them. Then they can post updates, there are prizes, and there are different social/marketing aspects. Upgrading to a more modern forum technology stack will allow us to help amplify that effect.
Where do you point the new people when they show up?
RD: We have a mailing list for devs. We have forums. We have a GitHub. We have a Wiki. Take a look at the app and figure out what you want to build, or ask us what you can do via email.
Who do you want to work with in the future?
RD: Racing organizations! We'd like to help them socialize their race events beyond the reach of people who are at the event. If a race organization was using our tech, the data could be broadcast out, like a livestream but watching dots of cars go around with stats and graphs during a race realtime!
BP: LocalMotors! They have an open source car!
The 3D printed one?
RD: Yeah, that was some years later. The rally fighter was their first open design, and they are working on other projects. They have had people submit ideas, and if it gets popular enough, they build it.
I can't think of many folks doing open source electronics for cars.
It is hard enough to build open hardware in general, but especially for cars. It is an extraordinarily locked-down platform, the car. It is not a laptop, you are taking about layers of custom built components, communicating over multiple proprietary channels. There can be decades before there is public data about what is going over the system in terms of data.
BP: Yeah, with what GM is doing, and John Deere... there is going to be a legal showdown.
RD: Yeah, that is why community is important. We don't own every car, so the community provides the feedback and testing. Physical compatibility is a hard problem. It is hard enough to test across ten Android devices, let alone all different makes and models of vehicles!
Any other non-racing or technology organizations you'd like to partner with?
BP: Autonomous vehicles maybe? UAV stuff has always fascinated me.
RD: Being on the west coast during the droughts got us talking about live data logging for agricultural systems, which would be cool.
BP: Yeah, Internet of Things has much potential we haven't talked about, and telematics use cases are always easy to pivot on. Monitoring environmental data would be cool. Farming would be cool.
Even in the 1960s and 1970s, you'd get schematics for your stereo receiver so you could take it to shop and they could fix it. You don't have that anymore. It is like a disposable item that you cannot fix. Car manufacturers are moving in that same direction, where you must use "authorized service centers."
RD: Yeah, and even then, the service centers don't debug, they just rip-and-replace. If the professional engineers can't do it, then that is really bad for anyone else.
BP: It is common today for cars to get shipped with incomplete firmware and things getting flashed after the fact through Electronic Control Units (ECUs). It is "upgrades," rather than having something fully tested before it leaves the factory floor.
The lasting feeling I have is it is amazing when someone gives us feedback saying: "What you did made a difference in my race, or my life." That direct impact makes it all worth it. When we touch lives directly, it is an amazing experience.
All images in this article are by Autosport Labs, Copyright All Rights Reserved.
Comments are closed.