So for my final project for a class, I decided that I wanted to use LabVIEW to control two functions on my motorcycle:
1. When I click the lock button on my wireless remote control (which causes my bike to emit ONE short beep and the hazard lights to flash ONCE), I want my MyDAQ to use the frequency from the hazard light wires to allow power from the battery to flow to the ignition relay and start up the motorcycle. Alternatively, when I click the unlock button on my remote (my bike will emit TWO short beeps and the hazard lights flash TWICE), I want my MyDAQ to use that change in frequency from the hazard light wires to allow power to the kill switch and turn off the motorcycle.
2. I want my MyDAQ to comprehend the voltage difference in the engine thermostat to allow voltage from the battery to turn on the radiator fan when the engine temperature is between 150 and 182 degrees Fahrenheit. The ECU threshold is 177 to 182 degrees Fahrenheit. I want the fan to stay on even if the engine is not running (in which case, I want to make an indicator or boolean on LabVIEW say: "Override engine cooling" to show that the fan should be running if the engine is still too hot.
Here are my understandings and research. Does anyone have any information, suggestions, corrections, comments, etc.? Anything would help, I kind of struggled with this class though I love every minute of learning about controls and automation. Thank you in advance!
Many things are unclear about your "project".
A few more thoughts in no particular order (Assuming we are talking about a real motorbike:
Answers to a couple of comments on your page:
I'll be honest though there are so many safety implications of this I really would think carefully about what you are trying to achieve.
Okay, to clear some things up:
I do have a MyDAQ.
Yes, this is including a real motorcycle.
The wireless remote control is just the same as a fob for a car.
The short beeps are loud and much like ones when locking/unlocking a car, but I don't want the MyDAQ to sense the beeps (audibly), but the frequency of the beeps from the voltage that goes to the horn.
The lights that fash are just the turn signals. They are just a physically visual indicator to the user that the vehicle is being locked/ unlocked (as a car would).
I have not written the code yet because I am still trying to visualize how this will be set up physically.
The temperature is being taken from the engine thermostat that is already on the motorcycle.
I plan to interface the thermostat with the MyDAQ by probing the wires connected to the thermostat and connecting them to the AI channel of the DAQ
Thank you for the feedback.
Thank you for your feedback!
The first consideration when I thought of this project was safety. My professor wanted our final to be something complex (with no sort of rubric handed out or ideas of what to include). Everyone decided to go all the way in complexity in hopes that he would at least say that our final project concepts were "good enough". Now he says that most of us have bitten off more than we can chew, but with no other corrections or guidance we are unsure of what to subtract or completely discard from our projects. Maybe I'm just looking to change my project entirely to something I can handle, but also include at least one of my passions.
Thank you for your responses. I'm also glad that you've thought about how you might implement this Project with a "real motorcycle", and are also cognizant of some of the "problems" with poking around with The Real Thing.
Putting on my Professor Hat (funny shape, about 30 cm square cardboard glued to a beanie, with a silly tassel hanging down), I'd ask "What's the Point of this Project?", or, alternatively, "What is the Title of this Project?". You aren't attempting to make a Controller for your motorcycle, nor are you attempting to create a system to "Monitor Motorcycle Systems during Real-World Driving Conditions", or something like that. If I had to come up with such a title, it might be "myDAQ and the Kawasaki XXXX".
Not to say that wouldn't be a valid Project, but what would be the point? Well, for one thing, you are proposing monitoring several different sensors and actuators, all running in parallel, and "doing various things" based on the readings you get. You've connected "real" sensors and actuators, have a "real" instrument (the myDAQ) that could take the readings, and have "real" problems in actualizing your concept (including such things as matching the signals to and from the myDAQ and the signals to and from the components of the motorcycle (including its key fob).
As a First Step, I'd leave the actual motorcycle out of the proposal, but would leave its "components" (the signal generators and actuators, for which you might not yet have actual knowledge of voltages, currents, frequencies, etc. involved) in place. In place of the physical bike, create a simulated bike, with simulated components.
An exception could be the key fob -- how were you planning to intercept and decode its signals? Are you building a little radio (or whatever it uses -- ultrasound?) receiver that you'd interface to the myDAQ?
As an exercise in LabVIEW, this isn't a bad Project. You have multiple independent, asynchronous Loops, multiple sensors, multiple actuators, multiple decision points. You have the myDAQ that expects (and generates) analog and digital signals of specific ranges and frequencies, and you have the Bike where the signals may need "conditioning" or "modifications" to interface properly with your LabVIEW Hardware. You want something that is modular, parallel, where components can be added or subtracted (why not allow, for example, the easy addition of a temperature sensor on the Brake Pads to warn you if you are braking too hard, or a "Cruise Control" setting to keep the speed constant?).
I would begin by studying the aftermarket remote starter add-ons to get a firm understanding on how they do it and why they do it the way the do. As I am sure there are some safety concerns none of us have thought of that need to be considered.
Thank you for replying and with much information!
The point of this project, in general, was to show that we know how to create systems and circuits using the software and hardware that we purchased from my school. I like the idea of simulating a virtual motorcycle, but I believe one of the components of the project was to sort of control a physical component using the software. He did give us a rubric (I misspoke), it just seems very abstract and vague.
For fun, I developed an NTP server monitor for my Raspberry PI which drove real LEDs to give status, not unlike a cable modem. Blinking yellow = PI has booted, NTP daemon not started. Solid yellow = NTP daemon started. Blinking blue = syncing. Solid blue = NTP running, sync'd with server(s). Solid red = an error occurred.
I guess something like that would check all the boxes. I guess as a bonus, it would show that you can deploy LabVIEW code to a target. I made my code run on both the PI with real LEDs and on Windows, with fake LEDs, just for an extra challenge.
The reason I mentioned it was because it's a lot cheaper to blow up a PI than a moterbike. 😉