Here’s the first test of Squid in a robotics application. Although Squid is designed to be controlled by an external controller such as a Raspberry Pi, Squid can also operate in a standalone mode. In this video, Squid is controlling a simple insect-like robot using layered behaviors. With a lot of onboard resources, I can think of a lot of add ons I might add to the robot. I have additional updates I want to add like I2C and analog to digital conversion, but with the first operational Squid, I wanted to jump ahead a bit and place Squid on a robot. Below are a couple of pictures of the bot with Squid as its controller. The robot can now also very easily be controlled through a Bluetooth connection.
Connecting a PIC to a Bluetooth module opens up a lot of possibilities for robotics. Here is the test setup for Squid. In an earlier post, I was using a 4Mhz crystal I switched to a 20Mhz for the PICs clock. In the image below, I’m using a JY-MCU Bluetooth module the HC-5 version. The Bluetooth module is connected to the PICs USART pins with two 10k ohm resistors to divide the PICs TX voltage from 5 volt to 2.5 volt. A safe level for the Bluetooth module while still a high enough voltage to be a logic level 1.
In “int main” I added the following two lines of code to test the Bluetooth connection.
Usart_write(“b”);
_delay_ms(1000);
This will transmit a “b” every second, and since the interrupt is enabled, any characters sent to the Squid will mirror back to the computer that is connected through Bluetooth to the PIC.
Next, we need to “pair” the Bluetooth to a computer. Power up the test setup, and on the computer, go to the Bluetooth devices. Highlight HC-05 and click “pair”.
Enter the passcode for the Bluetooth module in this case “1234” and click “NEXT”.
And we are connected.
Next, we need to find our COM port. Open Bluetooth devices and click “Bluetooth Settings” and “COM ports”. There will be two COM ports--an incoming and an outgoing.
I’m using Putty as a terminal, so the next step is to open Putty and click the serial radio button, enter the outgoing com port and BUAD rate (speed).
If Putty fails to connect, try opening Putty and connecting to the incoming Com port then close Putty, open Putty again, and then try connecting to the outgoing COM port. I ran into this problem…I’m not sure why, but it worked.
Once connected, the below screen should appear. A “b” is being received every second, and every key I press is being mirrored back…SUCCESS!!!
First, we need an area to start coding. After the project has been created, click “File” in the upper left hand corner and then click “NewFile”. The box below will pop up. Highlight “C” and then “C Main File” and finally click “Next”.
In the next box, you can name the page. I called mine sqmain. Then click “Next”.
We now have a page to code on.
Next, include the h files. I also “defined” a crystal frequency “XTAL_FREQ” as 20 Mhz to be used in later time delays. Also define a couple of subs “void usart_setup(void);” and “void usart_write(char);”. Both sub-routines are self-explanatory. The setup sub-routine will be used to setup the PICs USART and the write will transmit the “char” data. I didn’t define a receive sub-routine because I will be using an interrupt to receive data. The configuration for the PIC is also shown below. I also created an array “char uart_receive_array[10];”to save data being received by the usart.
Below is the “usart_setup” sub-routine. I know I should set it up to calculate changing the buad rate, but for now, this will get the USART running. The buad rate is set to 9600 which is the Bluetooth module’s initial speed. The USART will be in asynchronous mode, and transmit and receive will be continuously enabled.
Below is the transmit sub-routine. Short and simple, call the sub with “usart_write('a');” and the usart will transmit an “a” and wait for it to complete.
Finally the interrupt. For now, just the usart receive interrupt is handled, but additional interrupts can be added as needed. When an interrupt is generated, the interrupt handler below will disable global interrupts “GIE = 0;” and check for the interrupt that was generated. If the USART receive interrupt was generated, each data register in the array will be moved to the next highest register. The lowest register “uart_receive_array[0]” will receive the new character being received. The character will then be sent to the write sub-routine “usart_write(uart_receive_array[0);” to acknowledge that the character has been received. I will be adding code to decode the received commands in future updates. Before exiting the interrupt handler, the global interrupts are re-enabled “GIE = 1;”.
These bits will need to be set in the “main()” routine to enable the USART received interrupts.
When starting a new program, I like testing each individual sub-routine and function on a solderless breadboard setup. This can help work out problems while reducing the risk to the fully assembled circuit board. Below is an image of a quick and easy setup for testing. I’m using a PICKIT 3 to store the program in the PIC. The USART and I2C pins are easily available to test connections to other devices.
For an IDE (Integrated Development Environment), I’m using MPLABX v3.05 with XC8 as the compiler. I was debating about writing the program in assembler but decided to use “C” since more people are familiar with “C”.
For anyone new to the wonderful world of MicroChip PICs, here is a quick run through of starting a new project. First, open MPLAB, click on “file” and click “New project”. Highlight “Microchip Embedded” and “Standalone Project” and click “Next”.
Select the device you are going to use. In this case, PIC16F874A and click “Next”.
Select your programmer and click next.
Select the compiler you are going to use and click “Next”.
Type the name of your project, select a file location and click “Finished” and you have created a new project.
I finished the preliminary circuit board layout. I still need to check and double check everything before exporting it to Gerber files and ordering boards.
I finished the preliminary schematics. I’ve decided to base the first Squid prototype around two PIC16F874A controllers. The two PICs will communicate to each other and also other off board peripheral devices via an I2C interface. PIC one will be able to communicate with higher level controllers with a Bluetooth module through the PICs onboard USART. The second PIC will be able to communicate to higher level controllers through a direct serial interface via again the PICs onboard USART. Using two PICs will supply the resources to handle the 16 individual H-bridges and 16 I/O ports.
The Squid board will be fairly small even though the schematics are in two sheets.
Dennis
