Author Topic: Set of libraries to manage RC incoming and outgoing pulses (RC Rx/Servos/ESC)  (Read 13316 times)

RC Navy

  • Jr. Member
  • **
  • Posts: 54
  • When you like, even too much, it is not enough!
Hi all,

Please find attached a set of asynchronous (non blocking) libraries dedicated to RC validated for the Digispark.

It manages:
- incoming pulses from standard Receivers -> <SoftRcPulseIn>: nice to read pulses from receivers
- outgoing pulses -> <SoftRcPulseOut>: nice to control servo and ESC

<SoftRcPulseIn> relies on another (also provided) library <TinyPinChange>.

All these libraries are provided with examples.

I have some other librairies to test with the Digispark before releasing them. Currently, they are only validated for UNO, ATtiny84 and ATtiny85 with the official arduino 1.03 (not the Digistump version for the Digispark).
As soon as I will have validated them for the Digispark, I will share them.

If you are curious, you can have a look to my RC dedicated (UNO/84/85 ready) libraries: http://p.loussouarn.free.fr/arduino/asynchrone/asynchrone.html.
Sorry, my site is in french, but if there is some interest with my librairies, I may translate to english...

Enjoy,

RC Navy

Bluebie

  • Sr. Member
  • ****
  • Posts: 486
These are really cool! TinyPinChange is an awesome addition too. I think we should include it in the digispark software, not just as a library, but build it right in to the attachInterrupt system! What do you think of this idea? Otherwise I think the TinyPinChange library should at least be built in to the Digispark software so all open source digispark projects can use it without people having to download. It's just too useful!

RC Navy

  • Jr. Member
  • **
  • Posts: 54
  • When you like, even too much, it is not enough!
Bluebie,

Quote
I think we should include it in the digispark software, not just as a library, but build it right in to the attachInterrupt system!
I provide this library "as is". You are completely free to tweak it as you need (I can give some support if needed). I created it because I wanted to use some pin change pins along with <SoftwareSerial>, but this one monopolizes the "pin change interrupt vector". That's why I also created a variant of <SoftwareSerial> but which relies on <TinyPinChange>: <SoftSerial>. Now, all the pin change is centralized into <TinyPinChange> as depicted below:


If you are not familiar with french language:
"Broches d'entrée" stands for "Input pins"
"Broches de sortie" stands for "Output pins"
"Sketch Utilisateur" stands for "User sketch"

I know that this approach adds some code overhead, but sketches are easier to write/debug and most important: all the code is asynchronous.
It's very easy to make several actions/tasks which seems to run in parallel. 8)

I hate to see delay() or pulseIn() in a sketch: all the sketch is blocked with these kind of functions, yuck!  delay() or pulseIn() are very nice to start programming with arduino, but when the tasks have to run "in parallel", we have to use some "advanced" programming using "asynchronous" approach.

It's amazing what we can do with a tiny microcontroller such as an ATtiny!

I continue to port/test my other libraries for the Digispak...

Regards,

RC Navy

bjh

  • Newbie
  • *
  • Posts: 31
Thanks for this!  I tried SoftRcPulseOut with a couple TowerPro SG90s and it seemed to basically work  :)   I still plan to finish my own (synchronous) library SimpleServo which jitters less in my testing, but it'll be nice to have options.


Being able to read input from an RC receiver has some intriguing possibilities, too.  Thanks again!

RC Navy

  • Jr. Member
  • **
  • Posts: 54
  • When you like, even too much, it is not enough!
Hi bjh,

Quote
I still plan to finish my own (synchronous) library SimpleServo which jitters less in my testing
The trick I used in SoftRcPulseOut to cancel the jitter consists of masking interruptions juste before each edge (rising and falling) and unmasking interruptions just after  each edge (rising and falling). It's very easy for the rising edge because you know when this occurs, but more tricky for the falling edge. Knowing the pulse duration, I mask interruptions some timer ticks before the falling edge (anticipation). This means that all interruptions are delayed, but we have to deal with some compromise. For most of interruptions, it's not critical, but for some other which are time sensitive, it may be...
With this trick, interruptions are served between each edge, because they are not masqued (juste around the edges).
You can have a look inside the SoftRcPulseOut.cpp file.

Hope this helps to solve your jitter issue.
 
RC Navy
« Last Edit: March 03, 2013, 02:40:28 am by RC Navy »

bjh

  • Newbie
  • *
  • Posts: 31
Interesting, I wondered what you'd done, since SoftRcPulseOut works much better for me than SoftwareServo did; nevertheless these servos twitch for a while after they reposition.  I think they may just be relatively sensitive, I haven't tried the other random servos I have, and was just fiddling with the knob example, so nothing fancy there.

Mark

  • Full Member
  • ***
  • Posts: 196
@bjh

I would suggest you stick a capacitor between the wiper and ground of your knob. (0.1uF is enough)
It could be a small variation in the ADC reading is causing the jitter.

It could also be small fluctuations in the power supply, so drop a 47, 100uF or even bigger across the supply to the servo, in case you're chasing something that is not the software....

Of course you could also set some values up to eliminate this ...but the caps across the supply are highly recommended (IMO).


Mark

RC Navy

  • Jr. Member
  • **
  • Posts: 54
  • When you like, even too much, it is not enough!
Hi bjh,
Quote
Interesting, I wondered what you'd done, since SoftRcPulseOut works much better for me than SoftwareServo did.
Initially, I used <SoftwareServo> library, but I was frustrated with the jitter. The name of this library was also confusing: it seems to work only with servos whereas it can be used for every device that can be controlled with a proportionnal receiver channel (servos, ESC, multi-switches...).
That's why I named my library <SoftRcPulseOut>. As indicated in the source, it is mainly derived from <SotwareServo> but with some improvements.
After that, I decided to write the symetrical library: <SoftRcPulseIn> for incoming RC pulses. Its name also reminds the blocking pulseIn() arduino function. ;)

You've got all the story...

As suggested by Mark, some capacitors can help to have a cleaner power supply. An external power supply is recommended for the servos since USB can only provide around 500mA. For a single one, it's sufficient if the requested torque is low.

RC Navy.
« Last Edit: March 04, 2013, 04:53:29 am by RC Navy »

bjh

  • Newbie
  • *
  • Posts: 31
These are small micro servos and I've been testing with no load so I didn't suspect power to be an issue, but the capacitors make all the difference!  100uF on the servo power reduced the jitter, a few of them helped more, and I get smooth, solid, action with a fat 3300uF buffering it.


A cap on the pot wiper didn't seem to change anything.  Not sure why the syncronously bit-banged version worked without the capacitor, but I'm glad to find a solution  :)

Mark

  • Full Member
  • ***
  • Posts: 196
@bjh

Never under-estimate the power of filtering.

The Digispark is a great device but is seriously under filtered, given some of the loads possible.
If in doubt put a 100 or 1000uF capacitor across the supply, long with a 0.1 and see what happens.

Is it possible that with the bit banging, you weren't reading the ADC quick so quickly or averaging it.?

For any motor, the energy required to get it moving is usually 2-3 times the amount to run at a constant speed.
It is also likely to be very electrically noisy, which can have an effect on the regulator.
Hence the first jitter, can induce more jitter.

Keep up the good work.

Mark

bjh

  • Newbie
  • *
  • Posts: 31

Quote
Never under-estimate the power of filtering.[/size]

Wow, I'm learning that!


Quote
Is it possible that with the bit banging, you weren't reading the ADC quick so quickly or averaging it.?For any motor, the energy required to get it moving is usually 2-3 times the amount to run at a constant speed.It is also likely to be very electrically noisy, which can have an effect on the regulator.Hence the first jitter, can induce more jitter.



Probably more to do with the synchronous design: read ADC, signal servo for some (on this scale, not small) amount of time, read ADC again...  Thus the noise might have settled down before signaling ended.


Quote

Keep up the good work.



Thanks!  I figure I'll still post the 1.0 version of my library (since it's basically done) in case it helps anyone, but point folks to SoftRcPulseOut and Mark's Capacitor Emporium  ;)


--bjh


digistump

  • Administrator
  • Hero Member
  • *****
  • Posts: 1465
These are now also included in the official release. http://digistump.com/wiki/digispark/tutorials/connecting#software


Thanks RC Navy for making these - let us know if you have any problem with their inclusion.