Progress Report for Chris Chow


Weeks 1 and 2

Date:08/27/2016-09/02/2016
Total hours: 9 (App development is awful)
Description of design efforts:
  • Set up 477grp4 website via thinlinc using gedit; this will continue to be updated throughout the semester.
  • Research on batteries, battery charging ICs, and motors was completed.
  • Chosen batteries: Li-ion 26650 (26mm diameter, 650mm length), capacity \(\in [3500, 6000]\)mAh. Many of these batteries have been shown to have less than ideal capacities, so it may be necessary to do additional research on which brands to buy.
    Note: Max voltage: 4.2V, nominal voltage: 3.7V, discharge voltage: 3.0V
    Therefore, we will have a voltage range \(\in [12.0\textrm{V}, 16.8\textrm{V}]\) for 4 batteries in series, so all components should run on \(\le12\textrm{V}\) to be safe.
  • Allison and I did preliminary research on motors for an estimate of what kind of power draw to expect. We expected about 5A of stall current, so with \(\frac{6000\textrm{mAh}\cdot 4\textrm{batteries}}{2\textrm{motors}\cdot5\textrm{A}}\), we expect a minimum of 2.4 hours of continuous use battery life, assuming the rest of BB-8's components' current draws are negligible compared to the motors.
  • Chosen battery charging controller: MAX745. This seems to be the charging IC of choice for multiple Li-ion batteries, and it seems like the datasheet is very well documented, including both an evaluation circuit as well as a sample operating circuit.
  • Begin work on BB-8 controller application, got Android Studio set up. We are currently targeting for Android API version 23 (Android 5.0 Lollipop). Documentation for developing Android apps is dense, but \(>90\%\) of sites are outdated and have development guides for older versions (even Android 2.0!). It is unknown as of yet whether we will create an app for iPhones or Windows phones, but it seems unlikely so far. Figure 1.1 shows the current UI appearance, subject to change.

    • Why do we keep following Kyle's design ideas?
    Figure 1.1: Current UI for Android app (click for larger view).
  • Worked on Functional Specifications with the team during mandatory lab, and wrote the Functional Description and Theory of Operation portions.

Week 3

Date:09/03/2016-09/09/2016
Total hours: 9 (Paper mache is life)
Description of design efforts:
  • Set up version control for each of the BB-8 components: Main Repository, Website Repository (These are both private at the moment), updated reference documents for the project.
  • Most of the time spent this week was on building BB8's chassis. After last week's failed attempt using cheap fiberglass, we purchased much higher quality fiberglass from Amazon and set upon several multi-hour sessions of adding layers of paper mache and fiberglass.
BB-8 After initial paper mache layer. New fiberglass texture. BB-8 After fiberglassing. Paper mache layer over fiberglass.
Figure 2.1: Various stages of BB-8 chassis development (click for larger views).
  • The diameter for the beach ball used was 18"; therefore, the surface area was calculated to be \(4\pi r^{2} = 4 \pi (9 \textrm{in})^{2}\), or approx. \(7 \textrm{ft}^{2}\). The fiberglass cloth came in quantities of 8 square feet, which allowed us to put about one layer of fiberglass on BB-8 per sheet of cloth purchased. Currently, BB-8 consists of 3 layers of paper mache (computer paper), followed by 3 layers of fiberglass, and several layers of newspaper to even out the sphere. We have dubbed this phase of ECE 477 as "Third-grade arts & crafts on steroids."
  • Continued, with the direction of Lab TAs, to research batteries applicable for BB-8. The original idea was to put 4 Li-ion batteries in series (these 26650 batteries), however it was quickly determined that this was a poor idea and would have to buy 8 to reach 10,000mAh, and that we should instead buy a 4S Li-po battery, which comes in a single neat package.
  • Preliminary research on inductive charging is underway, with a focus on the Qi standard. The reference designs and interface definitions will be a good night time read. However, the current availability for consumer chargers is almost exclusively for 5V devices, so I have begun looking into wireless car chargers, especially the Plugless wireless charging system.
  • Helped complete the component analysis including motor and battery selection.
  • Began research on BB-8's voice; while the easiest way of making astromech droid sounds is to store each sound effect from the movie as audio samples, I have been thinking of synthesizing BB-8's voice via the microcontroller; therefore, users would be able to have almost limitless control over BB-8's voice, rather than choosing between predefined sound effects. I have begun to do some spectral analysis of the BB-8's voice (taken from this video), in the hopes of reverse-engineering the effect.

Figure 2.2: Audio waveform of first 10 seconds of the video (click for full size).

Figure 2.3: Spectrogram of the waveform shown above (click for full size).

Week 4

Date:09/10/2016-09/16/2016
Total hours: 14 (What is documentation?)
Description of design efforts:
  • Applied (an entire tub) of wood putty to BB-8, in an attempt to smooth out the various bumps caused by the unevenness of the beach ball and countless layers of paper mache and fiberglass. The wood putty applies on pink and dries beige; we found out that the wood putty dried incredibly quickly; one half of BB-8 was drying out before we finished appling the wood putty to the other side.
Wood putty application process Wood putty applied.
Figure 3.1: Wood putty application (click for larger views).
  • Went with the team to the EE machine shop for guidance on how to cut BB-8 in half, but had a class while the rest of the team cut BB-8 in half. Pictures of this process are available in the other team progress reports for this week.
  • Worked on the Bill of Materials as well as the Electrical Overview for documentation.
  • Took SparkFun's crash course on EAGLE, and learned how to set up circuit schematics and board layouts. We are currently planning on completing a preliminary schematic design for all of BB-8's electronic components this weekend, and hopefully get the board layout done next week. For the most part, we will be using the SparkFun footprints for our passive components, but will be creating our own libraries for the other ICs.
IRF7303 schematic. IRF7303 footprint (SO-08). MAX745 schematic. MAX745 footprint (SSOP20).
Figure 3.2: Custom parts created in EAGLE (click for larger views).

Week 5

Date:09/17/2016-09/23/2016
Total hours: 26 (EAGLE is life)
Description of design efforts:
  • The week started off with an attempt to finish the layering on BB-8. Water putty was applied at a ratio of approximately 1:3 parts water to powder.
Figure 4.1: Water putty application (click for larger view).
  • The application of the water putty made BB-8 substantially heavier, but it was only until the sanding portion that problems arose. Because water putty was applied to each hemisphere individually, the hardened water putty was quite fragile at the edges of the hemispheres. This, in addition to those edges bearing the load from the rest of the hemisphere, is what we believe to have caused parts of the water putty layer to chip off.
  • I also proofread the mechanical overview before submission.
  • The incredibly large number of hours spent this week were on creating footprints and schematics for the various parts of BB-8. I focused primarily on the SD card interface, the audio amplifier, the wireless charging receiver, and the charging circuit. Originally, we had intended to use the MAX745 as the charger (when we were still using Lithium-ion batteries), but further research quickly revealed that this was not going to be a permanent solution for Lithium-polymer batteries. In our case, with the use of a 3S Li-po battery, we needed charging balancing. Hours of research on various parts by Maxim and TI yielded a few ICs; however, many required control directly from the microcontroller for balancing, which would sacrifice large amounts of GPIO pins. These can be found at on the project repository.
Table 4.1: Parts Created
Part Purpose Symbol Footprint
1N4148-805 0805 Diode Package
AVX 5738 SD Card Connector
BQ40Z60 Battery Fuel Gauge / Charge controller
BQ2947 Overvoltage Protector
CD17308Q3 N-MOSFET
BQ51013B Wireless Receiver
BQ501210 Wireless Transmitter
  • We also created the schematics for various parts.

Figure 4.3: Current Schematic of Everything (I made the wireless receiver, transmitter, charging circuit, audio amp, and SD card connector.)

Week 6

Date:09/24/2016-09/30/2016
Total hours: 5 (And on the 6th week, they rested)
Description of design efforts:
  • Most of this week was spent verifying and validating parts on the schematic. We're updating the BoM with final passive sizes (validating footprint sizes, voltage maximums, values) to ensure our PCB layout will be completely correct.
  • We've been quite busy this week, with various team members having exams and other commitments, but are planning on final validation this coming Sunday.
  • The BQ40Z60/BQ2947 battery monitor circuit has been finalized with adjustments from Allison's validation process as well as comments from Matt.
Figure 5.1: Updated Battery Monitor Circuit (click for full size.)
  • I (finally) got access to the Student Edition of EAGLE, so I will be able to help in the PCB placement this weekend.

Week 7

Date:10/1/2016-10/7/2016
Total hours: 32 (What is a layout?)
Description of design efforts:
  • The beginning of this week was spent validating and finalizing the schematics. Things of note that needed to be changed were capacitor values for the wireless charging receiver, since we have chosen a slightly different coil than the evaluation module, and the resistor networks for the NTC's automatic shutdown capability.
Coil capacitor equations. Coil capacitor calculations.
Figure 6.1: BQ51013 coil capacitance calculations (click images for larger views)
NTC network equations. NTC network calculations.
Figure 6.2: BQ51013 NTC temperature sense calculations (click images for larger views)
  • The majority of my free time spent this week was on board layout. We've decided to use Advanced Circuits as our PCB manufacturer, so our tolerances via sizes are to their specifications. The team has also decided to use a two-layer board, which, while cheaper, is significantly harder to route.
  • We've divided the routing for two people: I'm routing the charging circuit, and Kyle will route the other peripherals. We'll work on routing the microcontroller together.
  • The overall board layout has been chosen, with more sensitive components as far away from the colossal charging circuit and battery monitoring at the bottom-right. Since we have a lot of free space, We plan on making the board smaller (down from 160mm x 100mm).
  • Routing this part of the board has been an ABSOLUTE pain. Our trace widths of 0.2mm and via drill sizes of 0.13 are at the lower limit of Advanced Circuits' tolerances, and many traces will undoubtably be too close to each other. Alas, I have tried my best so far, and hopefully I will only need to adjust routes slightly. We do plan on putting ground planes on the top and bottom layers.
  • Since most of us are away for Fall break, we plan on working on the mid-semester review as we have time, and mostly on Tuesday when we all are back.

Weeks 8 and 9

Date:10/8/2016-10/21/2016
Total hours: 28 (PROTOTYPING)
Description of design efforts:
  • The beginning of this two-week session, I was away for fall break, so I wasn't able to get any work done. However, as soon as I returned, the team and I worked on our midterm design review and continued to work on the PCB.
  • That weekend, I began prototyping the sound system for BB-8. Since the SD card peripheral still wasn't working on Alex's end, (FR_NOT_READY...) I began to attempt to set up the audio without that system.
  • The concept of the audio system is simple: the microcontroller will read the audio samples (from the SD card, a static array, etc.), which correspond to duty cycles that are set for the PWM. Since the audio signal will be passed through a low-pass RC filter with a cutoff right above human hearing perception, and then amplified, the high frequency edges on the square wave PWM signals will be filtered out to reconstruct the original waveform.
  • Setting up the hardware to do that was quite simple, but debugging the STM32CubeMX HAL systems was a pain. It took about 3 hours to figure out two major issues that needed to be addressed: first; that the timer module had to explicitly be toggled in STM32CubeMX to enable the interrupt on that timer - enabling the timer with interrupt mode doesn't automatically do this. Second; that when enabling the PWM, that the channel specified MUST be the channel that is being used - the "TIM_CHANNEL_ALL" variable does not enable the PWM (for some unknown reason); "TIM_CHANNEL_1" must be used.
  • I had a few issues with the audio signal, namely because WAV files are actually sampled at 48000Hz instead of 44100Hz, like most audio files, which caused a little bit of pitch-shifting for the audio. It's not too noticeable, but I've gotten the timer as close to 48000Hz as I can.

Figure 7.1: Working audio shown on the scope (turn sound on!) [Sorry for the vertical video]
  • The second half of the week was spent trying to get SD working. Despite numerous f_open errors of "FA_NOT_READY", or "FA_DISK_ERR" while working on the SD card, I attempted to debug by stepping through each of the functions and seeing where it all went wrong. I got as far as to understand that there was something wrong with trying to initialize the disk (somewhere about 6 function calls deep), until I decided to call it a day. I even added pull-up resistors to D0, CMD, and CLK. The next day, Alex informed me that he had just talked to Team 1 and was informed that they'd just needed to put pull-up resistors on ONLY D0 and CMD. The SD card communication works now...
  • With working SD, I decided to attempt to implement reading from the SD card instead of reading from a static array. To facilitate this, I designed a circular buffer to save memory. The core concept can be found in the ECE362 lecture notes, and I followed them to the best of my ability. I also implemented a function to get the remaining number of spaces available in the circular buffer, which was so that we can keep the circular buffer as full as possible. Currently, however, we can read from the SD card to the circular buffer, but for some reason, the audio portion stops working after it reads from the SD card once. I've been debugging this issue since Thursday, and have my suspicions that the FATFS abstraction code is running too slowly and is being interrupted by the timer interrupt.
  • Lastly, I've set up the BQ40Z60 battery monitoring circuit to test the SMBus connections with the microcontroller. I've hooked up the evaluation module according to the specifications, but for some reason, the eval board isn't turning on at all... I hope to investigate the problem in lab this weekend.

Week 10

Date:10/22/2016-10/29/2016
Total hours: 12 (Glorious Prototyping)
Description of design efforts:
  • Team prototype (Alex and I) came into lab on the weekend with one goal: get the servo, audio, and Bluetooth communication working for lab on Wednesday. Luckily, Alex had the magnificent foresight to assign the audio PWM pin to a pin that could also double as the DAC output of the microcontroller. Unfortunately, the microcontroller in the prototyping kit I was using, the Nucleo-F411RE, doesn't have a DAC. So, we had to merge the two prototyping stations (the bluetooth prototyping and the audio prototyping).
  • Switching the software from using PWM to using DMA was incredibly painless; I had designed the PWM to have a period of 128 timer counts, which translated quite well to the 8-bit (256 discrete values) DAC mode for the STM32. The current audio files are arranged as a sequence of 8-bit unsigned integers, which halves file size compared to a 16-bit PCM wave file. I also have created a simple MATLAB script that converts arbitrary .wav files into our custom audio file format (.bb8 files!).
  • Instead of manually changing the duty cycle of the PWM output before it passes through the low-pass filter, the STM32's DMA capabilities as well as STM32CubeMX's hardware abstraction layer allowed me to simply pass a pointer to the array of values into a DAC initializing function.
  • Currently, we have a 96000 (2 second-long) buffer for the audio samples, but the STM32F4 family of microcontrollers has a built-in set of interrupts for the DMA->DAC transmission that is recommended by ST Microelectonics to use in a two-buffer-system for playing audio of arbitrary lengths. If the need arises to have more free RAM, or longer sounds, I plan on implementing this audio system.
  • Additionally, I discovered that I had been misconfiguring the STM32; my projects had been running the STM32 at 25MHz, instead of 168MHz, which completely threw off any timer prescaler values. Switching the clock rate back to 168MHz allowed me to use the prescaler values that I had calculated, rather than attempting arbitrary prescaler values.
  • However, switching from PWM to the DAC was not all for naught; the servo for BB-8's head motion is powered by the PWM, and configuring it is much simpler than configuring PWM audio. The design of the servo is simple: based on a directional characteristic set by the Bluetooth interrupt, the servo increases or decreases its duty cycle to between 600 and 2400 microseconds, corresponding to a -90 to 90 degree rotation. Thus, on every timer tick, we simply write to the compare register of the PWM channel - a 20ms nominal period for the timer ensures that the PWM timer interrupt won't affect other, much more vital, interrupts.
  • Although both the head servo and audio were working, Team Prototype decided it was time to start integrating the RN4020 Bluetooth code into the current code for the audio and servo. Fortunately, this went off without a hitch; a merge of the two demos was inherently simple, as we've been using our final pinout for the PCB and have been writing fairly modular interrupt-driven code. The modifications to the Bluetooth code were one-liners; simply adding the effect of receiving a command to the command interrupt, we were able to link the bluetooth communication with the audio and servo.
  • I was also tired of using the (albeit wonderful) Bluetooth LE connection app, and decided to implement BLE functionality into the current prototype BB-8 app. Deciding not to reinvent the wheel, I utilized the publicly available Android Open-Source Project (AOSP) Bluetooth LE Generic Attribute Profile sample and apply our app's control fragment to the sample app. Again, connecting the app's bluetooth capabilities to the UI were quite simple, adding callbacks to the button press events that write values to the specific private characteristics for the servo and audio.
  • Overall, this was a huge week for prototyping progress. We successfully completed and integrated Bluetooth bi-directonal communication to/from the microcontroller, reading and playing audio files from the SD card using SDIO, and rotating the head with PWM.

Week 11

Date:10/30/2016-11/4/2016
Total hours: 6 (Why won't you work, BQ40Z60?)
Description of design efforts:
  • This week, I was away at an interview from Saturday to late Tuesday night, so I was unable to get much done during the week.
  • I was in charge of the Reliability and Safety Analysis documentation, which took up a decent amount of time; however, learning about the various parts' failure modes and reliability was pretty fascinating, and we are now slightly more confident that any non-catastrophic shorts or other failures are not likely to kill us.
  • I also re-wired the speaker to be compatible with the board's JST-XH connectors, to begin the migration from prototyping on the Discovery board to finalized systems on the PCB.
  • I also spent another fruitless couple of hours in lab attempting to get the bq40z60 to connect to my computer. I have absolutely no idea why it's not working. The input rail is 15V, there's a load resistor on the output system voltage, and the battery terminals are connected exactly to specifications. None of the powered LEDs are on, and my computer is not detecting any SMBus devices when connected to the EV2300 (the drivers work...). I've gotten as far as attempting to read anything from the eval module, but it says that the "Device is sealed". I don't know if that's because the BQ40Z60 isn't functioning at all, or if that's actually the error that we're getting. It seems like it's reading something, because disconnecting the SMBus connector greys out the connection to the BQ40Z60 information. I'll be sure to ask Matt, our TA, in lab on Wednesday, since he was gone last week. Additionally, what I've noticed is that when trying to send any command, such as "DEVICE_NUMBER", I get the error that the command sent doesn't match the command returned in the read packet.

  • I also soldered a couple of headers and the JST-XH connector for the speaker to our working PCB, in preparation for our stencil's arrival sometime after next Thursday. I hope to get a lot of work done in lab this coming weekend with team PCB, such as getting all of the components (head servo, audio, and bluetooth bidirectional communication) done on the PCB.

Week 12

Date:11/5/2016-11/11/2016
Total hours 16
Description of design efforts:
  • Starting Saturday, we attempted to finish up migrating the prototyping progress (Bluetooth, Servo, Audio) to the pcb. We soldered the SD card connector to the pcb, as well as the audio amplifier circuit. Porting the code to the PCB version went well; we heard some (distorted) BB-8 sounds on the speaker, which meant that reading from the SD card worked perfectly, but, there was probably something wrong with the audio amplifier circuit. However, when we were testing this with the power supply, we accidentally knocked loose the 12V rail from the connector and it brushed over the PCB. This, unfortunately, hit a couple of pins on the microcontroller, internally shorting 3.3V to ground somewhere. This killed our third microcontroller. We then spent the rest of the night desoldering and resoldering our last usable microcontroller onto the PCB, and trying to recover progress we made and then lost that day.
  • In the interim, Kyle and I also made a second version of the PCB, because we only have one backup board. We decided to move (delete) the charging circuit part in the interest of board fab pricing, and fixed the couple of errors that we found on our original design. We're planning on ordering from Elecrow instead of Advanced Circuits.
  • I've been working with the BQ40Z60 battery manager in my "spare" time, and have started probing the SMBus (I2C) packets between my laptop and the evaluation module. It seems like the battery management software by default sends the AlternateManufacturerAccess(), 0x44 - our eval board seems to dislike it and fails to ack, as shown below.
  • However, the BQ40Z60 seems to respond to the regular manufacturer access command, 0x00. So, I've just begun to send some preliminary status commands. Operation status returns 0x004B, which corresponds to 16'b0000 0000 0100 0111, which I believe means that the AC voltage is below the threshold, the charge and discharge FETs are active, and the system is present. This is odd, seeing as the output from the power supply was 15V, which is the nominal voltage. I even upped it to 20V, and the result was the same. I may be reading it wrong.
  • I also sent the permanent fault status command, 0x0053, and received 0x0020 back, or 16'b0000 0000 0010 0000, but it's odd, considering that the command was supposed to return 4 bytes; I'll have to check out the documentation again to make sure I'm definitely not doing something wrong.
  • I also desoldered the microcontroller from our original "dead" board, which fixed the short from 3.3V to Ground in our original board. I then soldered the audio circuit (sans microcontroller) onto the board, and have been testing it with an analog function generator by probing the outputs. So far the frequency response seems okay; the amplitude of the output of the circuit seems to roll off properly. More work will be done this weekend on making sure the audio circuit works before resoldering it onto the working board.

Week 13

Date:11/2/2016-11/18/2016
Total hours 23 (Holy PSSCs, Batman!)
Description of design efforts:
  • We started this week out with a bang! On Saturday, we worked heavily on getting the motor controller soldered onto the board and getting some code set up for interfacing with the motors from the microcontroller. We spent a couple of hours debugging the motor controller; the motor controller was asserting the IS line, or current sense and error signal, whenever the motor was connected to the headers. This was perplexing, as the PWM signals were passing properly through the microcontroller and motor controller, and the current draw never went above 50mA. We thought that the motor controller was reacting poorly to a spike in voltage, so we began to ramp up the PWM duty cycle to see if that would fix it. This seemed to work barely, allowing the motor to spin up from a 0 to 5% duty cycle, but the motor controller would immediately die afterwards. After bashing our heads against the table for another hour or so, we realized that the problem was simple: we had set the current limit of the power supply to 100mA. When the motor drew currents approaching 100mA, the power supply would drop the voltage to compensate for the current, which would trip the undervoltage signal, (in)conveniently located on the IS line. Upping the current limit to 500mA handily fixed the problem, allowing us to start working on the interfacing for forward, backward, and turning commands.
  • At the same time, the mechanical team put together the platform for BB-8's PCB, battery, motor mounts, and upper platform for the servo.

  • Monday was our "miracle weekend" for completing parts of BB-8. We successfully implemented forward, backward, and turning drive controls for BB-8 at the beginning of Monday, and started testing BB-8 to see how the platform would react while inside a ball. It seemed to be able to turn and move fairly well while outside of the ball, but once we put BB-8 inside the ball, it seemed to be much less stable. Putting a makeshift counterweight (a metal clamp) on the underside of the platform seemed to help greatly. This was, however, definitely a temporary solution, and Joe graciously offered to find a counterweight for BB-8 from the EE machine shop. While that was going on, I continued to work on some more interfacing with BB-8. I successfully implemented the Bluetooth LE battery service with the voltage divider alternate battery status monitor. Since the IGNORE_CC jumper is soldered (and none of the battery management chips are soldered onto the working board), our way to determine battery status is with a simple voltage divider connected to the ADC. That way, we scale the 9-12.4V range to a smaller range with a maximum value under 3.3V. Since battery status isn't particularly timing-critical, our interrupt to modify battery level only runs every 5 seconds, and only updates the value if there is a change of at least 1%. I also updated the UI for the Android app to be notified by the RN4020 and update the percentage shown. Below are videos of BB-8 attempting to roll around, and the battery level updating based off of the voltage divider values.
Figure 11.3: Battery status updating in-app. Figure 11.4: BB-8 attempting to roll without a counterweight.

  • BB-8's head is having some issues being attached; because both the servo connection and the head connection are straight magnets, so any tilting of the head disconnects one of the two magnets from the body. We're currently working on a scheme for a curved attachement with the body to keep stable while attached.
  • The last thing we got working on Monday night was the audio (again!). We resoldered the audio amp IC onto the working PCB, and after a couple of minutes of testing, noticing that the output from the audio IC was asserted high permanently... We checked the datasheet once more, and noticed that the shutdown signal was active low. Since the shutdown as floating on the breakout board, we never noticed what the signal should've been nominally. Asserting the shutdown GPIO pin low immediately fixed the audio circuit, and 3 weeks of us thinking that the audio ICs weren't working.
  • Finally, I've started working on our final unused board. I spent lab on Wednesday placing all the ICs onto the board connected to the solder paste, and we reflowed most of the ICs - we didn't have enough time to place all of the passives, though. I am currently in the progress of soldering the rest of the subsystems onto the board, with the power systems coming first.

Weeks 14-15

Date:11/19/2016-12/2/2016
Total hours 7
Description of design efforts:
  • Much of the time spent in lab these past two weeks has been finalizing work on the mechanical portions. We finally curved the head magnet platforms on both the body and the head - this gives the magnets a much more uniform connection to the internal parts, as well as moving the points of contact from the middle of the magnet platform to the magnets themselves. This resulted in a much more stable head connection that doesn't immediately make the head fall off when BB-8 moves any significant distance.
  • BB-8 was painted by Kyle's friend over break, and looks great now! However, since BB-8 is now opaque, it is MUCH harder to navigate BB-8 properly. Ideally, the head points vaguely in the direction the body is facing internally, but because of its ability to spin ±90°, it's difficult to predict which direction BB-8 is facing at any point.
  • Therefore, I've spent significant amounts of time working on updating the control scheme. Instead of four directional buttons, I'm devising a coordinate-plane system that should map to a fine-grain control of the motor powers. The idea is to have a one-to-one mapping of motor powers for left and right motors from [-100, 100] for both that is still intuitive in terms of which direction BB-8 will travel. This also requires an overhaul of the internal Bluetooth characteristics and how they're handled, but I definitely should have more time next week to work on perfecting BB-8 before the Spark Challenge.