The LW Bot v1.0 specification will be posted in the next few weeks. The firmware will include support for wireless communication, battery monitoring, drive system, two leds, a dual axis accelerometer, and a yaw rate gyro. Currently I am in the process of changing the firmware to support the accelerometer and gyro. Originally the code was all contained in one main file but now it is split up among files specific to each function such as drive, adc, etc. This takes a more object orientated approach although the code is still written in c. Below is a picture of the two sensors with the accelerometer and gyro on left and right respectively. Because the gyro contains a temperature sensor, I will place it near the 5 volt regulators to detect if they become too hot. The documentation for the two sensors can be found here.
On another note, the renderer for Eagle3D would not properly run on my Mac and thus I will continue to publish 2D electrical schematics for now.
After much trial and mostly error I have decided to not use my own ethernet based bootloader for the LW Bot. Originally it would have been a neat idea to be able to wirelessly re-flash the AMTEGA however I soon realized I was constrained both by a limited battery supply and significant interference causing me to send packets several times. Since the power supply is so limited it would be a waste of power to have the robot waiting to be re-flashed. I also realized since most of the logic is implemented on the controlling computer side and the robot simply parses commands the robot will need to be updated very rarely. For control of the robot I am debating between an Xbox360 controller attached to the host computer or an Android application.
After roughly a month of not updating my site I am finally back. I had finished my last AP exam this Thursday and thus senior year is coming to an a near end.
The LW Bot ethernet bootloader is somewhat complete. The computer will parse the hex file using this specification. Recently I have been experimenting with programs such as AutoCad for Mac, Labview, and Matlab. I plan on using AutoCad and possibly Inventor to prototype my designs before production. I am using Matlab to educate myself on Laplace Transforms and Fourier Analysis.
In addition I have begun looking into PCB design and plan on fabricating my own before the beginning of my summer break. I remember seeing a library to produce 3D eagle schematics and I will look into that in the near future.
Regarding the firmware I have finally implemented a processCommand function that is called whenever the robot receives a packet.
char* processCommand(char* command,int8_t* values)
if(strcmp(command,"goToBootloader") == 0)
else if(strcmp(command,"driveStraight") == 0)
else if(strcmp(command,"drive") == 0)
else if(strcmp(command,"setLed") == 0)
This function allows me to send text commands from my computer in a somewhat simple syntax. Basically to tell the robot to go straight I could send it driveStraight=127 or drive=127,127 where a “=” tells the chip to then expect parameters for the command and “,”‘s tell it additional parameters follow. The next feature I plan to start implementing is two voltage readers one for each battery and then bootloader support over UDP. I will post additional details regarding the bootloader once I come up with them. Regarding the power sources I am looking into using a non-isolated buck switchable power supply to power the router. The chips will still be powered through a 5V regulator as this regulator will also supply power to the buck’s components. A current picture of the robot can be found below:
Recently I have not had time to work on my projects because of school work and getting stuff ready for college(ECE at Carnegie Mellon Class of 2015 ) so this is a more conceptual update. This past Monday I received my replacement ethernet shield which I am currently swapping with the broken one. Instead of using the 9.6V Ni-Cd battery to power the router my robotics advisor graciously gave me a VEX robotics 7.2V Ni-Cd which is rated 1000mAh higher than the 9.6V battery thus allowing my robot to be controlled wirelessly for a longer period of time. I originally wanted to design a circuit such that the 12V battery pack could power the router once the 7.2V battery ran low(using 8 AA’s to power a router would need to be replaced often) and the 7.2V could be charged in system thus being disconnected from the router. This could easily be accomplished using relays however due to cost and size restraints I am going to try to implement it using transistors. I am not sure if this would be effective(2.5 A is quite a bit for a transistor) however I will look into it.
I meant to include this in my last post but here is a note. The DI-624 has some strange firewall that does not allow devices over ethernet to talk to wireless devices. The only workaround to this problem I found was here. Basically
route add 192.168.0.30 192.168.0.1
where 192.168.0.30 is the robot and 192.168.0.1 is the router.
Below are photos of The Cogito Project v2.0 main control system. As stated before the peripherals are staying the same and only the control hardware and software are being updated in v2.0. It turns out the relays I were going to use for the cold cathode lights and emergency light are AC Relays( ) so when I turned them on they wouldn’t switch off properly. Instead of using relays I am going to use the L293D(H-bridge) to control them. I have to wire that chip and then the hardware is complete. The software protocol will hopefully be done in a few weeks.
I had a random idea Sunday night. Since I dont have the budget to go buy medium sized motors and wood would be too heavy of a material to use with the motors I currently have I thought I should use the Legos I have sitting up in the attic. Basically the “robot” uses 4 Mindstorm motors @ 12V to carry two battery packs, a router(DI-624), and a breadboard. The 9.6 NI-CD battery is used to power the router while the 8 AA battery pack(12V) is used to power the motors and microcontroller(through a 5V regulator of course). The interesting part is the robot is going to be able to be programmed and controlled wirelessly. Using a enc28j60 ethernet shield the ATMEGA644P can talk to the router. The ATMEGA644P will have some form of an ethernet bootloader flashed however I will probably end up making my own ethernet bootloader to meet my needs(based off of tuxgraphics enc28j60 code). The problem is though last night I accidentally fried my current shield so I had to order another one from sparkfun this morning.
Recently I have been working on v2.0 of The Cogito Project. As of today I have the wooden enclosure for the main control almost complete. It consists of two platforms of which the bottom platform is surrounded by plexiglass on 3 sides. Inside the bottom platform a power strip splits power to the laptop charger, wireless router supply, and Xbox360 power supply. The router which acts as a wireless bridge is located on the bottom platform as well. The Xbox360 power supply has the GND line, 12v ON line, and the 12V line being used. The 5V line is not being used because 5V is supplied from the laptop’s usb port which also triggers 12V ON when necessary by a pin on the ATMEGA88. The 12V line is fed into a board of 4 relays that will soon be wired to a pair of cold cathode lights, an emergency light, and a fan. The ports for the peripherals are located on the top left side of the case. Furthermore, in this version the ATMEGA88 has bootloadHID flashed on it which allows the chip to be programmed without the usual AVRISP mkII or any SPI programmer in this case. This is very beneficial to the way the project is organized. Basically there are three layers of abstraction.
The first layer is the PIN layer which corresponds to the individual pins on the ATMEGA88. These pins can be low, high, or highz(disconnected). This layer can only be changed through the physical action of swapping wires from the ports to different pins on the chip.
The second layer is the PORT layer. A port is what a peripheral, such as a AC Unit Block Relay, would plug into. As you may know from v1.0 the peripherals are each controlled by two lines so therefore each port controls two pins. This layer is implemented through the chip breaking down the usb request, recognizing what port the request is asking for, and putting the pins that port controls into a specific state as stated by the request.
Finally, the last layer is the PERIPHERAL layer. This layer is not located on the chip’s flash but rather the computer’s program where each port now becomes a particular peripheral such an AC Block Unit Relay. This peripheral object would have functions such as turn on, that turn the relay on and strobe the power on led. This layer can be changed by rewriting the c++ classes which are located on the laptop.
Basically a peripheral object sends a request via USB to the microcontroller. That request is then acted on whatever port it requested. The port, by changing its pins change what state the peripheral plugged into that port is in.
Under the ARLP page the schematics and source code for v2.0 can now be found. Also, while off the cold cathode lights that were part of the Cogito Project I had an epiphany. Instead of powering The Cogito Project from an Xbox360 power supply and communicating with it over serial I would instead use USB to communicate and power it at the same time. Before I start developing ARLP v2.1(read battery voltage) I am going to update The Cogito Project to use USB. While I am at it I might as well build a nice case for the project too .
After doing some research on ethernet bootloaders and trying to cut down on the application code I soon realized there is no chance I will be able to fit an ethernet bootloader on the ATMEGA88. That leaves me with two options. The first is to use another medium for a bootloader such as USB however due to the size constraints of the launch pad electronics area that is not a reasonable option. The second option is to use at different chip such as the ATMEGA644P as the main controller however I do not feel like ripping my current electronics out. Therefore, the next feature I will implement is the ability to measure the voltage of the battery which will be released in v2.1. After v2.1 all hardware changes on the rocket launch pad in the foreseeable future will be complete and then I can update the client code(computer code) to have camera support.
As I began writing up the specification for ARLPv2.0 I realized the first feature I should implement is not voltage readings or camera support but rather an ethernet bootloader. Since I am graduating this year and I plan on donating this project to the rocketry club they are going to need a way to program the atmega without a SPI programmer considering I am the only person who has one in my school. *Off to google*