How to bend a 15mm stainless steel tube!
Another busy week has just flown by: we’ve finished our lighting controller board, debugged our firmware and tested our LED strings… the simulator should be visible from the moon if not beyond! So we tweaked our code to protect our eyesight. We may want to add some more animation patterns later.
We wanted to focus on the mechanical controls and the interface between the electronics and the controls this weekend. Unfortunately, this meant working under outside. That plan was somewhat compromised with the storms battering the UK over the last week and this weekend, so we decided to shorten our working session today and take some cover.
We spent half a day with the air frame: identifying our requirements, evaluating solutions, measuring and generally discussing our options.
We think we can make this work using wire ropes and some additional parts:
We’re also going to need to create more 3D printed parts than we planned originally.
Further research over the weekend allowed us to identify all the components we needed for our wire ropes (cable clamps, thimbles, turnbuckles to allow us to adjust the tension on the cables, locking carabiners, etc.). Hopefully this will all fit inside our budget as this is starting to get quite stretched already.
Much time was spent on the code this week trying to understand how the MCP chip handles interrupts. While interrupts were sometimes generated, we found that the pin reported by the MCP didn’t always match the pin that had generated the interrupt. This meant that our code was trying to clear an interrupt that didn’t exist rather than the pin that had triggered the interrupt. Since the MCP will not trigger another interrupt until the first one is cleared, our buttons didn’t work anymore.
We checked our code again. We checked the library again. We added diagnostics statements, ran the code through a debugger (live debugging). There was no practical explanation for the wrong pins being flagged by the MCP.
We altered our code again to check for pin state differences rather than to use interrupt. Then, finally, on Saturday, we hooked buttons, switches, sensors, potentiometers and power suppy onto our boards. We started the laptop, configured the flight simulation software and hooked up the virtual reality headset. After some troubleshooting to force the PC to recognise all our inputs (especially the potentiometers), we finally had a working simulator: we are able to “fly” our glider using the MPU6050, use our buttons to start the flight, add height, enable thermal helpers, etc. It worked! So we disabled the coordinated rudder and started flying with tthe MPU6050 and the rudder. More success!
We will need to do a little bit of tuning once the sensors are installed in the glider but we’ve done it!
After enjoying our flying for a while, we decided to move on to the lighting controller. While 2 of us soldered the boards for the lighting, the other 2 focussed on the firmware. By the end of the day we had finished the soldering and had software that compiled. A little bit of testing and we’ll be ready to install the controls in the glider and fly. A major milestone is definitely in sight.
Sadly, with an incoming severe storm, we decided to postpone introducing the 2nd group of younger explorers to the simulator. (With hindisght, this turned out to be a wise decision as we lost power twice during the day which would have made it impossible to work.)
We started introducing the younger air explorers to the simulator this afternoon. To make this part easier, we split them into 2 groups. So today we explained our work so far, the purpose of the controls and demonstrated the simulator to 3 new explorers. We also looked at the basics of 3D design and the tools we will be using to create the parts we need.
Depending on the weather, the second group of 3 explorers will join us next week.
What an eventful week…
After last week’s problems with the Arduino Pro Micro boards we decided to try reverting to an Arduino Leonardo board. The Leonardo worked well for prototyping but the female headers on the board made it hard to create a board with permanent, soldered connections. So we ordered and received a Leonardo without headers. On paper, this was a great idea. In practice, we soon realised that while we could solder header pins on 1 side without problems, on the other side of the board, the 2 blocks of headers are separated by a gap 1.5 times the width of a 2.54 mm pitch. So if we soldered male headers on the Leonardo board, we could not plug it into female headers on one of our boards. Rather annoying indeed.
So the Arduino Leonardo went back and we ordered an Arduino Micro board to replace it. We had no problem soldering male headers on the Micro. This gave us a reliable (and genuine) Arduino board to control our gliders and solved 1 of our 2 problems.
We still had to find a solution to our lack of pins and interrupts. After some research, we decided to try using an MCP23017 I2C I/O expander. Some of us had experience of using one for another project and it looked like we could make it work. The MCP23017 offers 16 I/O pins split into 2 banks of 8. Each bank of 8 pins has an associated Interrupt pin. The 2 pins can be configured to be logically OR’d thus giving us a single interrupt pin (connected to the Micro’s in #7 with an interrupt handler) for 16 actual I/O pins. On paper, at least, this would be brilliant. So we re-drew our schematics to take the new chip into account while we waited for our delivery.
It then took a few hours to create a new board that would accommodate the Arduino Micro, an MCP23017, a 5.5mm power jack, our I2C devices and the connectors we needed.
We also spent time reworking our code to use the Adafruit MCP23017 library. This would allow us to make the most of the chip’s interrupt capability.
So on 1 February, we put it all together: new board, new Arduino board and updated software… it didn’t work. We re-read the datasheet, checked our connections (found a really well hidden short where a tiny bit of insulation had melted enough to create a tiny but effective short between 2 data wires), checked our voltages, wire continuity and everything we could think of. No change.
We decided to upload an I2C scanner sketch to try and find out what was happening. Our MCP23017 chip wasn’t visible. The other I2C devices were there but not the MCP chip. While we were ready to connect a logic level analyser to the circuit, we also re-read the datasheet. That’s when we spotted that the MCP’s reset pin is an active low pin. We had left the pin floating so we quickly wired the reset pin to our 5V rail on the board. The MCP chip magically appeared on our I2C scan. Problem solved!
We quickly soldered some buttons and switches on connectors so we could get started with our proper testing. Some of the switches worked but not others. We checked our code but that looked ok. We had enough reliability to do an end-to-end test. Our first proper test… Success!
Unhappy with yesterday’s failed test, we decided to investigate further. We did find a couple of omissions on our board. The reason the MCU couldn’t see the I2C devices is rather simple: the I2C clock and data wires weren’t connected to the MCU!
We also realised that one of the ends of the Cat6 cable we used to connect the MPU was wired using a different version of the cabling standard. T-568A versus T-568B.
This was rather positive. However, our MCU still wasn’t recognising inputs correctly. The Arduino Pro Micro we are using seem to be responding correctly or to be picking up interrupts.
We tried cleaning up our code a little but to no avail. We also realised that using interrupts on pins 0 and 1 was causing us problems uploading new code to the MCU. These are the RX/TX pins and, while is is ok to use them for other things, our code was conflicting with the functioning of the USB port.
This is what we observed:
We checked and re-checked the datasheets, checked for information online but couldn’t work out where our problem came from. As our MCU’s power regulator can accept up to 16V (12V recommended), we connected a 12V power supply to the MCU. This immediately produced the magic blue smoke! A second attempt caused one of the on-board resistors to spark on the MCU. We concluded that that MCU board was no longer usable!
Rather than break another board, we decided to try with one of our Arduino Leonardo boards we used for the prototype. This worked and produced mostly expected results (bugs notwithstanding).
After some further reading and discussion, we decided that we needed to find solutions to 2 problems:
Back to soldering today. We continued assembling our boards. Towards the end of the day we put everything together for a test before heading to the AGM of the gliding club.
Unfortunately, things didn’t go to plan! The VR headset and Condor are working fine but Condor could not see our controls. This is frustrating but we have ideas on how to solve our problems.
Another good working session on the electronics today. Plenty of wire cutting, soldering and testing. We’re quite happy with our work. Obviously we’re not professionals but we’ve tried to keep our boards clean, neat and tidy.
Happy New Year!
Our objectives for today were to finalise the Bill of Materials (BOM) for the electronics and to start soldering the parts we have already received.
Reviewing the BOM was harder than we thought. We went through our electronics design and queried every aspect to ensure we were happy with it. This highlighted some unease about our choice of connectors. Terminal blocks are good but can be fiddly in tight spaces and would need cable stress relief that wasn’t easy to add. Furthermore, they would not be very good for quick connections/disconnections. So we looked at alternative connectors and decided to use RJ45 plugs and sockets. RJ45 plugs are easy to insert / remove, provide a positive connection and RJ45 sockets are simple to solder onto small breakout boards to align with the 2.54mm pitch of our PTH boards.
We had already planned on using Cat5e or Cat6 cabling to bring signals back to the rear of the glider so this seemed like a practical, logical choice. The cat5e/cat6 cables have the advantages of being AWG26, twisted pairs enclosed in PVC sheating, therefore providing clean cable runs that are easy to tie to the tubular frame of the glider. This choice meant we had to review all our connections and assign functions to the wires in the cat5e/cat6 cables.
We also revisited our choice of connectors for the front and rear control panels (to connect the switches, LED strips and LCD displays to the panel PTH boards. We decided to use JST XH 2.54mm connectors as they are compatible with the pitch of our PTH boards, keyed (so they cannot be inserted incorrectly) and fairly robust.
We finished our day by soldering RJ45 sockets onto breakout boards and soldering the pins of the ardunio micro pros and of the component breakout boards.
Our objective today is to control the virtual glider with one of our prototype kits. So we assembled the cirtcuits required to connect the MPU6050 sensor, the real time clock and the LCD display.
While the code showed no problem, Condor wasn’t seeing the MPU6050 sensor. After troubleshooting for a while including using a logic level analyser, we created a new sketch to scan the I2C bus. This gave us some unexpected results. It seemed that some of the devices connected to the I2C bus weren’t connected. We checked and re-checked our connections but they were fine. So we proceeded by elimination, removing 1 device at a time from the bus. This made us realise that 2 of our devices use the same 0x68 I2C address: the RTC clock and the MPU6050 sensor.
Fortunately, the MPU6050 datasheet gave us a convenient work around. The sensor will define its address as either 0x68 or 0x69 depending on the logic level of the AD0 pin. We connected the AD0 pin to our 3V3 supply and re-ran our I2C scanner. Thankfully, all devices now appeared. We were back on track!
Our next hurdle was the MPU6050 library. The library offers no way to define the sensor’s I2C address when the object is created. There is, however, a constant defined in the library’s header file with the address of the sensor. Modifying the value of the constant and recompiling fixed our problem.
We also resolved a couple of issues with writing messages on the LCD display.
Once we had reflashed our firmware on the Ardunio Leonardo, we spent time working out what our firmware needed to send Condor in order for Condor to recognise it as a valid input. This took quite a bit of fiddling but led us eventually to fly our virtual glider using the prototyping kit and the firmware. This was a major breakthrough and a perfect end of 2019: not only was it satisfying to see our code working but, more importantly, it proved our design beyond doubt.
We can now focus on soldering the boards, finalising our firmware, assembling everything inside the glider and creating support frames.
What started as a dream in February 2019 is now becoming reality.
Another day working on the simulator firmware. We added the logic for the momentary and toggle switches. This made us review and change the purpose we had originally intended for the switches. We realised that we needed to rethink the shortcuts needed while flying with a virtual reality headset.
We replaced the DS1307RTC library in our code with the RTClib library which saved us a few 100 bytes of flash memory and committed our code to the Github repository.
We also created the code for the lighting controller and committed it to its own Github repository
We connected the VR headset to the laptops and installed Condor V2. After a little bit of configuration work, we were able to fly virtually. What an experience! It took us a while to work out how to control the glider using the keyboard (and later with a mouse). We possibly died a few times after losing wings in flight but it’s ok since it’s quite hard to fly a glider you cannot control!