rbasoalto

OK, a long time has gone by... I finally made the choice and got the motors, ESC, propellers, and a frame from DX.com.
I know there are better places to get these parts, but DX.com had a good price and variety. For around 100 USD I got everything I need to make a "stable flight" prototype. The only things missing are batteries and radio.
A friend of mine crashed his R/C airplane and gladly donated the radio for this project. And batteries... let me first get this thing off the ground tethered, and just then I can think about batteries.
 
On the software side, I'm partnering with a friend with lots of experience in MSP430 (although not so much in control systems), but I think we can learn something from ArduCopter code, or similar projects, and port them to the Stellaris. 32-bit architecture at 80 MHz and hardware floating-point unit might come very handy here.
 
The first steps will be getting the Stellaris working nice with Mac/Linux and hopefully with gcc.
Then we're going to focus on modules: reading the sensors, controlling the motors, reading the radio commands, and debug output (maybe stream debug messages through CC1100 radios, or spit them through UART with a HC05-like bluetooth module).
Then comes the hard part of putting inertia and motors together with the control system.
Finally, getting the quad to obey radio commands.
 
We're also thinking on integrating gps waypointing capabilities for semi-autonomous navigation. This will probably not be of too much use, since we're not expecting battery life to exceed 10~20 minutes. We'll have to measure the system power requirements and find a suitable battery pack to fit our power/weight needs.
 
PS: for those of you who are curious about the parts used, here's the list:
A2212-6 2200KV Brushless Motor Set - Golden http://dx.com/p/41211
Mystery Speed Controller Pentium-30A for Brushless Motors (300/450 R/C Helicopters) http://dx.com/p/34338
4-Axis HJ450 Multi Flame Wheel Flame Strong Smooth KK MK MWC Quadcopter Kit - Red + Black http://dx.com/p/124486
10 x 4.5 1045 Rotating Shaft Propellers for Multi Copter - Black (2-Pair) http://dx.com/p/123222

Hi everyone!
I saw this IMU (3-axis accelerometer + 3-axis gyro + 3-axis magnetometer + pressure altimeter) for $21 on eBay (link), and the $5 Stellaris launchpad, and I immediately thought: QUADCOPTER!
 
Already placed the order for the IMU and Stellaris, and I plan to design a Boosterpack to connect motors, sensors, and probably a sonar ranger to the floor and/or ceiling (for indoor flight).
 
Anyone has any experience with these flying monsters?
 
Thanks!

OK, let's see if simplicity can win
 
http://forum.43oh.com/topic/3016-very-simple-ir-remote/

OK, let's see if simplicity can win
 
http://forum.43oh.com/topic/3016-very-simple-ir-remote/

Hi!
I made a very simple IR remote control with a MSP430G2211, a 4x4 keypad, and an IR LED.
 
I wanted to make a remote for my car radio, but for the time being, it's a Sony TV remote.
 
You can see the code (mspgcc) at https://github.com/rbasoalto/sonyremote
 
A couple of pictures...



 
The code could use a little rework, but for a quick&dirty hack, it's working pretty nice.
 
BOM:
Keypad IR LED MSP430G2211 + socket Resistor for RST (it's inside the socket) Decoupling cap (probably not needed) Salvaged iPod Li-ion battery AMS1117-3.3 regulator (just the one I had lying around...) Assorted connectors Perf board  
Next steps:
Program new codes using keypad. Add a receiver module to enable learning of new codes. Higher power IR, using a transistor or MOSFET and a couple of high-intensity IR LEDs

Hi!
I made a very simple IR remote control with a MSP430G2211, a 4x4 keypad, and an IR LED.
 
I wanted to make a remote for my car radio, but for the time being, it's a Sony TV remote.
 
You can see the code (mspgcc) at https://github.com/rbasoalto/sonyremote
 
A couple of pictures...



 
The code could use a little rework, but for a quick&dirty hack, it's working pretty nice.
 
BOM:
Keypad IR LED MSP430G2211 + socket Resistor for RST (it's inside the socket) Decoupling cap (probably not needed) Salvaged iPod Li-ion battery AMS1117-3.3 regulator (just the one I had lying around...) Assorted connectors Perf board  
Next steps:
Program new codes using keypad. Add a receiver module to enable learning of new codes. Higher power IR, using a transistor or MOSFET and a couple of high-intensity IR LEDs

Hi!
I made a very simple IR remote control with a MSP430G2211, a 4x4 keypad, and an IR LED.
 
I wanted to make a remote for my car radio, but for the time being, it's a Sony TV remote.
 
You can see the code (mspgcc) at https://github.com/rbasoalto/sonyremote
 
A couple of pictures...



 
The code could use a little rework, but for a quick&dirty hack, it's working pretty nice.
 
BOM:
Keypad IR LED MSP430G2211 + socket Resistor for RST (it's inside the socket) Decoupling cap (probably not needed) Salvaged iPod Li-ion battery AMS1117-3.3 regulator (just the one I had lying around...) Assorted connectors Perf board  
Next steps:
Program new codes using keypad. Add a receiver module to enable learning of new codes. Higher power IR, using a transistor or MOSFET and a couple of high-intensity IR LEDs

Very nice!
Maybe you can have a look at http://en.wikipedia.org/wiki/HOTP for security. It's the kind of cryptographically-secure unpredictable sequence generators that banks use for two-factor authentication. Google's two-factor authentication uses it too.
 
The idea is that you apply an HMAC function (some kind of hash involving a private key) to a counter. Both transmitter and receiver need to store this counter. Since both will usually be in sync, the HMAC received can be compared to the expected value, based on the shared private key, and the counter. If it fails, it can also try a few counts ahead too, in case the button was pressed accidentally out of the receiver's range.
 
Although banks and Google use a time-based algorithm, it's essentially the same, but using the count of 30-second ticks instead of an event counter. I think I've seen a version for the Chronos that is compatible with Google Authenticator. Should be trivial to adapt.
 
Since you will need to store a counter, FRAM would be ideal for zero-power-standby. But you can also use flash, or just have the MSP sleeping in LPM4 the whole time and wake it, with an interrupt from the button, for transmission (at a few uA it shouldn't be noticeable).
In this last case, you could use a three-way handshake, much like TCP/IP sockets, for keeping the counters in sync. Something like

[*:3rhtxy43]Remote: HEY, the current code is 123456.
[*:3rhtxy43]Receiver: OK, please come in.
[*:3rhtxy43]Remote: Thanks! Increment the counter! (I will increment it too)
 
I could continue giving ideas for centuries, it's a very interesting topic.
 
Cheers! I hope you're not locked out!

Very nice!
Maybe you can have a look at http://en.wikipedia.org/wiki/HOTP for security. It's the kind of cryptographically-secure unpredictable sequence generators that banks use for two-factor authentication. Google's two-factor authentication uses it too.
 
The idea is that you apply an HMAC function (some kind of hash involving a private key) to a counter. Both transmitter and receiver need to store this counter. Since both will usually be in sync, the HMAC received can be compared to the expected value, based on the shared private key, and the counter. If it fails, it can also try a few counts ahead too, in case the button was pressed accidentally out of the receiver's range.
 
Although banks and Google use a time-based algorithm, it's essentially the same, but using the count of 30-second ticks instead of an event counter. I think I've seen a version for the Chronos that is compatible with Google Authenticator. Should be trivial to adapt.
 
Since you will need to store a counter, FRAM would be ideal for zero-power-standby. But you can also use flash, or just have the MSP sleeping in LPM4 the whole time and wake it, with an interrupt from the button, for transmission (at a few uA it shouldn't be noticeable).
In this last case, you could use a three-way handshake, much like TCP/IP sockets, for keeping the counters in sync. Something like

[*:3rhtxy43]Remote: HEY, the current code is 123456.
[*:3rhtxy43]Receiver: OK, please come in.
[*:3rhtxy43]Remote: Thanks! Increment the counter! (I will increment it too)
 
I could continue giving ideas for centuries, it's a very interesting topic.
 
Cheers! I hope you're not locked out!

Very nice!
Maybe you can have a look at http://en.wikipedia.org/wiki/HOTP for security. It's the kind of cryptographically-secure unpredictable sequence generators that banks use for two-factor authentication. Google's two-factor authentication uses it too.
 
The idea is that you apply an HMAC function (some kind of hash involving a private key) to a counter. Both transmitter and receiver need to store this counter. Since both will usually be in sync, the HMAC received can be compared to the expected value, based on the shared private key, and the counter. If it fails, it can also try a few counts ahead too, in case the button was pressed accidentally out of the receiver's range.
 
Although banks and Google use a time-based algorithm, it's essentially the same, but using the count of 30-second ticks instead of an event counter. I think I've seen a version for the Chronos that is compatible with Google Authenticator. Should be trivial to adapt.
 
Since you will need to store a counter, FRAM would be ideal for zero-power-standby. But you can also use flash, or just have the MSP sleeping in LPM4 the whole time and wake it, with an interrupt from the button, for transmission (at a few uA it shouldn't be noticeable).
In this last case, you could use a three-way handshake, much like TCP/IP sockets, for keeping the counters in sync. Something like

[*:3rhtxy43]Remote: HEY, the current code is 123456.
[*:3rhtxy43]Receiver: OK, please come in.
[*:3rhtxy43]Remote: Thanks! Increment the counter! (I will increment it too)
 
I could continue giving ideas for centuries, it's a very interesting topic.
 
Cheers! I hope you're not locked out!

Very nice!
Maybe you can have a look at http://en.wikipedia.org/wiki/HOTP for security. It's the kind of cryptographically-secure unpredictable sequence generators that banks use for two-factor authentication. Google's two-factor authentication uses it too.
 
The idea is that you apply an HMAC function (some kind of hash involving a private key) to a counter. Both transmitter and receiver need to store this counter. Since both will usually be in sync, the HMAC received can be compared to the expected value, based on the shared private key, and the counter. If it fails, it can also try a few counts ahead too, in case the button was pressed accidentally out of the receiver's range.
 
Although banks and Google use a time-based algorithm, it's essentially the same, but using the count of 30-second ticks instead of an event counter. I think I've seen a version for the Chronos that is compatible with Google Authenticator. Should be trivial to adapt.
 
Since you will need to store a counter, FRAM would be ideal for zero-power-standby. But you can also use flash, or just have the MSP sleeping in LPM4 the whole time and wake it, with an interrupt from the button, for transmission (at a few uA it shouldn't be noticeable).
In this last case, you could use a three-way handshake, much like TCP/IP sockets, for keeping the counters in sync. Something like

[*:3rhtxy43]Remote: HEY, the current code is 123456.
[*:3rhtxy43]Receiver: OK, please come in.
[*:3rhtxy43]Remote: Thanks! Increment the counter! (I will increment it too)
 
I could continue giving ideas for centuries, it's a very interesting topic.
 
Cheers! I hope you're not locked out!

Hi everyone!
I saw this IMU (3-axis accelerometer + 3-axis gyro + 3-axis magnetometer + pressure altimeter) for $21 on eBay (link), and the $5 Stellaris launchpad, and I immediately thought: QUADCOPTER!
 
Already placed the order for the IMU and Stellaris, and I plan to design a Boosterpack to connect motors, sensors, and probably a sonar ranger to the floor and/or ceiling (for indoor flight).
 
Anyone has any experience with these flying monsters?
 
Thanks!

Very interested! I flew mine on a maiden yesterday. I'm using CC3D as a controller which is based of an STM32. I can give you alot more information if you want. Very eager to see your progress.
Also, Stellarisiti has Blogging support, so you can continue a build log in this thread and also write to your blog about any milestones.
 
This is mine:

Hi everyone!
I saw this IMU (3-axis accelerometer + 3-axis gyro + 3-axis magnetometer + pressure altimeter) for $21 on eBay (link), and the $5 Stellaris launchpad, and I immediately thought: QUADCOPTER!
 
Already placed the order for the IMU and Stellaris, and I plan to design a Boosterpack to connect motors, sensors, and probably a sonar ranger to the floor and/or ceiling (for indoor flight).
 
Anyone has any experience with these flying monsters?
 
Thanks!

Got a new batch of Color LCD Booster Pack boards.
The board was revised and will require small code change, CS pin was moved from P1.2 to P1.0 (here's the reason why.)
Also gone are Nokia displays and stuff that was not used.
2x2 header is not necessary anymore (and will not be included in the kit) since header pads are shorted by default (USCI is a default setup.) Backlight resistor and memory HOLD resistors are also shorted (HOLD -> Vcc.)
HOLD pins can now be used on both memory chips.
Switches have now optional RC de-bouncers.
 
New boards will be used ONLY for the kit, PCB version will remain the same.
 
 

Here are two adapters that can be used to remap the pins.
 
 

I must admit I
RobotBooster_mini_v1.zip

I think I am done with the layout.
To make this board more versatile, port P1 is connected to the header, so instead of USB->MIDI, this board could also be used as logic analyzer or USB->Power Board/Relays, etc.
There is a programming header, BSL header, 3 LEDs (one USB power and two general use,) opto isolator and buffer for MIDI In and Out.
The two drill holes on the left can be used for wire tie, in case wires are soldered directly to the board.
 

Here's the code I used for USB->UART example.
It's basically TI's example code with most of unnecessary code removed and with my LCD code added.
 
USB_UART_example.zip

The design guide tells you to limit the number of vias, but they are OK.
I did consider doing something like below, but I am not sure if this will be any better.
Placing 5510 or USB on the bottom layer would probably be the best solution here.
Are there any software USB diagnostic tools I could use that will show mi transfer errors?
 
 

 
 
Also, relative to some other designs out there, I don't think my design is that problematic.
 
 

This is software IIC master code in C, and C++ using a class and a template. There is also code/class/template for IIC EEPROM and the INA219 voltage/current monitor.
 
There are 4 core functions...

init(); // Init GPIO start(); // Start bit stop(); // Stop bit unsigned ex(unsigned); // Data byte & ack exchange
 
and 3 helper functions that call ex();...

unsigned write(unsigned); // Write a byte & ack, verify unsigned read(); // Read a byte & ack unsigned read_nak(); // Read a byte & nak
 
Creating an instance of the IIC object is different for each code type:

C: T_IIC iic = { BIT1, BIT0, &P2IN, &P2OUT, &P2DIR }; C++ class: CSWIIC iic(BIT1, BIT0, P2IN, P2OUT, P2DIR); C++ template: CSWIIC iic;
 
The C functions require that the IIC structure be passed as the first argument. The C++ class and template use the usual class.function notation.

C: iic_start(&iic); a = iic_write(&iic, ; iic_stop(&iic); C++ class or template: iic.start(); a = iic.write(; iic.stop();
 
This is a disassembly of the start() function for all three versions. The C function and C++ class member function are identical code! The template allows the compiler to do compile time optimization that can not be done with C or C++ class. It is smaller, faster and uses less RAM.
 

iic.zip

Here are two design proposals. Up to 6 of each can be stacked to increase channel count.
 
The first uses a 12 bit ADC and has 2 channels that can be used for voltage or current and 5 channels that are current only. This could be used for single or split phase applications. Accuracy would be poor at low load due to limited ADC resolution.
 
A 2.5 V reference voltage is supplied by the MSP430 and buffered by IC1A. The buffered reference is used by the ADC and also divided by 2 and buffered by IC1B to create a bias for the sensors. The first ADC channel reads the bias voltage so it can be subtracted from the other 7 channels and produce a signed result representing voltages above and below 'zero'.
 
Each input has a simple passive first order low pass filter to reduce aliasing. A second or higher order filter would be better, but require many more components.
 

 
The second uses a 24 bit (max) ADC and has 3 channels that can be used for voltage or current and 3 channels that are current only. It could be used for single, split, or 3 phase applications. Accuracy would probably be limited by the voltage and current transformers used. It could approach 'utility grade' precision with careful hardware and firmware design.
 
Each input is balanced and ground referenced. TP or STP cable would be used to minimize pickup of unwanted signals in the wiring. Passive first order low pass filter to reduce aliasing.
 
The MCP3903 ADC is made for power monitoring applications and has hardware assist for phase lead/lag compensation. This would be a SMD design to ensure maximum performance - ground planes and guarding are critical for high resolution measurement.
 

Did you think about rechargeable Li-ion or Li-po batteries? They give 3.6v (4.2v when fully charged really) and are pretty compact for the amount of energy stored. They also come in infinite number of shapes. Maybe it's worth a look. The other option is coin cell style sandwich of 3 NiMH cells, for 3.6v, pretty common in minor rechargeable household electronics, I bet you could find them on eBay or somewhere else.
 
EDIT: just found a stack of 3 "1/3 AA" NiMH, in the space of 1AA you get 3 cells NiMH at 480 mAh, should do the trick... http://www.ebay.com/itm/140790250490