Knight v2 Completion

October 31, 2016

The knight project was completed just in time for the October Linuxing in London meetup.

Mechanics

The 3D model was completed and painted a week or so back. I filled a spare hole in the box lid with a dowel and cut it flush. Connectors were added to the LED wires and the knight was screwed to the box by its feet. I used the PiCon Zero servo test code to determine the maximum and minimum position of the servo. When I came to fasten the arm, I realised that I did not have a screw long enough to attach the arm but it pushed on and stayed in place so can survive without a screw for the time being.

Electronics

The original version could not support a servo as the DragonBoard currently has no driver support for PWM. I had a board from the Gnome event earlier in the year and that seemed ideal for this project. The PiCon Zero is board that provides buffered inputs and outputs, it is designed for use with a Raspberry Pi Zero. The board connects to the via I2C which means that it can also be used with different hosts. The level shifters that were previously used for the LEDs were rewired to connect up the I2C bus between the DragonBoard and PiCon zero. Three of the outputs were used for the LEDs and one for the servo. The passive IR sensor was also attached directly to the PiCon Zero rather than the GPIO. This simplified the wiring and coding.

A ProtoZero board from Average Man vs Pi hosted the level shifters and connectors to the PiCon Zero and the DragonBoard.

Software

From the competition version there were a few changes to the code. I dropped LibSoc as the input was moved over to the PiCon Zero. To support the simultaneous motion and lighting I used queues in the python code.

Testing Queues
Testing Queues and PiConZero

This was merged into the original code replacing the previous flashing LED code. So that the code would start automatically a boot script was added, based on my previous version for the Enchanted Cottage and some help from Dan Nanni’s article on How to automatically start a program on boot in Debian. There’s also a slightly different version using a start-stop-daemon that I intend to investigate.

The final code is available on GitHub.

You can also watch the video of the talk, which was made by skills matter.

Questions

Some of the questions at the talk were around the electronics and the 1.8v I/O on the DragonBoard.

Why not use relays?

A relay is a good way to turn on a higher current device but it also requires quite a bit of current to power it. So to control that from a DragonBoard (or a pi) you’d need to have some transistors to boost the current. Relays are not particularly cheap or compact so there are typically better options. Relays are also a simple switch so you couldn’t use them to driver a servo or dim LEDs.

Could you connect the I2C without level shifters?

The low level 1.8v signals are probably good enough to turn on the circuits of a higher voltage module. However the I2C bus is actually bidirectional so something is necessary to limit the higher voltage back down to the DragonBoard GPIO. The level shifter modules are very simple, small and quite cheap so it is not a big deal including these into the circuit.

Good and bad about the DragonBoard, would you use it for another project?

Yes, I do plan to use the DragonBoard for a new project. I hope to wire up a screen and a webcam with some lenses to make a microscope.

As mentioned in the talk the main concerns for the board are:

• 2mm pin separation
• 1.8v levels on the GPIO
• Higher price than competitor boards such as a Beaglebone or Raspberry Pi
• No PWM support
• Issues with the Wifi

I believe that this last issue has been resolved but I’ve not had chance to test out the latest image.

On the flip side the board does have good processing capability. One of the Linuxing in London guests pointed out that it has a true GPU, Open Source GPU driver and plenty of off load engines on the 64bit Qualcomm® Snapdragon™ processor. This does make it a great option for video, image or signal processing. Clem Martins who put me in contact with the competition used the board for software defined radio.

I managed to find a cheap source for the 2mm connectors. Use of the level shifters and PiConZero solved all my I/O limitations.

As mentioned in the talk if you are using USB for your hardware connectivity then the GPIO limitations do not affect you.

Summary

So that’s pretty much all I plan to do with the DragonDetector. Perhaps I’ll try to work out why it was not detecting during the talk, some people suggested the crowd or the lights were the issue. Or perhaps IR focusing from a camera was affecting it?

It’s been a fun project and working with a different development platform from your usual is definitely something I’d recommend. My 3D printing and modelling skills were challenged by the project and I’ve learnt some new electronics technique. Although I did not win the $5000 it has been a great project to work on and I’m glad I got involved with the competition.

By Andy from Workshopshed 2 Comments

  Posted in: Dragon Detector Tags: 3d Printing, Electronics, Talk