Weekly Updates

Week 1 (March 3rd)

The focus of this week was to finalize any parts that needed to be ordered and to  begin researching the exact communication protocols we would be using and how to implement them. We went through and tweaked some hardware on an old skateboard that Dhruv had and have it physically setup with a motor mounted as well. We are currently waiting on the pulley and timing belt to arrive along with the charger for the battery, but otherwise the skateboard should almost be testable in terms of a basic electric board with zero modifications. 

In terms of our modifications, we have begun looking into VESC tool, which is a programming tool developed by Benjamin Vedder, the creator of the ESC (electronic speed controller) that we are using. I had looked into this tool many years ago when initially trying to build an electric skateboard but did not understand what UART was. Now that we know, we can begin using the tool to try and understand a bit better how the ESC works so that we can begin figuring out how to communicate with it via this protocol. All of this is taking a substantial amount of time to research, and we are also trying to knock out Lab 6 so that we can focus all of our attention on the project.

As far as the nunchuck application goes we are currently waiting on a part to arrive to interface with the Wii Nunchuck itself. We have begun to set up the I2C protocol so that when the parts do arrive it should be easy to interface with the board itself, as it only requires power from the STM32 board and communicates using the SCA/SLK ports. Once it arrives we plan to use Termite to test the input of the control stick.

Week 2 (March 10th)

After some digging we found that the nunchuck controller uses 3.3V power, which is convenient for us with the STM32 board as we will not have to regulate the voltage from 5V, which would cause erratic data or possibly damage the controller. The "data" and "clock" lines of the module go to the SDA and SCL pins respectively on the microcontroller. The part has not arrived yet, but we have written debug statements to test it once it arrives.

All of the parts for the skateboard half itself are here and we are working on communicating with it using UART. As a start, I am working on building a project that sends signals to the board, and from there we will determine the values that we will need to translate from the nunchuck.

Week 3 (March 17th)

There are some problems interfacing with the nunchuck, it seems that not all nunchucks are created equal, as other manufacturers have used different addresses than what Nintendo initially designed for them. The project is coming along and hopefully, the microcontroller should be able to communicate with the skateboard so that we have a working demo. The nunchucks are also old so we are unsure if there are any problems with them individually, but thankfully we have multiple to experiment with.

The skateboard half needs with using UART and we are hoping to choose the values from the nunchuck once the Nunchucky module is implemented correctly. Once this is done it is just about setting up the board so one can hold on to the power source for the STM32 board while riding.

The VESC communicates over UART using packets with the following format:

• One Start byte (value 2 for short packets and 3 for long packets)

• One or two bytes specifying the packet length

• The payload of the packet

• Two bytes with a CRC checksum on the payload

• One stop byte (value 3)

We wrote some basic code that should be able to compile a UART packet, it is just a matter of figuring out exactly what the payload needs to look like so that the motor operates as intended.

Week 4 (Finals!)

Wii finished!!! Spent several hours every day for the past week working on the project and eventually came to a decent stopping point. A few things changed since our initial design though:

We used ADC to control the VESC rather than UART as the specific UART packet that the VESC requires was too complex for the time available. PPM was another option, but ADC made more sense as it was something we had directly covered in the scope of this class. The nunchuk code allows the programmer to configure any of the buttons or directions, but for our purposes only the forward and reverse throttles were used.

Right now, the controls aren't 100% accurate and definitely require some fine tuning in terms of playing with the exact DAC values to make it run smoothly. That being said, we felt as though a lot was accomplished and were satisfied when we saw that suddenly the motor started rotating. Visualizing the duty cycle/current on VESC tool also helped us with configuration. Overall, a tough challenge but rewarding at the end.