Menu ▾ ▴

VUE32

Back to the OpenECoSys Main Page

Overview

[-img src=VUE32 Enclosure.JPG: missing =-]

Within the framework of a Capstone Project, twelve students in mechanical engineering and fifteen students in electrical engineering chose to design and build an urban electric vehicle with active torque vectoring. As there is actually no such thing as a freely available car control architecture which would allow us to test and implements our ideas on an existing vehicle, we designed one. The approach taken favours a highly modular hardware architecture, built around multiple VUE32 boards and a PandaBoard embedded computer. This page covers the VUE32 module.

This project is released under an Open Hardware licence (OSHW).

For additional details, please refer to Projet VUE's official web page: <http://projetvue.com/>

The Car

[-img src=Vue completed.jpg: missing =-]

Videos:

Specifications:

Official specifications obtained from our tests.

  • Autonomy: 45km
  • 0-60kph: 4s
  • Top speed: tested up to 75kph (can go up to 110kph)

For additional details and pictures of the car, please refer to Projet VUE's official web page: <http://projetvue.com/>

Functionalities and details

  • PIC32MX795F512H Microcontroller
    • 80MHz, 1.56 DMIPS/MHz, 32-bit MIPS M4K® Core
    • 512K Flash, 128K RAM
    • USB 2.0, 2 x CAN2.0b
  • 8x Digital I/Os, 0-3.3V (protected)
  • 4x External 10 bits ADC 0-3.3V (protected, filtered)
  • 2x Speed sensor inputs, compatible with standard car's magnetic speed sensors
  • 4x 12V 10A power outputs
  • 2x 2A motor driver outputs
  • 1x I²C
  • Onboard sensors: temperature and battery voltage
  • Compact design
    • 4-layers 95 x 54.25mm PCB
    • Custom enclosure
  • Open source hardware, Altium files available
  • Open source software, based on the [NETVProtocolStack]

Detailed hardware description

[-img src=Diagramme vue32 englishonly.png: missing =-]

Schematic

[-img src=Sch topsheet.png: missing =-]

Complete PDF Schematic: PDF

Page by page description:

  • p. 1/10: Top sheet
  • p. 2/10: 4 channel analog inputs. Details: [VUE32_4CH_ANALOG]
  • p. 3/10: CAN
  • p. 4/10: 2A DC Motor driver
  • p. 5/10: PIC32
  • p. 6/10: Power output. Details: [VUE32_PWR_OUT]
  • p. 7/10: Digital I/Os
  • p. 8/10: Speed sensors. Details: [VUE32_SPEED]
  • p. 9/10: Supplies. Details: [VUE32_SUPPLIES]
  • p. 10/10: USB-Serial

General comments:

  • Additional information pages are supplied when the comments on the schematic were not judged complete enough. Feel free to request more information.
  • Partial assembly is used to keep the cost at a minimum
  • There is only 1 USB connector, even if there is on-board USB and a USB-Serial bridge. The later one was added only as a security (in case we couldn't use the USB stack due to timing considerations). As the onboard USB works flawlessly, the USB-Serial peripheral is not used.

PCB

2D PCB Top view [-img src=VUE32 1 0 2D.png: missing =-]
3D PCB Top view

Top Layer: signals [-img src=Pcb l1.png: missing =-]
Inner Layer 1: GND plane [-img src=Pcb l2.png: missing =-]

Inner Layer 2: power planes [-img src=Pcb l3.png: missing =-]
Bottom Layer: signals [-img src=Pcb l4.png: missing =-]

General comments:

  • 259 components, 793 pads, 536 via/holes, 94 x 54.25mm
  • We used Labo Circuit's Standard specs: http://golabo.com/en/documentation/technical-specifications...
  • The assembly was done on a pick and place, reflow soldering
  • 97.7% of the components are on the top layer to reduce the assembly cost (single stencil). The only components on the bottom side are optional jumper resistors (in an easy to solder 0603 package).

Simulations

A couple simulations were made in LTSpice. The files are in the main archive. Here's an example, the power output:

[-img src=Ltspice power.png: missing =-]

Enclosure

Custom enclosure, designed especially for the VUE32 board:

3D animation of the first design: http://jfduval.ca/ftp/vue/VUE32_animation.mp4...

This design offers the equivalent of an IP31B protection:

  • IP31B: Solid particle protection: >2.5 mm (Tools, thick wires, etc.)
  • IP31B: Liquid ingress protection: Dripping water (Dripping water (vertically falling drops) shall have no harmful effect.)
  • IP31B: Protected against access to hazardous parts with fingers

For all the details: <http://en.wikipedia.org/wiki/Ip_rating>

This is far from being perfect. It was designed that way to keep costs down and to simplify connector selection. In our car, they are placed in protected areas. The next step would be to pick new connectors and design a sealed enclosure to reach at least an IP64D (or even IP66D) rating. That way, we could place these boards everywhere in the car, not just in protected areas.

Connectors:

An example of what could be used is the TE Connectivity Ampseal series. The 1-776163-1 is 12$, has 35 contacts rated up to 17A each.

Peripherals

Here is a brief list of the automotive peripherals that we use with the VUE32:

Sensors and user input:

  • CAN steering wheel position sensor
  • Yaw and lateral acceleration sensor (analog)
  • Lights lever
  • Wipers lever
  • Key, Drive/Park/Reverse switch
  • Battery current sensor
  • Magnetic wheel speed sensors
  • Doorlock switches, windows switches
  • Pedal position sensors (analog)

Output peripherals:

  • All kinds of lights: low beams, high beams, flashers, ...
  • Wipers: arms and washer pump
  • Power windows
  • Door locks
  • Pumps
  • Blowers
  • Audio amplifier enable
  • Relays

Excellent source of information: Evilution <http://www.evilution.co.uk/>

Cables and Connectors

Logic connector: [-img src=Con logique.png: missing =-]
Logic connector (zoom): [-img src=Con logique zoom.png: missing =-]

Power connector: [-img src=Con power.png: missing =-]

A spreadsheet with all the wiring information of our Smart is available here: http://sourceforge.net/projects/opene.../download

Scientific Article

Full paper available here: http://sourceforge.net/projects/opene.../download

Software

Embedded software - PIC32: GitHub VUE32

Final code is in VUE32_2_0.

Panda Board data acquisition and GUI: GitHub SigmaBoard & GitHub SigmaScreen

Does it work?

Of course! We waited a long time before releasing the details to be sure that the boards were thoroughly tested. While v0.1 (our initial design) had some issues, v1.0 is almost perfect.

Here is an extract of our QA sheet, as of December 13th 2012:

[-img src=Qa 13122012.png: missing =-]

An example of what we went through to qualify our power outputs. Notice the size of the power resistor compared to the size of the board!

Power output qualification


[-img src=Power test.JPG: missing =-]

Known issues

  • Analog inputs: wrong resistor value. Refer to [VUE32_4CH_ANALOG].
  • Can't do hot power swapping. Refer to [VUE32_SUPPLIES].
  • CAN resistor: wrong connection, the resistor should be wired between CANH and CANL

Pictures

[-img src=IMG 0298.png: missing =-]

Freshly assembled VUE32 v1.0

[-img src=Vue32 1 0 19092012 3.JPG: missing =-]
[-img src=Vue32 1 0 19092012 4.JPG: missing =-]

[-img src=Vue32 1 0 19092012 5.JPG: missing =-]
[-img src=Vue32 1 0 19092012 6.JPG: missing =-]

Fully assembled VUE32 v1.0 with enclosure

[-img src=Enclosure 1.JPG: missing =-]
[-img src=Enclosure 2.JPG: missing =-]

[-img src=Enclosure 3.JPG: missing =-]
[-img src=Enclosure 4.JPG: missing =-]

[-img src=Enclosure 5.JPG: missing =-]
[-img src=Enclosure 6.JPG: missing =-]

Design files and license

Hardware files

This project is licensed as Open Source Hardware. Here is an extract of the definition, according to Sparkfun:

If a device or project has this icon, it means the plans must:

  • Contain editable source files
  • Allow for modification
  • No discrimination against groups [...] or technology [...]
  • You are allowed to sell your version. No -NC limitations.
  • May require attribution

All the details are available on their website: <https://www.sparkfun.com/static/oshw/>

We are not selling this board. This project was purely educational, not for profit. By releasing this design we hope we will help the development of electric cars of all kinds.

Let us know if you use the files and give us credit. That's the least we can ask. Contact: j f d u v a l @at@ a q r a .dot. c a.

All the design files are available here: http://sourceforge.net/projects/opene.../download

Free Altium Viewer: http://www.altium.com/community/downl.../viewer-edition.cfm

Software / sources

See Software.

FAQ

Many good questions and comments were made on Hackaday and by email. In this FAQ, I’ll try to clarify some points:

  • Why do you use an electronic board instead of wires for simple stuff (door sensors and lights, turn signal lever, etc.)?

First, it reduces the number and the length of wires. Copper is both heavy and expensive, so there is a real gain in minimizing its use.

Second, we can program more “intelligent” functions (single tap opens the window, auto door lock when you start rolling, turning off the roof light when the door stays open too long, etc.)

  • What happens if controller fails and people are locked inside vehicle during accident or car going into deep water?

It’s no different than in any car. We use the manual override.

  • Open controller but closed motors?

This page deals only with the VUE32. We are also looking at the possibility of releasing the mechanical plans under an OSHW license. As for the motors, well, we can’t design and build every single component of the car in a couple months, so we had to use some off the shelf parts. The good news is that a new team can now use our VUE32 and focus on designing an OSHW motor!

  • Why didn’t you buy ready-made electronics at a scrapyard?

Our plan is not to do an exact replica of a Smart car. We are trying a new control architecture. An open design like the VUE32 allows us to try a lot of functionalities!

“Smart” parts are expensive. It’s cheaper to use wires.

Copper is getting more and more expansive: http://www.infomine.com/investment/me.../all/. If we can regroup a lot of functions on a cheap, polyvalent computer board we can gain a lot.

  • Can we use it for conversions? In a different car than a Smart?

Yes. It’s an open design, made to be used with any brand or model or car.

  • Is it rugged enough for real-world conditions?

Not yet. Please see the Future and Security sections.

Thanks for the feedback!

Security / Legal

This is only a prototype!

  • We are NOT responsible for any problem or accident linked to the use of this board
  • Use and modify AT YOUR OWN RISK

Use this design as a reference only. Our car will only be tested in a closed circuit.

Future

Here's a list of improvements and ideas for the next revision:

  • Fix the known issues
  • The programming connector is too fragile. A better, more rugged part should be used (ex.: Molex Picoblade)
  • We broke many wires on the Logic connector (Molex iGrid). A more robust connector could be used.
  • Better IP protection (see Enclosure)
  • Bigger SMT components (see below)
  • Improved protections

Please note that v1.0 is NOT READY for real word usage. Yes, it works well in our Smart. No, it probably won’t sustain years of abuse (thermal cycles, vibrations, humidity). The beauty of OSHW is that you can now improve on this design!

Luky, who’s in the automotive engineering field, contacted me about this design. He did an in-depth analysis of the design and he offered a lot of good ideas for the next generation. Here is a summary of our email exchange:

Luky: You should seriously consider to use a casting compound. Vibrations and water condensation are very serious problems for automotive electronics.

Me: The only reason we are not using any at this time is that we want to be able to work on the boards. I'll look at removable conformal coating to see if we can apply some on the boards (Update 12/12/2012: conformal coating was applied on all our boards. MG 419c http://www.mgchemicals.com/products/p.../acrylic-conformal-coating-419c/) when they'll be fully tested in the car. Also, this is an academic project. The car will be used only for a couple hours of testing, in controlled conditions.

Luky: Removable compound is "only" a protection against moisture / dirt etc. For a mechanical protection you will need a "hard" or at least a viscous coating. But I'm not an expert on this.

Luky: The first weak point is the THT-electrolyte capacitor. Cracks are inevitable. SMD Elkos are much more stable, an alternative is an axial Electrolyte capacitor.

Luky: About 0402 components: They have a problem with temperature cycles. If the expansion coefficient from the PCB and the component is different, a large amount of mechanical stress will be created and the small components will simply fall down. Not instantly, but after 1-2 years. Using bigger solder pads ("IPC low density") is an additional help. The other problem is that a high voltage (ESD...) simply jumps over a small component if you don't provide an additional Spark Gap.

Luky: I noticed that you are using a FT230XS. This chip has a problem: (3.1.1 USB Data Transfer) http://www.ftdichip.com/Support/Docum.../TN_139_FT230X%20Errata%20Technical%20Note.pdf

Me : I'm aware of this, I received the recall email after the design was sent to fab. Anyway, as mentioned on the website, we only use the onboard USB of the PIC32.

Luky: Transient Absorption Zener Diodes are really important, but they are not suitable for overvoltage Protection, they are made for Transient protection. Don't use a 12V TVS in a 12V System (unless the +12V is really stable), 15V or 18V are a good choice. If you need an overvoltage protection you must consider where the Power is going. The currents can be very high! A circuit breaker is usually a better choice.

Me: It’s not shown on the schematic but we have an in-line fuse with each board. Our 12V should be stable as we don’t have an alternator and we are not constantly switching inductive loads. This system will be improved in the next revision.

Luky: If the USB connector is used a ESD-Protection would be a good idea and maybe a common mode choke, considering that you have power Electronic components nearby.

Luky: An old Saying in the Industry is that over 1/3 of the Board is I/O protection...

Sponsors

This project would have been impossible to realise without our generous sponsors. The major ones are: Dassault Systèmes, Enseignement supérieur, Recherche, Science et Technologie Québec, Solaxis, Piktronik, A.M. Midatech, Labo Circuits, Gates and Proto Prototypes. A complete list is available here: http://mecano.gme.usherbrooke.ca/~vue.../sponsorships.html

Authors and Greetings

Contact Jean-François Duval for more information, j f d u v a l @at@ a q r a .dot. ca.

Related Projects

Related

OpenECoSys-Wiki: NETVProtocolStack
OpenECoSys-Wiki: OpenECoSys
OpenECoSys-Wiki: Projects
OpenECoSys-Wiki: VUE32_4CH_ANALOG
OpenECoSys-Wiki: VUE32_PWR_OUT
OpenECoSys-Wiki: VUE32_SPEED
OpenECoSys-Wiki: VUE32_SUPPLIES

Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.