Digital Dashboard – Display Ideas

Leave a reply

The dashboard/logger is starting to come together. Most of the sensor functionality I want is in place, it logs well, etc. The tricky part now is how to display all this info in a way that is useful and clear while driving the car.

One of the most import visual outputs is the shift light itself. The setup i’m using is fairly large and clear with enough length and resolution to hopefully make it clear where you are in the rev band and how its trending. I do hope that they are bright enough to see in the sunlight, but I think having it mounted in the factory dash area under the dash hood should make this ok.

The second most important indication is for the warning messages. If my oil pressure drops or I start to overheat, i want it to be very clear very quickly. As of now, if there is an alarm condition, the whole display changes to a warning message screen:

achtung“Warning”, “Achtung!”, “Danger to the Manifold”, would all be appropriate. At the same time the shift lights will all blink red. I can display up to three alarms at once should hopefully be enough, even for a German car.

Lastly, i thought it would be cool to have a large number display for the gear indicator. While i generally know what gear I’m in, i’m moving to a 3.46 rear end in the E36 this year and will be shifting more often so it may come in handy.

IMG_1211Working with an old school character display is pretty clunky, but it at least allows you to program 8 custom characters. I used five of the custom characters for the I, II, III, IIII, and IIII characters for the bar graph. I used the remaining three slots for the large number characters- basically an upper block, lower block, and full block. There are prettier 4 line characters out there, but I don’t have the memory for them with the bar graph.

The mbed microcontroller i’m using does have a built in controller for a 7″ 800×480 full color TFT display, but that’s for another day.

In addition to the main screen, I can scroll through different screens using the buttons on the right side of the display. As of now I have a screen showing the raw ADC data for the 8 analog inputs, a screen with all processed sensors, a screen with GPS status, a screen with some basic setup stuff. I’ll post more info on those when i get them sorted out.

 

Digital Dashboard – GPS

Leave a reply

Another thing that i like about the EA LPC4088 board is that it has Xbee formfactor headers on it. EA also makes a GPS accessory that plugs into using the popular PA6H module so there is lots of community support out there for it.

The unit itself is pretty slick and has a 10hz update rate which is helpful for tracking high speed things like race cars. The device talks over a UART using standard NMEA protocol so there are plenty of parsing libraries out there. I literally had this running in a couple hours.

I also soldered on a UFL connector and attached an active external antenna. It has a magnet mount which will work well on the roof of the car.

gpspic

The precision shown on the display is only enough to get you in my  general metro area. The data logger logs six decimal places of info which is more meaningful for tracking a car on track.

This hasn’t yet left my house. I’m super eager to actually drive around with this and see how the data looks. I’m hoping it doesn’t require too elaborate of filtering.

Digital Dashboard – Main Unit Shield PCB

Leave a reply

I went around in circles for a few weeks trying to figure out the best way to deal with the main unit. My initial thought was to spin an entirely new PCB to house the LPC4088 Quickstart board, SDcard interface, accelerometer, ADCs, buffer opamps, etc, etc. Basically it would replace the LPC4088 QSB Base Board and add the additional components I needed. Nice and clean.

After thinking a bit, however, I came to the conclusion that this would be pretty redundant, entail a much more complicated design effort, and cost more to build. I might as well use what’s been done for me and simply add what I need. Fortunately, the Base Board has an Arduino shield interface. I can just build a shield! It will plug into the empty shield header interface shown here:

image5

The other benefit of this reduced scope is that I can actually get the design done and built in a timely manner. I decided on using a Microchip 8-channel MP3208 12-bit ADC. This will cover 8 channels of 0-5V analog input, plenty for my logger. I’m using MCP604 opamps and basic RC filters for input buffering/filtering.

Here’s an example of one of the analog input circuits. It has an optional 5V pullup via jumper, buffer, and antialiasing filter.

AnalogInCircuit

The other main purpose of the shield is two connectors. One for all my sensors to connect to as inputs and the other to connect to the Remote Display.

The board looks like this:

TOP

I just placed the order today so the PCBs should be here in a couple weeks. In the mean time i need to gather up the BOM and  order the parts.

In the meantime I plan to focus on the software a bit and get that decent shape. More to come!

 

Digital Dashboard – The Remote Display is Built

Leave a reply

I received the “Remote Display” PCBs from OSHPark before Christmas. This was my first time using OSHPark, but i must say it was a pretty great experience. It was very easy to upload my Eagle board design, it processed quickly, and they gave detailed renders of the final boards and all the layers – all easily viewable right on their website. They also arrived ahead of schedule.

IMG_1223I had some time off for the holidays and managed to get one board built up.

image3

It’s funny how I already see things that I wish I had done differently. Why didn’t i label the trim pots and the buttons?!? (The pots control contrast and the R, G, and B backlight). But what matters most came through, it works!

image2

It still looks like a science fair project, but at least all the hardware is set and physically stable. One less bread board to deal with.

Now that this is done I need to focus on both the “Main Unit” PCB and polish up the software.

 

PCBs for the digital dashboard!

Leave a reply

I finally got moving again on the digital dashboard project. I was held up a bit not being able to find device models using DipTrace. I made a few from scratch, but it was tedious and was bogging me down. I also knew that when it came time to do the layout, I’d have to shell out for a paid version of DipTrace. This got me researching options and I finally decided to give Eagle another go. It has a clunky UI, but the community support can’t be beat. There are libraries for everything out there. For example Adafruit and Sparkfun both share their schematics in Eagle and offer their libraries up for public use.

After about 30 minutes of getting used to the UI, I was rolling. I was able to find a few obscure device models such as the 12 LED bargraph in the Adafruit library. I also found that making new device models from scratch was a breeze in Eagle so I soon found myself cranking them out myself rather than hunting for them.

Using Eagle, i was able to finalize the design for the remote display PCB. This will serve as the “dashboard” part of this project. The other half will be the “main unit” where the processor is housed along with all the sensor inputs, etc.

Due to all the LED and LCD I/O, I decided to go with a four layer board. It costs twice as much, but everything is neater and more electrically sound. There isn’t much too critical with regards to signal speed or integrity on this board, but its still fun to do things right.

Layout

 

5V power and ground planes are on the inner layers with traces on the outter layers. All components are on top. You can see the four 12 bar LEDs along the top that will act together as the shift light and also blink warning statuses. In the middle is a good old fashioned 20×4 character LCD. It has an RGB backlight so the four trim pots on the left control its contract and background color. On the right are three push buttons. As of now the top button is to start/stop data logging and the other two are for menu scrolling. The connector on the left is a Molex Microfit which is easy to use, has good density, and has cheap off-brand crimp tooling.

The middle chip is the MCP23008 demux that is running the LCD off the I2C bus. The two chips toward the outside are HT16K33 LED controllers and each drive a pair of the 12bar LEDs on the I2C bus as well. Oh and there’s a power LED too!

I decided to go with OSH Park for the PCBs. They have a ton of great feedback and good prices as well. In about two weeks i should have my boards!

top

I’ll get the parts on order soon and if all goes well, I’ll have a functioning PCB assembly in the next few weeks. My plan is to use this assembly with the LPC4088 dev base board acting as the main unit. This way I’m only introducing one major variable at a time. When all the kinks are worked out with this Remote Display assembly, I’ll move on to ordering the Main Unit boards.

Digital Dashboard & Data Logger

Leave a reply

For awhile I’ve thought that it’d be cool to make my own digital dash and data logger for my track cars. You can certainly buy these, but they aren’t cheap. I think i can build one for way less, learn a thing or two, and have fun doing it.

So far i have a breadboarded prototype up and running. It’s based on the EA LPC4088 on the mbed.org platform. I’m using a mini dev board for break out and a standard breadboard to host my peripherals.

Prototype!

Prototype!

For now I’m using a basic 20×4 LCD for display. This processor can power a TFT so eventually i may move to that. When in use, i plan to focus more on the shift lights (shown on the right of the breadboard) and warning lights for real time feedback.

Basic Block Diagram

Basic Block Diagram

As of now it has:

  • LPC4088 quickstart board with EA Basic Dev Board
  • LCD with i2c backpack
  • Shiftlight strips (from adafruit) on i2c backpack
  • AD7490 ADC on SPI bus
  • AEM pressure and temp sensors feeding into ADC
  • SD memory card reader on Dev Board

It’s currently capable of receiving sensor inputs via 5V ADC and pulse train (engine and vehicle speed). It crunches the sensor data and displays it on screen. The shift light also functions appropriates and flashes red when max RPM is exceeded. It samples and also writes the data out to the SD memory card at 10hz.

The next step really is to solidify the hardware. I’m working on a schematic that I’ll layout and make into a PCB. It’s mostly done, but i’m hung up on how i want to divide up the components. Should I have a brain in the glove box and a remote display? Should the shift light be separate from the display? etc.  I also have an accelerometer that I need to integrate. Eventually I’ll also want GPS so I should probably make provisions for that before I get too far along. Then again, these things tend to actually develop when you move on what you have now and iterate later. Holding for future updates leads to nothing getting done.

Click on the “Digital Dashboard” category to the right for all the latest posts.

M3 Updates

Leave a reply

I’m doing a lousy job of keeping this updated, but here’s an update on the M3.

So far I’ve done:

  • Installed Cobra Suzuka racing seats for head room and control
    • VAC Motorsport adapters, mounts, and hardware
  • Removed headliner and sunroof, installed fiberglass delete panel for headroom and future rollbar height
  • Replaced the H&R Race springs with Sport, better ride height and geometry
  • Front wheel bearings
  • Front control arms and Bimmerworld TrackCAB delrin bushings
  • Bimmerworld Group N rep motor mounts
  • Rogue Engineering transmission mounts
  • Secondary Air Pump delete

Right now the car is solid and I’m just having fun driving it. So far I’ve done four track days and two autocrosses with it and its been a blast. I have the last track day at NHMS coming up this weekend.

The next item on the list is to install a 4pt roll bar and get the harnesses I have sitting on a shelf installed. I hope to document this project a little more thoroughly!

Project M3

Leave a reply

Well a lot has happened in the six months since i last posted anything about cars. Last fall I sold the GTI. It was a good car and consistently exceeded my expectations both on and off track. Despite VW’s somewhat tarnished reputation for reliability, it never so much as hiccup’ed, even running an extra 100ftlbs of torque and 75 additional horsepower on track.

However the track bug was coming back with a vengeance and I knew i should get something older, cheaper, with more track/race support going forward. I decided on an E36 M3. Since I’ve owned one before, I know them well. They have tremendous aftermarket race tech/support and a great community. I was even running BMWCCA track events in the GTI!

Previously, i had a sedan, but this time i wanted a coupe. There isn’t a performance difference, but the larger coupe doors make getting in and out easier with race seats easier for a tall guy like me. Alpine White is the only color a BMW should be in my opinion and a black interior would be ideal.

It took me over six months to find the right car, but I finally did. And lucky enough, it was a local car and BMWCCA-Boston club member.

1997 BMW M3

1997 BMW M3

It’s a southern car brought up here by the previous owner as a weekend/track car. It’s lived a comfy life and is really clean. It came with a great maintenance/mod history. The previous owner definitely loved this car.

In my next post, I’ll go over where the car stands, what I’ve done recently, and what my goals for the car are.

 

New Processor: Robotis OpenCM9.04 w/ ARM Cortex M3

4 Replies

The last “brain” BETH had was a Raspberry Pi. The Pi worked well and was of course very powerful, but I started to get sick of it.

Having to power on, wait a minute for boot, SSH in, samba share my source files, run program, issue shutdown command, wait for shutdown, and power off all the time got old. I tried to improve things by hooking up an LCD that would run a start up menu on boot up. It would show me the IP address so i could remote-in easier and allow me to run the BETH program with a button press. It helped, but ultimately all it was doing was adding ever more complexity to both hardware and software. I began to realize that all of this was slowing down development because I often didn’t feel like going through the hoops to get started. (boo hoo, right?)

Another con to the Raspberry Pi was that relative to a microcontroller, it used a lot of power and battery life was much less than what it was with the Arbotix microcontroller.

Lastly, I no longer wanted to deal with the Linux overhead. Robot projects are fun, Linux projects are fun, but i’d rather keep them separate so i can focus on one thing at a time.

So all this drove me to find a new processor. The timing was right, though, because Robotis just released the OpenCM9.04.

Robotis OpenCM 9.04

Robotis OpenCM 9.04

This is a totally open-source ARM Cortex M3 based microcontroller designed for use with Dynamixel servos and general robotics use. It uses what’s essentially the Arduino IDE with an ARM toolchain hooked up. It’s very easy to use with the built in 3-pin Dynamixel connectors, voltage regulator, and 3 UARTs. For hardware, all I i had to do was run power, ground, TX, and RX to an Xbee break out board. The board is powered from my powered Dynamixel hub through the Dynamixel connector. The other nice thing is that this board is quite small, about half the size of the original Arbotix controller, and allows my to install the battery back inside the hex body.

For software, I reverted back to my Arduino BETH code, updated to my more recent Raspberry Pi trajectory/gait algorithms, and had it all running in a couple hours. The functioning code is on my GitHub.

I must say its refreshing to have an “instant-on” robot. It makes it much easier to casually boot up and work on it without having to commit for a few hours due to booting up, software updates, remote logins, etc. It’s also nice to focus purely on the software that is controlling the robot directly.

As for power, this is significantly more powerful than the ol AVR in the Arbotix controller (72MHz vs 16MHz, 32bit vs 8bit, etc). The only thing this lacks is a hardware FPU for floating point math. I think this will cut it for my FK/IK/trajectory type needs for now. I do have an upcoming project that may push this limit, but more on that later.

Videos of B.E.T.H.!

1 Reply

I’ve been really slack about ironing out the last few bugs and taking some video of B.E.T.H. in action… But here it is! Some of the movements are a little erratic, but that’s because i’m filming with one hand while controlling the dual joystick controller with the other.

Here is a body forward kinematics demo. Here you can see that i can input body angles via the controller and the legs move as necessary to allow the body rotation without moving the feet.

Next is the tripod gait. This is a simple and fast gait in which two sets of three legs forming a triangle move alternately.

This is a wave gait. The wave gait is slow and moves only one foot at a time. The rest of the legs have to pull backwards in unison.

Finally, we have my favorite, the ripple gait. Two legs move at a time with one leg beginning to step as the other hits it’s peak height in the step. Because two legs move at once, its faster than the wave gait, but slower than the tripod.

For more info on gaits, here is a good article from Oricom Tech. My final code used here is available on my GitHub.

For more info on B.E.T.H., head back to the beginning.