Related
Recommended

PicoScope 6424E Oscilloscope + Accessories: Methodology

colporteur

The Pico Oscilloscope RoadTest Review is currently in a holding pattern due to a shipping error. I figured I would fill the wait time by sharing the methodology or my approach for the RoadTest. I value the input from members. On past RoadTest their commentary has improved my review by providing knowledge I didn't have, thereby enabling me to correct details I stated in error.

 

My application offered to review the equipment while analyzing servo motor operation. Recently, I discovered a tutorial I wrote in June 2019, demonstrating servo motors on a Raspberry Pi, doesn't work today. My preliminary investigation of the servo problem was interrupted by "SQUIRREL" https://www.youtube.com/watch?v=SSUXXzN26zg .  The RoadTest Review of the oscilloscope was an opportunity I felt would force me to focus on the task at hand. Why are the servo motors not working on the Pi?

 

It appears the endorsement for operating servo motors is higher on microcontroller like an Arduino rather than on a single board computer (SBC) like the Pi. Raspberry Pi's are running an operating system that shares the signalling of the servo with a host of other tasks the operating system is managing. The multitasking environment impacts the servo's performance. I plan to analyze the servo motor signals using the Pico oscilloscope to uncover the knowledge that will hopefully improve my understanding.

 

I'm initially looking at three areas that influence the servo operation. Microcontroller vs SBC. The servo motors themselves. How the signal are generated through code.

  • The test platforms that will generate the servo signals will be a Raspberry Pi3B+ GPIO outputs and GPIO's on an OEM Arduino Nano.
  • The servos being used are Tower Pro SG92R & SR90.
  • The code will be python on the Pi and C++ on the Arduino. I suspect the signals themselves produced by the Pi or Arduino are impacted by the code solution. i.e. using a defined method or producing the signal raw. This is an area of particular interest. I will give it my best shot. Unfortunately, I lack the programming background to fully investigate.

 

I confess my testing methodology is not consistent i.e. not using same code on both devices. If I step back and not get buried in the weeds, my goal is to evaluate the Pico 6424E Oscilloscope and not write a research paper on the operation of servo motor. If that was the task I would reserve it for more talented people in this community than me.

 

Here is what I have for code solutions to operate a servo motor.

Raspberry Pi:

  • RPi.gpio
  • gpiozero
  • wiringpi

 

Arduino:

  • Servo.h
  • manual define servoPin 9........

 

A question to members: what code solutions are you using to control servo's?

 

To reiterate, the goal is to review the Pico 6424E Oscilloscope. The devices are being used just to produce the signals for the scope. I may not arrive at an answer to my problem but I am confident the equipment will enable me to at least look at the signals.

 

The review needs to include both analogue (probe) and digital (MSO) capabilities of the oscilloscope. My experience using oscilloscope stopped in the mid 90's when my career moved from electronic support to computer support. I have some challenges in blowing off the accumulated dust on the knowledge I have as well as the changes in technology in twenty years.

  • in reply to genebren

    Way out beyond my depth. I need tanks to go that deep.

  • in reply to colporteur

    Walky used c-code directly complied to the ATmega328PB processor (not Arduino), which is included in the 'final' link as an attachment.

  • in reply to genebren

    Thanks for the input.

     

    Your walky was using what code to drive the servo? I only know of the two, I mentioned both in my post. Am I safe to assume it sourced servo.h?

  • Sean,

     

    I have built a few different products that feature servo control, based on an implementation on the ATmega328PB (like on a classic Nano).  The two products differ in how that process the servo signals, but they both rely on the 16-bit timers of the ATmega328PB.

     

    On my WalkyII biped robot (Walky the Biped Robot - WalkyII gets a new brain (hardware) and Walky the Biped Robot - WalkyII the final chapter. (code)), I use two timer channels (Timer1 and Timer3) to each generate 2 PWM signals, for a total of 4 outputs.  This approach provided buffered connection between the ATmega328PB and the servos.

     

    On another product I develop 12 servo channels driven from a single timer with two outputs.  The two outputs are provided to a pair of 1:6 demultiplexers (made up of P-Channel MOSFETs) to drive the 12 output channels.  The timer is setup to reach terminal count in 3.125 mSec and the PWM compare registers are set to a value between 500 and 2500 (0.5 to 2.5ms).  When the larger of the two timers values is detected (via interrupts), the software switches to the next channel on the demultiplexers and loads the PWM compare registers for the next pair of pulses.  This process continues through the six channels and includes two blank channels for a total servo frame rate of 25ms (8 * 3.125ms). Since the PWM pluse widths are handled directly by the timers, the resulting pulses are very clean and jitter free.

     

    Good luck on your servo control study and roadtest in general.

     

    Gene

     

    P.S. I love my PicoScope 5444D MSO.