From our first test run at the parking lot.
Kanske världens bästa ingenjörstävling för studenter. 6e plats i design, 5e i endurance, 4e i AutoX, 3a för Business plan => 4e totalt.
Youtube-video från Endurance-finalen:
Vi befinner oss nu i Hockenheim, Tyskland för att delta i Formula Student Germany 2013. Om jag har tid lägger jag upp några foton efter varje dag.
Till hjälp finns verktyg som illustrerar hårrdisknyttjande per mapp. Svaret i Windows finns hos WinDirStat, Mac OSX har Disk Inventory X och Ubuntu Server har ncdu.
As a part of the Embedded Control Systems course we( Brian Bonafelia, Nicklas Gustafsson, Per Nyman och jag) got a task of programming a self balancing robot in Lego Mindstorms (NXT). The benefit of using Lego from a control theoretical point of view is that it has quite bad mechanics, and there demonstrates the strengths of control theory; to compensate bad mechanics with sophisticated software. Focus in the course if mainly not on Lego building but more on creating the mathematical model and programming control theory algorithms corresponding to said model. Now the result with a short video:
Video with more talk and more details:
I helgen åkte pappa och jag ut till Enköpingsbanan för att köra KZ2. Jag hade tidigare köpt en Gopro och såg detta som ett tillfälle att testa den ordentligt och är själv ganska nöjd med resultatet. Bättre hade i och för sig varit att sätta kameran längre fram på hjälmen men då var visiret i vägen. Video:
Kortfattat om KZ2:
DN publicerade idag en liten artikel där Chalmers formula student fick vara med på ett foto och omnämns i två mening. Kul förutom de faktafel som letat sig in. Dels att vi studerar till civilingenjörer, att det inte är en studentföreningen utan en projektkurs och att det inte heller är en racerbil utan en tävlingsbil. Skillnaden är att fokus läggs på själva ingenjörsaspekten och inte i att vinna ett race. Men men, kul att det skrivs något.
[Uppdatering]. Mer fanns att läsa i Högskoleguiden 2013 på sidan 36.
[Uppdatering 2013-03-09]. DN rättade till bildtexten.
The project where I spend most of my time right now is Chalmers formula student where I am Project engineer in the Vehicle electronics subgroup. This post is a summary of the design of the over-all wiring. If I find the time I will also post some more information about other subsystems.
The overall wiring provides electrical power to the components and transfers signal data from sensors to the processing nodes. The overall schematics refer to the design of this electrical system. The schematics are necessary when connecting the electrical system on the car. It is also very useful for troubleshooting and repair of the system.
Our target goals are presented in the table below:
Time to disconnect electronics from engine
Time to check and change fuses
1 min to check. 1 min to change.
Time to check and change relay
Time to check battery and change battery
1 min to check battery with multimeter. 10 minutes to change it.
|Time to reprogram ECU||5 minutes||
The ECU should be easy accessible. As long as the software is working it should be quick.
Time to download data from DAQ
Memory card out from DAQ, into computer, download data and memory card back to DAQ
Mean minimum distance between major electronics failure (after debugging and testing)
Reliable enough to do at least five competitions
Water and dust protection level
The approach when designing the over-all wiring was to start with a low complexity model where the most important subsystems were represented. Understanding the interactions between subsystems is important to get efficient and minimal wiring and therefore the solution model is a good starting point. Designing the vehicle schematics is an iterative process where information is added for most of the new design decisions. The schematics include component specification, choice of connector, pin configurations, connections to the processing nodes, sensors, engine control unit with wiring, generator, fuel pump and power supply.
Protection level IP45 is chosen from pre-study to get sufficient protection from water, dirt and dust. Our assumption when choosing the protection level was that water is a bigger issue than dust since water implies a greater risk for electric failure. IP45 will give protection from dust and dirt above 1mm and protection from ingress of water from a water jet. Going for IP65 increases the protection to be completely protected from dust and protection from water up to more powerful water yet.1 Upgrading the protection level to IP65 to get a safety factor was not too difficult since boxes from Multicomp together with Buccaneer connectors satisfy this specification.
To avoid disturbances cables carrying signals are separated from cables carrying high currents and shielded cables are used in high disturbance zones near the engine.
Connectors for sensors have to have a high water and dust protection level since they will be unprotected by any other component. To get a low maintenance time when dismounting a subsystem from the electronics they have to be easy to connect and disconnect. They should also not be too expensive. TE connectivity Superseal 1.5 series (Figure ) with IP67 will meet this requirement.2
Connectors for the processing nodes was set to have the same requirements as for the sensor connectors but with a constraint that the female connector has to be mounted at the side of the box containing the processing nodes. Circular connectors were chosen since they make the manufacturing of the processing nodes easier compared to using rectangular connectors. It is also much easier to find circular connectors with sufficient water and dust protection. Buccaneer 400 series (Figure ) which have IP68 classification are chosen.
A hole on each side in the monocoque is used for wiring the sensors near the front wheels to the front processing node. Delron Inserts 102 series (thru-bolt) will be inserted into the hole for water and dust protection.
Alternative solutions for the overall wiring were discussed and benchmarked. The main reasons for rejected design alternatives were reduced reliability or increased complexity.
Instead of drilling a hole at each side of the monocoque to transfer a cable for the sensors at the wheels a connector could have been used. We had discussions about using connectors from Deutsch which would be lightweight and robust. The main disadvantage was the wiring inside the monocoque. With a connector the bend of the wires connected to the connector must not get in the way of the driver’s legs. The driver department should be as clean as possible to avoid the driver hitting any protruding parts. Adding a connector would increase this risk and therefore the solution was rejected.
The reason for choosing a two node system was to reduce wiring and divide logging and processing on two processors. A two node system with a CAN bus is much easier to expand than a single node system. Adding more sensors can be done by connecting them to free inputs on either of the two nodes or by adding a new node since a CAN bus is used. One design alternative that was considered was to have small nodes by each wheel with a CAN bus connecting them. This could decrease wiring even further since the distance from each sensor to a close by node would be smaller. The main reason for not choosing this design was to limit the number of developed components. Our recommendation though to next year’s CFS would be to consider this approach.
An alternative to the current solution of connecting the ECU to the rear node via RS232 would be to connect it to the CAN bus5. Since the rear node in this case would not need to handle the communication to the ECU and instead get the data from the already implemented CAN bus communication the processing would be reduced. The same would be true reducing the programming code when using CAN instead of RS232 since the CAN code has to be implemented either way. The disadvantages are added components since the ECU does not have a CAN interface but a RS232 interface. A purchase of a CAN adapter would be needed with increased cost as result. The programming code for communication to the ECU was implemented last year and will hopefully reduce the development time this year which makes the advantages of the CAN interface less important.
Using a serial adapter between the DASH3 and the DAQ would make the dashboard able to read sensor values from the data logger. This solution was most importantly not chosen since it would increase the number of components and the complexity of writing to the dashboard did not seem too great to overcome since the dashboard protocol is open6. Even though Race Technology in an email wrote that the logging capacity would not be decreased by much since the update frequency to the dashboard does not have to be more than a couple of times per second, we were not sure if it would be a limiting factor or not. The safe option was to not use the serial adapter and instead send the data from the front node. The disadvantage of this solution is more development time since routines needs to be programmed for communication between the node and the dashboard. With the serial adapter this is already done by Race Technology.
Connecting the DASH3 to the CAN bus would be done with a CAN adapter. The distance from the DASH3 to the front node is so close that any weight saving due to wiring would not be a factor. The main advantage would be an assumed reduced development time since the sensor data to display on the dashboard would already be present on the CAN bus. Only configuration of the DASH3 would be necessary.
An alternative to the circular connectors in the processing nodes would be rectangular connectors. If the processing nodes are better protected from water and dust this would be a good option since it makes connecting sensors somewhat easier. A disadvantage with circular connectors is that they require soldering or the use of clamp tool. Adding sensors to a rectangular terminal block would be a matter of just connecting wires to the connector block. This connector is for example used on the DAQ (Figure ) which we use for data logging.
To minimize the amount of switches on the dashboard it is possible to combine the switches for ignition, fuel pump and start engine into a switch with multiple states; Off, Ignition, ignition+fuel pump and start engine (with momentary action). The main disadvantage is lost control of forcing the fuel pump to be either on or off. The states of this switch would be:
Ignition and fuel pump
Starter motor. This state would be momentary stable and return to state 3 when released.
The reason this solution was neglected was loss of control of the fuel pump. With a dedicated switch for fuel pump three states can be selected:
No fuel pump
Fuel pump controlled by ECU
Fuel pump forced on
The first approach for the schematic design was to do it by hand on paper (Figure ) and then convert this to 2D CAD software. For developing the vehicle schematics a comparison between alternative software was done. A brief summary of the software comparison test:
ExpressSCH seemed quite good at first but adding components was a hassle.
FastEl did simple tasks complex and lacked user friendliness.
Eagle CAD has two main features: board design and schematics design. Designed for manufacturing PCBs and therefore a lot of features would be left unused when only designing schematics
TinyCAD is a simple and fast program without any advanced features.
TinyCAD was chosen since it got the job done and was fast to work with compared to the other alternatives.
Click on the image and then download it as a png. The schematics file is very big and the image below is just a thumbnail.
Applied to and got accepted to the subgroup Vehicle Electronics to build Chalmers contribution to Formula Student in England and Germany. I designed the electronic architecture in the car, designed and manufactured circuit boards, programmed and wired electronics.