Redesign of my "HUD"

[linkinpark9812]

Some of you may have seen the old one, but I had redesigned it and improved it a lot. Not on the bike yet, but almost done fully bench testing it.

[csmith12]

That is alot crammed into a small space. Cool none the less, can't wait to see it mounted up.

You got me thinking....

[TnNinjaGirl]

I'm throughly impressed

[evidens83]

Interesting. Stupid question but will this be HUD on a lid or the windscreen?

[Snake]

Awesome work!

[kirk595x]

[EsrTek]

Not sure about that.. I like the idea, but would never use it as pictured.
Too much info crammed into a small space. Would have to focus too much on the HUD to find the info you're wanting.

[adouglas]

Agreed.

WAY too much clutter.

What possible use could, say, the number of GPS satellites you're receiving be while riding?

There are gratuitous icons. A picture of a satellite? What for? A picture of a fan? What for?

I write for a living. There's a very old, tried and true rule for editing:

First you put down everything you think you need to say. Then, go back and remove everything that isn't actually about the topic.

(At this point, I could go into four paragraphs about the effect of too much information on operator performance due to distraction, the false belief that because a bit of information is available it is therefore useful, the cultural tendency to pay too much attention to technology, etc.... but none of that is about the topic. See?)

You're in the first half of that rule. You've got the kitchen sink.

Step back a minute and ask what you actually need to know while riding the bike.

I'd say:

• Gear position
• Speed
• Fuel
• Health of systems (which doesn't mean every bit of data you can get, it means "is the bike running well or not?")
• Basic navigation (not lat/lon to the second or elevation, but info that will help you actually get you to your destination).

Save the heavy detail for a second, info/service/troubleshooting mode.

[Panda]

I assumed it was secondary display that wasn't meant to be used while riding except for the gear position indicator.

[DEFY]

Looks like a lot went into the display but I would go with having sub menus. If the info isn't necessary for basic function and helpfulness towards the rider then make it optional to view.

[adouglas]

Another way of thinking about information in the context of riding is to ask the following question:

Is the data actionable or not?

If not, then it's not something you need to know at that moment.

I'd define "actionable" as information that can prompt a useful response. Non-actionable information might be good to have in another context but has no place in the rider's brain, which should be focused on operating the vehicle and staying safe.

Things that the rider has no control over and which cannot influence the ride are useless while on the bike. So... time? Yes. You can ride faster or take a detour if you're late. Date? No.

Gear, mph, fuel level, rpm, out-of-limits system conditions --- all actionable.

OAT, humidity, satellite reception, elevation, obscure stuff like "H DOP, Brd, Psu" (whatever the heck those are), the random GPS icon --- all merely visual and cognitive noise.

Question: Every GPS has a screen that will show you detailed satellite data. How many of you have looked at that while driving your car?

[csmith12]

Originally Posted by adouglas

all merely visual and cognitive noise.

I know your intent is well meant but cut the guy some slack. If it's for his own personal use, he can put whatever he wants on it.

Designing user interfaces or HUDS is always an art. Some will hate it with a passion, others love super detailed techy looking stuff, while others love the power of simplicity or the less is more idea.

Also, my new car has about 50 buttons, knobs, gauges and things to push, pull, turn, ect... ect... ect... Yet, I tune them out every day. Visual noise, is only noise if you listen to it. Us riders should know that already.

[TnNinjaGirl]

Originally Posted by csmith12

Also, my new car has about 50 buttons, knobs, gauges and things to push, pull, turn, ect... ect... ect... Yet, I tune them out every day. Visual noise, is only noise if you listen to it. Us riders should know that already.

The first thing I thought of was a aircraft. They've got lotsa dial, switches and flashy lights and somehow they haven't managed to kill me or anyone I know.

There is no real point to this post. I think the HUD thing is cool and a great excersize in imagination and ability.

[NevadaWolf]

Cool display. looking awesome!

The data all depends on what the user needs to see. Personally I like having the date, helps when I am checking the receipt from gas stations for accuracy. (Yes, i brain fart on the date.)

Is the HDOP useful to most people? Nope, but if you are used to seeing GPS data and understand that its the horizontal dilution of precision, then it can be useful is knowing if the GPS reading you are seeing is trustworthy or garbage. While that may not help for most people, if you are collecting location data for a survey project, that data becomes invaluable. Don't laugh, I've collected boundary data in my truck before.

Based on the original design, BRD looks like it is referencing outside temperature. Not sure what the letters stand for, but I wish i was in 72* weather.

Can it be cleaned up? Sure. But that's the beauty of a digital display, it can be customized.

[Motofool]

Originally Posted by linkinpark9812

Some of you may have seen the old one ...........

Just in case you have not seen the predecessor display:
http://www.ninjette.org/forums/showthread.php?t=145121

[broilmebk]

I guess if you got used to it, the amount of info isn't a big deal. But I like the simplicity of the original design. Either way, a hell of a lot more than what I can do. Great job!

[Asspire]

I like it, I want build one of these now.


is the amps meter measure system load or the computer?

[adouglas]

Originally Posted by TnNinjaGirl

The first thing I thought of was a aircraft. They've got lotsa dial, switches and flashy lights and somehow they haven't managed to kill me or anyone I know.

I'm a pilot, former aviation safety journalist and am old enough to remember the days before digital displays.

Pilot error-caused crashes associated with misinterpretation and information overload have, and continue to, occur.

Let me give you an example. The first photo is pretty much identical to the panel on the plane I used to fly. On top of this I had to navigate using paper charts and a clipboard in my lap.



This second photo is a current "glass cockpit" with a moving map display. See how much simpler it is? Which do you think would reduce pilot workload and therefore, free up attention to focus on flying?




Things have obviously gotten much simpler over the years. There is much to be said for presenting information clearly and in a useful manner.

Great job on creating a working display that integrates so much information. However... per the post from @csmith12, having a zillion pieces of information that are ignored begs the question: why have them presented to you in the first place?

Availability is certainly good. Having it in front of you all the time is not, necessarily.

[csmith12]

Well, I don't wanna speak for Miles, but having made quite a few user interfaces/dashboards myself, it's all part of the development cycle. Throw it against the wall and see what sticks. Also, judging by the hardware and limited info, maybe there is no way to initiate a submenu. No buttons, maybe a touchscreen... that would be uber cool. And coming from it from the rider's point of view, maybe make it like a wallet, just fold it over to reveal the sub info.

Crawl before you walk ya know but you do have a perfectly valid point yo.

[alex.s]

cool screen. what is it? oled? i'm guessing it's over i2c? what computer are you using? pic? atmel? arduino? i'm assuming you're bringing the tach in from a coil wrap and the speed heading and alt are all from a serial gps unit? then dividing the speed and rpm to get a gear ratio and matching it to a gear set? the accessories are interesting. did the temp senders hook up into the analog inputs pretty cleanly? did you have to do anything special? maybe with the atmel you used a discharge timer instead? i'm loving the temp and humidity readout. how are you picking it up? would love to see a basic diagram of your setup. i've been working on an IMU that integrates 6dof Gs along with gps. its for model rocketry but really, not that much different from what you're doing here. would love to see more info on your setup.

[linkinpark9812]

So many replies haha.

I was debating between the whole simple design and having a "menu" system of sorts, but was also experimenting with a "one screen" design, where everything is presented.

I am a techy guy, so I do like having the tech info there. All of it is not meant to be seen while riding, or at least only when stopped. The reason is I don't want to cycle menus and be distracted, even while stopped. Taking a little time to read the smaller info while stopped to me is OK. I do have a couple buttons but their location is only meant to be used when stopped.

Now the old design had a menu system where I could cycle information. I just wanted to see how this new design would work.

Luckily, the way it is programmed, it is very modular (especially after redesigning) so things can be moved or re-sized easily on the display if needed to later.

I basically put the important information big and the less important small. I am good at programming, GUI, not so much. I leave that to the CGT (graphics people).

For the screen, obviously far left is gear. It uses two hall sensors and a magnet on the gear shifter, as well as taps to the N light on the bike. I would say it is 90-95% accurate and is easily corrected by going back to neutral.

Next to that is my accessories that can be turned on and off with the buttons and lit up accordingly. Fuse Box, Aux LEDs (white LEDs on the bike), running lights for the turn signals, and to switch between my stock and aftermarket horn. Radar is something with testing.

I tried not to repeat information, but bottom left show left/right turn signal, the battery voltage (I do already have a gauge for that), brake lights activating and status of ignition.

Next is the Fuel info, with percentage and Trip. Again, those are small, because not useful while riding. The next is MPG which is bigger (dashed right now as not calculating) because that can be useful.

Next is GPS info, only important thing being if it has a connection or not. The GPS icon is to indicate if I am logging (which will log my entire trip to be later downloaded if desired).

HT C is for heated clothing power status (have yet to buy).

Next is if my coolant fan is on. I have an external gauge with the coolant temp and it is nice to know that the fan is kicking on when it gets to hot.

Very top is outside temp and humidity and direction of travel. Bottom is the time and date.

Far right are the temps of Brd(the computer board) and PSU (the power supply). Then there is the amps, which is the current amp load on the bike, which will be done with a sensor.

I appreciate the feedback. Once I get some riding with it, I'll see if I need to fine tune anything. And this is secondary and is not meant to replace the existing dash on my bike, just an addition.

[linkinpark9812]

Originally Posted by alex.s

cool screen. what is it? oled? i'm guessing it's over i2c? what computer are you using? pic? atmel? arduino? i'm assuming you're bringing the tach in from a coil wrap and the speed heading and alt are all from a serial gps unit? then dividing the speed and rpm to get a gear ratio and matching it to a gear set? the accessories are interesting. did the temp senders hook up into the analog inputs pretty cleanly? did you have to do anything special? maybe with the atmel you used a discharge timer instead? i'm loving the temp and humidity readout. how are you picking it up? would love to see a basic diagram of your setup. i've been working on an IMU that integrates 6dof Gs along with gps. its for model rocketry but really, not that much different from what you're doing here. would love to see more info on your setup.

It is OLED, uses SPI interface with PIC micro-controller.

My old system had 1 PIC (technically 2, but was poorly utilized). This one has 3. The main, a PIC18F46K22, is the brain, takes most of the input and either does outputs or tells the other 2 PICs what to do. The other 2, both PIC18F26K22. One is used specifically for the OLED and presenting data, the other is dedicated to interface with the GPS module and some I/O that couldn't fit with the Main PIC.

They communicate with a very basic protocol I have, similar to 1-wire SPI, all done in software though.

No Tach on mine, and MPH and trip is all done with the GPS module.

Gear is done physically, with 2 hall sensors for up and down and magnets on the gear shifter.

External temp (with the humidity) is a digital signal. The PSU and Board are analog (TMP36) and work pretty good. I used to use one for the external temp and was still quite accurate, but I wanted humidity too, so I got the digital one.

GPS Module communicates with UART to the PIC.

Here is what my board looked like before I did all the ugly wiring of it (just the components):



The big 40-pin is the main PIC, the two top 28-pins are the 2nd and 3rd pic. The two 8pins on the right are an accurate VREF for the analog signals and NOR memory (for the graphics on the display). The 20pin is a level convert for communication between 5V and 3.3V electronics (OLED and NOR flash use 3.3V, everything else is 5V).

Bottom right is the GPS module, which will be connected to an external antenna. The rest you probably know, transistors, resistors, capacitors, etc. On the sides are the connectors for everything outside of the board, with some status LEDs for debugging.

And here is the "spaghetti" disaster afterwards:

[TnNinjaGirl]

Originally Posted by adouglas

I'm a pilot, former aviation safety journalist and am old enough to remember the days before digital displays.

Pilot error-caused crashes associated with misinterpretation and information overload have, and continue to, occur.

Let me give you an example. The first photo is pretty much identical to the panel on the plane I used to fly. On top of this I had to navigate using paper charts and a clipboard in my lap.



This second photo is a current "glass cockpit" with a moving map display. See how much simpler it is? Which do you think would reduce pilot workload and therefore, free up attention to focus on flying?




Things have obviously gotten much simpler over the years. There is much to be said for presenting information clearly and in a useful manner.

The top picture looks a lot like the Cessna I used to fly and the bottom looks more like a Glasair one of my friends has. Made decades apart. The new screens remind me of the Tesla screens nowadays.

[Sirref]

Originally Posted by adouglas

I write for a living. There's a very old, tried and true rule for editing

You just explained a lot, particularly about how your posts are so consistently well written.

[alex.s]

Originally Posted by linkinpark9812

It is OLED, uses SPI interface

fun project. nice rat's-nest you've got there not a fan of making circuit boards i guess? curious though, why did you split it into 3 chips? just couldn't have the gps uart process loop fast enough to have a reasonable update rate while running the rest of the inputs? or..? what is the rate on your gps unit? i am currently running with a very old gps unit i had laying around that issues 1hz at 4800bps. dog slow. so slow that streaming in nema data from the thing was affecting the gyro integration. i wound up going to software serial and processing gyro and accel data rates in-between bytes of data as the nema sentence streams in from the slow ass gps. it's basically a big state machine on a quick cycle loop. anyway, cool stuff. now lets see the video of it running on the bike

[headshrink]

[rant]
The picture of the Tesla cockpit looks pretty cool, but practically I hate, hate, HATE touchscreens in cars. I put one of those double-DIN touchscreen units in my old Exploder, and found the distraction level went up at least 10-fold. Without being able to feel buttons, you have to take your eyes off the road. Road bumps/vibration also caused me to constantly hit the wrong button (designed way too small and close together to be practical anyways). As touchscreens are being integrated more and more, it's becoming even more difficult to keep eyes on road. I can choose not to use my radio, but with other car systems are being interfaced through the touchscreen..... no good. With the exception of initial set-up, I don't want to go through a single menu when I drive my car! Plus, more to break, and more $$$.

I can no longer hide the fact from myself that I'm avoiding work.... dammit, this is more fun.
[/rant]

[alex.s]

Originally Posted by headshrink

[rant]
The picture of the Tesla cockpit looks pretty cool, but practically I hate, hate, HATE touchscreens in cars. I put one of those double-DIN touchscreen units in my old Exploder, and found the distraction level went up at least 10-fold. Without being able to feel buttons, you have to take your eyes off the road. Road bumps/vibration also caused me to constantly hit the wrong button (designed way too small and close together to be practical anyways). As touchscreens are being integrated more and more, it's becoming even more difficult to keep eyes on road. I can choose not to use my radio, but with other car systems are being interfaced through the touchscreen..... no good. With the exception of initial set-up, I don't want to go through a single menu when I drive my car! Plus, more to break, and more $$$.

I can no longer hide the fact from myself that I'm avoiding work.... dammit, this is more fun.
[/rant]

as with all non-driving-related accessories in cars (gps, radio, cell phone, passengers, climate control), you should not be making adjustments while in motion. you sir, are a distracted driver.

[TnNinjaGirl]

That's why motorcycles are nice. No driving aids. No buttons to fiddle with. Just you and the machine, and a badass DIY HUD display!

[linkinpark9812]

Originally Posted by alex.s

fun project. nice rat's-nest you've got there not a fan of making circuit boards i guess? curious though, why did you split it into 3 chips? just couldn't have the gps uart process loop fast enough to have a reasonable update rate while running the rest of the inputs? or..? what is the rate on your gps unit? i am currently running with a very old gps unit i had laying around that issues 1hz at 4800bps. dog slow. so slow that streaming in nema data from the thing was affecting the gyro integration. i wound up going to software serial and processing gyro and accel data rates in-between bytes of data as the nema sentence streams in from the slow ass gps. it's basically a big state machine on a quick cycle loop. anyway, cool stuff. now lets see the video of it running on the bike

Didn't want to drop the money, especially when I kept making changes. I actually had to make two small changes afterwards (Apparently didn't catch everything until testing), but was easy to fix with it being all through-hole. Plus def improves soldering skills!

I probably could have gotten away with putting the GPS function on the Main PIC too, but the GPS only seems to run reliably at 9600bps. I also needed the extra pins for I/O's. I could have used an I/O expander, but I also needed some PWM pins as well, so it worked out for the better IMO.
However, I REALLY had to put the OLED on its own. The OLED is quick, the NOR Flash is not. Even with a dedicated PIC for the OLED, you can see all the initial loading of the main screen, though the refreshes of the items look instantaneous. That made it grueling when the PIC got stuck doing something else and the screen would get jittery, especially with some of the animations on the screen.

I know I could have gotten away with all text, but I do like graphics in GUIs, and I was pushing myself with my programming skills to see what I could make it do. (BTW, it is all written in C).

For example, when changing gears, they fade out and in (they used to slide out and then in from the left side of the screen, but the NOR lag didn't make it look the greatest), the fan spins when the coolant fan is on, etc.

And what is cool is I can take the inputs from the bike and make different things happen. For example, when the hazards on the bike are kicked on, the Aux LEDs strobe.

[Alex]

Originally Posted by TnNinjaGirl

That's why motorcycles are nice. No driving aids. No buttons to fiddle with. Just you and the machine, and a badass DIY HUD display!

From another thread:

Originally Posted by Alex

One of the riders in this year's event recently switched bikes to a Wing. He thinks he has the new one set up reasonably completely at this point:

[linkinpark9812]

Originally Posted by Alex

From another thread:

Damn! And I thought my HUD, along with my volt meter and coolant temp meter, were pushing the limit of "information overload".

[alex.s]

Originally Posted by linkinpark9812

Didn't want to drop the money, especially when I kept making changes. I actually had to make two small changes afterwards (Apparently didn't catch everything until testing), but was easy to fix with it being all through-hole. Plus def improves soldering skills!

I probably could have gotten away with putting the GPS function on the Main PIC too, but the GPS only seems to run reliably at 9600bps. I also needed the extra pins for I/O's. I could have used an I/O expander, but I also needed some PWM pins as well, so it worked out for the better IMO.
However, I REALLY had to put the OLED on its own. The OLED is quick, the NOR Flash is not. Even with a dedicated PIC for the OLED, you can see all the initial loading of the main screen, though the refreshes of the items look instantaneous. That made it grueling when the PIC got stuck doing something else and the screen would get jittery, especially with some of the animations on the screen.

I know I could have gotten away with all text, but I do like graphics in GUIs, and I was pushing myself with my programming skills to see what I could make it do. (BTW, it is all written in C).

For example, when changing gears, they fade out and in (they used to slide out and then in from the left side of the screen, but the NOR lag didn't make it look the greatest), the fan spins when the coolant fan is on, etc.

And what is cool is I can take the inputs from the bike and make different things happen. For example, when the hazards on the bike are kicked on, the Aux LEDs strobe.

SD cards are quite a bit quicker than older MMC flash cartridges and pretty easy to use on microcontrollers. they are basically a 2 way uart device. you can find small boards to act as intermediary for a few dollars that pass through i2c or spi. but it sounds like you just need more ram so you can keep more images in fast memory. maybe next version you could use a raspberry pi. 500mhz, 512mb ram, built in usb and storage. makes a lot of things really easy. but you gotta plop down the $50 or whatever. but then you can use fancy screens. and wifi and crap.

[linkinpark9812]

Originally Posted by alex.s

SD cards are quite a bit quicker than older MMC flash cartridges and pretty easy to use on microcontrollers. they are basically a 2 way uart device. you can find small boards to act as intermediary for a few dollars that pass through i2c or spi. but it sounds like you just need more ram so you can keep more images in fast memory. maybe next version you could use a raspberry pi. 500mhz, 512mb ram, built in usb and storage. makes a lot of things really easy. but you gotta plop down the $50 or whatever. but then you can use fancy screens. and wifi and crap.

Ironically, I bought one, and was going to use it as a replacement. Was going to use a basic FAT file system so I could just "drag" the images onto the card. Right now, they have to be embedded at a particular memory location. Somewhat a pain in the ass in the beginning. And I did not feel like getting the FAT libraries working for the PIC, as they weren't 100% complete and took up a lot of valuable programming memory, so I decided not to use it.

Guess I should have just used the SD card regardless, even without a file system... Oh well.

And RAM is "non-existent" on embedded microcontrollers, at least for storing anything large, like graphics. My goal was to create a custom system, hence not using a "prebuilt" Arduino or PIC board, or something like the Raspberry Pi, though I would like to mess with one.

This way allows me to make my own board to have all the proper connectors I need and make it look somewhat neat, like this:

[headshrink]

Originally Posted by alex.s

as with all non-driving-related accessories in cars (gps, radio, cell phone, passengers, climate control), you should not be making adjustments while in motion. you sir, are a distracted driver.

That's assumed, but it shouldn't be difficult to be able to turn down the volume while driving if it were to become a distraction.

[headshrink]

That Goldwing up there should be complete with one more GPS.