36 replies to this topic

[Kenn Sebesta]

Brian, on 18 December 2011 - 10:38 PM, said:

You know, if you can settle for a USB interface to the GCS and PPM receiver interface, I think you can implement this on a move controller.  I thought about doing that, but I already had the other hardware, so I decided to use it.  It would be especially nice, though, if the battery charger could be enabled.

SNA. ZY. You can use the Move to control the UAV, too.

[Reddog]

Kenn Sebesta, on 18 December 2011 - 11:20 PM, said:

SNA. ZY. You can use the Move to control the UAV, too.

How is the move able to do this but an Arduino cannot deal with UAVtalk because it does not have enough ram? Maybe its just raw control with no UAVtalk?

Thanks for answering all my questions, I have learn't heaps!

[Kenn Sebesta]

Reddog, on 19 December 2011 - 05:18 AM, said:

How is the move able to do this but an Arduino cannot deal with UAVtalk because it does not have enough ram? Maybe its just raw control with no UAVtalk?

The Move has almost identical hardware to the CopterControl, so as D-Lite and Brian have demonstrated in the MoveCopter thread, it can run OpenPilot and be used to fly a quadcopter. As such, it can run anything the CopterControl can, which includes UAVTalk.

[Brian]

Reddog, on 19 December 2011 - 05:18 AM, said:

How is the move able to do this but an Arduino cannot deal with UAVtalk because it does not have enough ram? Maybe its just raw control with no UAVtalk?

Thanks for answering all my questions, I have learn't heaps!

Yes, the problem is mostly RAM.  I ported UAVtalk to the Arduino, but in order to handle more than a few message types, it requires a Mega, which are relatively big and expensive.  The STM32 is also much faster, and I was able to use the same code base, which is nice.

Like Kenn said, the Move controller is very similar to the CopterControl board.  It's a nice piece of hardware for the price.

[D-Lite]

Brian, on 18 December 2011 - 10:38 PM, said:

You know, if you can settle for a USB interface to the GCS and PPM receiver interface, I think you can implement this on a move controller.  I thought about doing that, but I already had the other hardware, so I decided to use it.

Yes, this shouldn't be too hard. But I'm looking for something smaller, that fits into the case of my old transmitter. The internals are modular so I could simply swap the R/F board  with an STM32/Bluetooth board. Well, just one of many options.

Brian, on 18 December 2011 - 10:38 PM, said:

It would be especially nice, though, if the battery charger could be enabled.

I'm not shure if there's a dedicated charge controller or if software has to take care about charging. In the first case, it would be relatively simple to find out how the controller is activated. but I looked into this some time ago and found a MCU pin that show the same pulse pattern as the charge voltage so I suspect the MCU is controlling the charging. Didn't looked deeper into that because I didn't have a use for the onboard battery anyway.

[Brian]

D-Lite, on 19 December 2011 - 02:57 PM, said:

Yes, this shouldn't be too hard. But I'm looking for something smaller, that fits into the case of my old transmitter. The internals are modular so I could simply swap the R/F board  with an STM32/Bluetooth board. Well, just one of many options.

I'm building up a board now that's similar to the one that I showed at the end of the first post, except I epoxied a small PC board on the side to hold a JTAG, and other 0.1" spaced hardware, similar to the original box.  I originally planned on using just the 2mm spaced board, but decided that I would surely have to debug it, since it's going to have many more interfaces (7 ADC, 1 PWM, and 5 digital I/O, and 2 USART if I remember correctly).  It's a tight fit, but it looks like it's going to work.

[Reddog]

Brian, on 19 December 2011 - 01:36 PM, said:

Yes, the problem is mostly RAM.  I ported UAVtalk to the Arduino, but in order to handle more than a few message types, it requires a Mega, which are relatively big and expensive.  The STM32 is also much faster, and I was able to use the same code base, which is nice.

Like Kenn said, the Move controller is very similar to the CopterControl board.  It's a nice piece of hardware for the price.

I picked up the Mega so I can learn C/C++ programming, so I would love to get involved at a later stage.

[braindead4554]

Glad I could help and see your nice quad!  But I must admit, all of this is way above my head

Great job BTW

Edited by braindead4554, 21 December 2011 - 05:25 AM.

[Brian]

Update...  I finished the actual transmitter version.  This  version replaces the logic board of an old 6 channel Futaba transmitter.  The analog sticks and trims are wired to 8 ADC pins on the STM32.  A potentiometer is wired to another ADC pin, and the 5 switches are connected as GPIO.  This turns the 6 channel transmitter into a 10 channel transmitter!

The logic board includes 2 Xbee slots.  The first is for the primary Xbee telemetry connection to the quad.  The other is intended to connect the transmitter to a GCS.  Currently I'm using a low power Xbee for the GCS connection, but I might switch that to a WiFi (RV-XV) or Bluetooth Bee.

I'm also reading the RSSI off the primary Xbee as PWM, but I don't know how to send that back to the GCS yet.

This is a picture of the internals:

 IMG_20111224_160237.jpg   708.89K   26 downloads

, and this is the finished product:

 IMG_20111224_195222.jpg   643.36K   23 downloads

Merry Christmas everyone!

[K Wells]

This is totally cool Brian, I have a brand new Turnigy PPM 9 ready for this mod...

[Brian]

Hmm...  It looks like the 9X is hackable.  I don't know much about it, but it seems like it might be possible to connect the AVR processor with similar hardware to this, or a PipX and not only have a UAVTalk transmitter, but a GCS on the LCD display as well.  Seems like something to look into!

[K Wells]

Brian, on 25 December 2011 - 03:39 AM, said:

Hmm...  It looks like the 9X is hackable.  I don't know much about it, but it seems like it might be possible to connect the AVR processor with similar hardware to this, or a PipX and not only have a UAVTalk transmitter, but a GCS on the LCD display as well.  Seems like something to look into!

I can donate and ship it to you, if you like to further your project

[Brian]

K Wells, on 25 December 2011 - 03:49 AM, said:

I can donate and ship it to you, if you like to further your project

Thanks for the offer, but they're cheap enough if I decide to try it.  That may be a good route to go to take it to the next level, but now I would like to do some more testing and debugging on the software side to convince myself that it's going to work well.

[Reddog]

Brian, I have been watching your Git updates, getting more and more excited about your transmitter as the software goes up! Love your work mate!

[Brian]

I've been testing this fairly extensively lately, and it's working very well.  I'm just about complete with adding debug logging capability in UAVTalk so that I can get some statistics on latency and dropped packets due to congestion.

On a side note:  I let a co-worker/friend who only has experience with ArduCopter fly my mini quad with my modified transmitter today, and he commented that it seemed to fly much smoother than what he was used to.  He thought it might be that I have higher resolution in reading the controls in my radio than a standard radio, but I think it's just the CopterControl board and OpendPilot software!

[D-Lite]

Brian, on 29 December 2011 - 07:20 PM, said:

On a side note:  I let a co-worker/friend who only has experience with ArduCopter fly my mini quad with my modified transmitter today, and he commented that it seemed to fly much smoother than what he was used to.  He thought it might be that I have higher resolution in reading the controls in my radio than a standard radio, but I think it's just the CopterControl board and OpendPilot software!

Btw. what update rate are you using to send the control commands?

[Brian]

D-Lite, on 29 December 2011 - 07:47 PM, said:

Btw. what update rate are you using to send the control commands?

Currently I have it set to 50ms, which seem too short to me, but the receiver code reads every 20ms, an I didn't want to get too far from that for the initial tests.  The trade-off is balancing telemetry bandwidth with update rate.  I don't think it's hogging the telemetry channel too much, but I'll be know more when I get some more detailed message logging.