Student Projects
by Ramzy Nawas, Daniel Peterson, and Kramer Schlaudt
Overview Recently, National Instruments prototyped an electric bicycle, called the NI-eBike, made from low cost components. For this project, the team will develop a dynamic model of the bike and implement a PID controller for a cruise control that optimizes battery life. Additionally, the team will create a 3D model of the NI-eBike in SolidWorks and combine this graphic model with the dynamic model to create a 3D simulation of the bike. All the control and simulation of the bike shall be developed in LabVIEW. The NI-eBike The eBike was originally created as the pet project of National Instruments’ international marketing director David Wilson. Mr. Wilson began constructing an intelligent bicycle in his garage based on a Schwinn mountain bike frame. Soon, the bicycle had a touch screen that automatically updated current wheel speed and bicycle velocity. The eBike was originally prototyped one year before this project by a senior design team also from The University of Texas at Austin. While the previous group succeeded in adding a DC Motor, a continuously variable transmission (CVT), and a PID Controller to the eBike, this was not so much an engineering undertaking as a feasibility study. National Instruments’ eBike utilizes their proprietary CompactRIO system for the vehicle’s control. SolidWorks Modeling The design team has finished the modeling for the bike. While the corporate liaisons at National Instruments did not require extreme accuracy with the graphical model, the group, and most decidedly Ramzy, decided to go above and beyond with this portion of the project. The team appropriated a cubicle on NI's campus and meticulously modeled the device, relying on a close proximity to the prototype to permit easier measurements. It was too difficult to see the exact way components of the bike fit together or predict exactly what measurements would be necessary to produce a very precise 3D image. A couple sample e-Bike components are shown below, measured and reproduced in exact detail: While some of the pieces are being slightly updated or refined, the model, as a whole, is finished and compiled. Here is a screen shot of the whole assembly in SolidWorks. 3D Picture Control Kramer has become our inhouse 3D Picture Control expert. The entire group spenta few hours together figuring out the basics of its use, but he has been the one figuring out how to specifically import SolidWorks files into LabVIEW. With some help from online resources, Kramer has managed to the various bicycle parts and combine then in one VI. Even better, the wheels spin around he axle axis in response to an input rotational velocity. The current wheel operates amazingly smoothly when put on a changing signal input (like a sin wave). We have taken the liberty of adding a blue sky to the background of the bike and making a road like surface beneath it for added effect. Here is a screen shot of the bicycle with wheels turning in LabVIEW's 3D Picture Control environment: A video of this model running is available at the bottom of this page, titled Running Bike. We still have a few concerns with how 3D Picture Control works within the LabVIEW environment. Namely, 3D Picture Control didn't want to import anything more than relative geometry when we attempted to pass it STL files. We countered this by passing it the more information dense VRML files. Still, there seem to be a few odd bugs associated with this module. Namely, the wheels descend away from the rest of the frame as the rotational velocity is increased due to the complications of defining multiple axes in LabVIEW's 3D Picture Control. For now, there is a simple, linear corrector that translates the bike wheel's up as velocity increases. While this looks fine, it limits that top speed, as, after a while, the displacement's response to velocity change becomes nonlinear. There are other methods of fixing the bike's rotation issues. For instance, you can add two 3D Picture Windows, each with a separately defined rotation axis, and overlap them in such a manner that it looks like one control. This has an infinite speed range, but doesn't look as nice as the previous method. Here is a picture of the LabVIEW code that runs the graphic model. This was later split into two sub VIs. The object creation set was called PictureMaker.Vi and the object rotation code was called PictureRunner.VI. Analytical Model Assumptions The group has also settled upon a simplified bicycle model to analyze. This involved reducing the functionality and mechanics of the bike to a more basic model that will, hopefully, still produce accurate results. These assumptions had a range of causes from practicality to necessity. The first set of assumptions were done because predicting bike behavior becomes exponentially more complicated if certain traits are allowed to remain in the model. It was assumed that the tires do not slip, that the frame is solid (no bending or deforming), and the normal force is evenly distributed. It was also assumed that both wheels only make contact with the ground at a single point.These assumptions allow us to make a more exact model for steady state operation, which is ideal for cruise control modeling. Some of the conditions, especially allowing tire slippage, also require much higher level physics and mathematics that have more difficult and trying solutions. The team also assumed that the lift coefficient is negligible in this matter, which is a fine assumption for a bicycle. Even on much faster motorcycles, the lift force is usually not a large factor. With lift's depedence on the square of the velocity, neglecting it for a bicycle should not harm accuracy much. Finally, the modeled was reduced for practicality's sake. Parts of the team, Daniel especially, savored the challenge of developing a 3D model for the bike. The 3D kinematics that would predict bike tilt on a turnrequire detailed knowledge of mass distribution of the bicycle and rider, which would be difficult to acquire readily. As a final blow, the e-Bike currently has no sensors to measure handlebar angle or bicycle tilt, thereby drastically increasing the difficulty of acquiring accurate test data for model validation. In the end, the group reached the decision to neglect turning or rolling on the bike and only allow 2D motion. The current bike model includes 2D effects, rolling resistance, air drag, and inertial effects. Analytical Model Bond Graph Armed with these assumptions, the group constructed a causally augmented bond graph of the e-Bike. This model had only one state variable, which makes sense given the no slip assumption. Here is a picture of the e-Bike bond graph: The above model does not take into account the effect of the transmission. The torque given to the bike is left general as a T(t). The continuously variable transmission should be easy to add to the model because the controller put on the device was added by the last design team and is a simple if then set of constraints. THis means the design team can account for its behavior with a simple formula node full of if statements. Despite two cases of derivative causality, the model can be solved for one equation of motion utilizing a motor equation. This motor equation's parameters came from the following motor curve: When solved for the change in angular momentum of the back wheel, the equation looks like: LabVIEW Model of Dynamic Model The model has proved to be more cluttered then originally intended. Here is the above equation represented by a LabVIEW Simulation Module block diagram: Quite a mess, isn't it? Because of this, we have produced the same information in the form of a formula node based VI: We like this form better because it is quite a bit cleaner and easier to read. It should be noted that most model parameters that are currently inputs will later be changed to constants. First, however, the design team must establish accurate values for them all. Some of the parameters, like the coefficient of friction and the bike mass, will be left as inputs so they can be varied and the overall system response can be gauged. Control Scheme The eBike has a very odd control scheme. Thanks to a long email discussion with NI engineer Asa Kirby, we have been able to construct a flow graph that shows how the eBike operates at a system level. With the above diagram, we have been able to construct a high level LabVIEW VI that will help us model the overall dynamic motion. This VI has been synced with the 3D Picture control VI to provide one complete model of the bike. After a few tests, we gathered the necessary parameters for the bike, meaning we are ready to start actual simulation and correction of the eBike model. There were a few difficulties connecting the two VI systems. Mainly, there was the timing and space conflicts of Control Design and Simulation Loops and 3D Picture Control. This simplest and most effective method of data visualization that we found was to export all the simulated data from the CD&Sim loop to a while loops, which then steps through the data while running the 3D Picture Control Model. Here is an image of the LabVIEW overall system VI. Here is an image of the front panel of the combined VI running using the offset 3D Picture Control method.
Finally, using several frames, the team was able to construct a combined dynamic and graphical model that would update in real time and permit rotation of the wheels in the graphical model. The front panel, using the two window method, is shown below. And here is the Block Diagram for the above VI. Testing After constructing a combined model, the team exported TDMS data from the actual eBike for simulation testing. After much model refinement, the project ended with the final result below. These results are less than ideal, we realize. In trial one, the left plot, the simulation had an average difference from the actual eBike of 0.88 MPH and a maximum difference of 2.1 MPH. In trial two, the right plot, the simulation had an average difference of 1.28 MPH and a maximum difference of 2.4 MPH. Most of this error is due to motor model error. The motor model we used above is wrong because the curve the previous design team used is actually for the 250W version of the motor. Even worse, the internet has many reports of the curve itself being incorrect. The team finally did a few tests to get the parameters used in the above plots, but it was not severe or thorough enough testing. NI needs to spend some time testing the motor or spend some money to get a new motor, preferably with an true motor curve. In order to see if the rest the dynamic model was sound, we did some fit testing to see if motor parameters could be made to make the models overlap. The result is shown in the picture below. Clearly, our model can be correct with the correct motor parameters. Cruise Control The team put a rudimentary cruise control on their real time, framed model to see if cruise control is feasible on the eBike. Initially, the team simply put a switch and a feedback loop to make the bike's simulated output velocity the new input velocity. The results were not as expected. The thick black line in the plot indicates where the cruise control was turned on. Clearly, the velocity trends toward zero. This is because the output velocity that was generated has a relatively high velocity request. When the lower, output velocity is cycled back through the PID controller, it generates a new motor voltage that is lower than the previous motor voltage. This situation feeds back upon itself as the motor continually gets less voltage and trends the velocity toward zero. The team corrected this by adding the following bit of LabVIEW code. It essentially checks to see if this is the first step that has the cruise control turned on. If it is, the output velocity from the model is stored and that constant signal is used as a velocity request. The resul of this code is shown below. Again, the thick, black line shows where cruise control was turned on. |
