SPI in WPILib

227 views
Skip to first unread message

jrothr...@hdsd.org

unread,
Jun 30, 2020, 11:46:08 PM6/30/20
to vmx-pi
I have finally finished my schoolwork and have begun to play around with the VMX-Pi a bit.  I do not know if I mentioned this (and if so, sorry), but the updates are working for I2c.  I have the color sensor and a Pixy2 working through I2c.  I am using the Pseudo Resonance library for the Pixy2 and though it is working for the most part, moving the servos for the attached base lock up the pixy.  I am wondering if the issue could be that I2C does not have the bandwidth for setting the servos.  

I am using the MXP port (by selecting option 4 in the init method).  I also tried changing the clock rate.  It did not help either.

Pseudo Resonance says they recommend using SPI instead.  When trying to get that to work, I get the following errors...


VMX HAL: SIGTERM signal received.
VMX HAL: closing pigpio library to release VMX resources.
At VMXPi::Terminate
VMX HAL: pigpio library closed and VMX resources released.
Robots should not quit, but yours did!
Warning at edu.wpi.first.wpilibj.RobotBase.runRobot(RobotBase.java:291): Robots should not quit, but yours did!
Unexpected return from startCompetition() method.
Error at edu.wpi.first.wpilibj.RobotBase.runRobot(RobotBase.java:297): Unexpected return from startCompetition() method.
Error! Inactive Notifier discovered during HAL_WaitForNotifierAlarm.Thu Jun 25 11:18:06 2020 - WARN : Error clearing CAN HW RX Buffer 0 Filter 0.
(VMXCAN.cpp [922])
Thu Jun 25 11:18:06 2020 - WARN : Error clearing CAN HW Mask for RX Buffer 0.
(VMXCAN.cpp [937])
*******VMX HAL SPIClient Performance*******

- Writes:
Total #: 27
Avg Us: 151
Min Us: 63
Max Us: 283
# long: 0
# lng2: 0
# lng3: 0
MinWait: 25
MaxWait: 73

Write CRC Errors: 0
Write Retries: 0
Write Failures: 0

- Reads:
Total #: 226760
Avg Us: 199
Min Us: 51
Max Us: 303
# long: 1
# lng2: 0
# lng3: 0
MinWait: 12
MaxWait: 24

Read CRC Errors: 0
Read Retries: 0
Read Failures: 0
*******************************************
2020-06-25 11:18:06 spiClose: pigpio uninitialised, call gpioInitialise()
VMX HAL: Error closing SPI AUX Channel 2.
Entering VMX HAL Internal Kill Handler.
Entering VMX HAL Internal Kill Handler.
MAU HAL: Error expiring IO Watchdog.


I did not post as a bug as I am wondering if I am doing something wrong. Does anyone have any idea what that could be?

I am using the following tutorial.
This hardware is amazing.  Thank you.
~Jacob

Scott Libert

unread,
Jul 1, 2020, 6:47:13 PM7/1/20
to vmx-pi
Hi Jacob,

1) Regarding I2C, if you want to run the I2C bus at a higher rate (400Kbps) rather than run at the default 100Kbps, please follow these instructions:

By default, the Raspberry Pi I2C bus speed is 100Khz (“Standard Mode”). To change the bus speed to 400Khz (Fast Mode) follow these I2C bus speed configuration instructions. Note that the I2C-capable device to which VMX-pi is connected may only communicate at a lower speed than 400Khz; consult the external device technical documentation for further details.

2) Unfortunately, there aren't any clues in the logs you attached to your message regarding troubles accessing SPI.  Can you please send or attach a copy of your code and we can review that and perhaps try to reproduce it on our side?

- scott

jrothr...@hdsd.org

unread,
Jul 1, 2020, 10:29:27 PM7/1/20
to vmx-pi
Scott,
Thank you.  That is helpful info about the I2C speed.  I will look into it and report back.  If that works, I am not sure our team needs SPI.  It is also possible that the servos

As for the SPI, I have not uploaded our code to git but will post it below.  Is there a test you know of that I could do to easily ensure I have SPI set up and working? 

Here is our code...
Robot.java

/*----------------------------------------------------------------------------*
/
/* Copyright (c) 2018 FIRST. All Rights Reserved.
*/
/* Open Source Software - may be modified and shared by FRC teams. The code
*/
/* must be accompanied by the FIRST BSD license file in the root directory of
*/
/* the project.
*/
/*----------------------------------------------------------------------------*/

package frc.robot;

import java.util.ArrayList;
import edu.wpi.first.wpilibj.TimedRobot;
import edu.wpi.first.wpilibj.smartdashboard.SmartDashboard;
import io.github.pseudoresonance.pixy2api.*;
import io.github.pseudoresonance.pixy2api.Pixy2CCC.Block;
import io.github.pseudoresonance.pixy2api.links.SPILink;
/**
* PIXY SPI EXAMPLE
* A few notes
* 1.) Two things need to be added to the build.gradle file. See the attached
tutorial document
* 2.) This code is for using Chip Select 0 (CS0) and the onboard SPI Port
* 3.) If you are using SPI mode, go into PixyMon and set the control mode to
SPI
*/
public class Robot extends TimedRobot {
  /**
* This function is run when the robot is first started up and should be used
* for any initialization code.
*/
private Pixy2 pixycam;
boolean isCamera = false ;
//private SPILink spi;
int state=- 1 ;
@Override
public void robotInit () {

 pixycam = Pixy2.createInstance(new SPILink()); // Creates a new Pixy2 camera using SPILink
  }
 

@Override
public void teleopPeriodic () {
if (!isCamera)
state = pixycam.init(4); // if no camera present, try to initialize
isCamera = state>= 0 ;
pixycam.setLamp((byte) 1, (byte) 1);
SmartDashboard.putBoolean( "Camera" , isCamera); //publish if we are connected
pixycam.getCCC().getBlocks( false , 255 , 255 ); //run getBlocks with arguments to have the camera
SmartDashboard.putNumber( "Stuff" , pixycam.getCCC().getBlocks() );
//acquire target data
ArrayList<Block> blocks = pixycam.getCCC().getBlockCache(); //assign the data to an ArrayList for convinience
if (blocks.size() > 0 )
{
double xcoord = blocks.get( 0 ).getX(); // x position of the largest target
double ycoord = blocks.get( 0 ).getY(); // y position of the largest target
String data = blocks.get( 0 ).toString(); // string containing target info
SmartDashboard.putBoolean( "present" , true ); // show there is a target present
SmartDashboard.putNumber( "Xccord" ,xcoord);
SmartDashboard.putNumber( "Ycoord" , ycoord);
SmartDashboard.putString( "Data" , data );
}
else
SmartDashboard.putBoolean( "present" , false );
SmartDashboard.putNumber( "size" , blocks.size());//push to dashboard how many targets are detected 

}
}


build.gradle...

plugins {
    id "java"
    id "com.kauailabs.first.GradleRIO" version "2020.3.2.1"
}

sourceCompatibility = JavaVersion.VERSION_11
targetCompatibility = JavaVersion.VERSION_11

def ROBOT_MAIN_CLASS = "frc.robot.Main"

// Define my targets (RoboRIO) and artifacts (deployable files)
// This is added by GradleRIO's backing project EmbeddedTools.
deploy {
    targets {
        vmxpi("roborio") {
            // Team number is loaded either from the .wpilib/wpilib_preferences.json
            // or from command line. If not found an exception will be thrown.
            // You can use getTeamOrDefault(team) instead of getTeamNumber if you
            // want to store a team number in this file.
            team = frc.getTeamNumber()
        }
    }
    artifacts {
        frcJavaArtifact('frcJava') {
            targets << "roborio"
            // Debug can be overridden by command line, for use with VSCode
            debug = frc.getDebugOrDefault(false)
        }
        // Built in artifact to deploy arbitrary files to the roboRIO.
        fileTreeArtifact('frcStaticFileDeploy') {
            // The directory below is the local directory to deploy
            files = fileTree(dir: 'src/main/deploy')
            // Deploy to RoboRIO target, into /home/lvuser/deploy
            targets << "roborio"
            directory = '/home/lvuser/deploy'
        }
    }
}

repositories {
}

// Set this to true to enable desktop support.
def includeDesktopSupport = false

// Defining my dependencies. In this case, WPILib (+ friends), and vendor libraries.
// Also defines JUnit 4.
dependencies {
    implementation wpi.deps.wpilib()
    nativeZip wpi.deps.wpilibJni(wpi.platforms.raspbian)
    nativeDesktopZip wpi.deps.wpilibJni(wpi.platforms.desktop)


    implementation wpi.deps.vendor.java()
    nativeZip wpi.deps.vendor.jni(wpi.platforms.raspbian)
    nativeDesktopZip wpi.deps.vendor.jni(wpi.platforms.desktop)
    implementation 'pw.otake.pseudoresonance:pixy2-java-api:1.4'

    testImplementation 'junit:junit:4.12'

    // Enable simulation gui support. Must check the box in vscode to enable support
    // upon debugging
    simulation wpi.deps.sim.gui(wpi.platforms.desktop, false)
}

// Setting up my Jar File. In this case, adding all libraries into the main jar ('fat jar')
// in order to make them all available at runtime. Also adding the manifest so WPILib
// knows where to look for our Robot Class.
jar {
    from { configurations.runtimeClasspath.collect { it.isDirectory() ? it : zipTree(it) } }
    manifest edu.wpi.first.gradlerio.GradleRIOPlugin.javaManifest(ROBOT_MAIN_CLASS)
}


Scott Libert

unread,
Jul 1, 2020, 10:55:34 PM7/1/20
to vmx-pi
> As for the SPI, I have not uploaded our code to git but will post it below.  

Thanks, I took a quick look and found the SPILink source code, it does appear to be using SPI.Port.kOnboardCS0.  That should work.

Can you run it again and see if the output in the log looks any different?  The one that you sent isn't giving us many clues, perhaps another run might yield more info.

> Is there a test you know of that I could do to easily ensure I have SPI set up and working? 

If you have a navX-MXP, you can connect the SPI port pins to the RoboRIO Onboard SPI port, and use the "Data Monitor" example code (change the port passed to the AHRS class constructor to SPI.Port.kOnboardCS0 to match what SPILink is doing) and see if that works.  That's the test case that we use to verify WPI Library SPI support on VMX-pi here in our labs.  Link to Data Monitor Example page:  https://pdocs.kauailabs.com/navx-mxp/examples/data-monitor/

Hope that helps,

- scott

jrothr...@hdsd.org

unread,
Jul 1, 2020, 11:09:18 PM7/1/20
to vmx-pi
Scott, 
Thank you.  I do not have a Navx MXP here, but I am going in to begin cleaning my classroom tomorrow, so I may be able to grab one (if we did not bury it when we cleaned up the shop).

I also tried using the MXP port, but that gave the same results.  

I tried to get a more verbose log by selecting Detail Tags.  Here it is below. I started from a reboot (hence the bad ping results in the beginning).

~Jacob

<TagVersion>1 <time> 00.000 <count> 1 <flags> 2 <Code> 44002 <details> Ping Results:  link-bad,  DS radio(.4)-bad,  robot radio(.1)-bad,  roboRIO(.2)-bad,  FMS-bad FRC:  Driver Station ping status has changed. <location> Driver Station <stack> 
<TagVersion>1 <time> 00.000 <message> VMX HAL:  pigpio library version 69 opened. 
<TagVersion>1 <time> 00.000 <message> VMX HAL:  SPI Aux Channel 2 opened with baudrate of 4000000. 
<TagVersion>1 <time> 00.000 <message> Retrying Read.... 
<TagVersion>1 <time> 00.000 <message> VMX HAL:  Error reading from bank 0, address 0, length 4. 
<TagVersion>1 <time> 00.000 <message> Read Aborted! 
<TagVersion>1 <time> 00.000 <message> VMX HAL:  Established communication with VMX-pi model 0x32, hardware rev 60, firmware version 3.0.411 
<TagVersion>1 <time> 00.000 <message> VMX HAL:  Acquired navX-Sensor configuration. 
<TagVersion>1 <time> 00.000 <message> VMX HAL:  Library version 1.1.225 
<TagVersion>1 <time> 00.000 <message> Set VMX CAN Mode to NORMAL. 
<TagVersion>1 <time> 00.000 <message> Server Running... 
<TagVersion>1 <time> 00.000 <message> ********** Robot program starting ********** 
<TagVersion>1 <time> 00.000 <message> Default simulationInit() method... Override me! 
<TagVersion>1 <time> 00.000 <message> Default disabledInit() method... Override me! 
<TagVersion>1 <time> 00.000 <message> Default disabledPeriodic() method... Override me! 
<TagVersion>1 <time> 00.000 <message> Default robotPeriodic() method... Override me! 
<TagVersion>1 <time> 00.000 <message> Watchdog not fed within 0.020000s 
<TagVersion>1 <time> 00.000 <message> Default simulationPeriodic() method... Override me! 
<TagVersion>1 <time> 00.000 <count> 1 <flags> 0 <Code> 1 <details> Loop time of 0.02s overrun
 <location> edu.wpi.first.wpilibj.IterativeRobotBase.printLoopOverrunMessage(IterativeRobotBase.java:309) <stack> 
<TagVersion>1 <time> 00.000 <message> Warning at edu.wpi.first.wpilibj.IterativeRobotBase.printLoopOverrunMessage(IterativeRobotBase.java:309): Loop time of 0.02s overrun 
<TagVersion>1 <time> 00.000 <message>  
<TagVersion>1 <time> 00.000 <message> SmartDashboard.updateValues(): 0.008132s 
<TagVersion>1 <time> 00.000 <message> disabledInit(): 0.001855s 
<TagVersion>1 <time> 00.000 <message> disablePeriodic(): 0.000379s 
<TagVersion>1 <time> 00.000 <message> robotPeriodic(): 0.000101s 
<TagVersion>1 <time> 00.000 <message> LiveWindow.updateValues(): 0.011141s 
<TagVersion>1 <time> 00.000 <message> Shuffleboard.update(): 0.000037s 
<TagVersion>1 <time> 00.000 <message> simulationPeriodic(): 0.053747s 
<TagVersion>1 <time> 00.000 <count> 1 <flags> 2 <Code> 44003 <details> FRC:  No robot code is currently running. <location> Driver Station <stack> 
<TagVersion>1 <time> 00.000 <count> 1 <flags> 2 <Code> 44002 <details> Ping Results:  link-bad,  DS radio(.4)-bad,  robot radio(.1)-bad,  roboRIO(.2)-GOOD,  FMS-bad FRC:  Driver Station ping status has changed. <location> Driver Station <stack> 
<TagVersion>1 <time> 00.000 <message> NT: server: client CONNECTED: 10.67.62.11 port 64778 
<TagVersion>1 <time> 00.000 <message> Default teleopInit() method... Override me! 
<TagVersion>1 <time> 00.000 <message> Thu Jun 25 11:17:34 2020 - WARN :  Error deactivating Resource type 9, index 0 
<TagVersion>1 <time> 00.000 <message>  (VMXIO.cpp [1214]) 
<TagVersion>1 <time> 00.000 <message> 2020-06-25 11:17:34 spiOpen: bad baud (2000) 
<TagVersion>1 <time> 00.000 <message> Watchdog not fed within 0.020000s 
<TagVersion>1 <time> 00.000 <count> 1 <flags> 0 <Code> 1 <details> Loop time of 0.02s overrun
 <location> edu.wpi.first.wpilibj.IterativeRobotBase.printLoopOverrunMessage(IterativeRobotBase.java:309) <stack> 
<TagVersion>1 <time> 00.000 <message> Warning at edu.wpi.first.wpilibj.IterativeRobotBase.printLoopOverrunMessage(IterativeRobotBase.java:309): Loop time of 0.02s overrun 
<TagVersion>1 <time> 00.000 <message>  
<TagVersion>1 <time> 00.000 <message> teleopPeriodic(): 5.023429s 
<TagVersion>1 <time> 00.000 <message> SmartDashboard.updateValues(): 0.000027s 
<TagVersion>1 <time> 00.000 <message> robotPeriodic(): 0.000010s 
<TagVersion>1 <time> 00.000 <message> LiveWindow.updateValues(): 0.000022s 
<TagVersion>1 <time> 00.000 <message> Shuffleboard.update(): 0.000010s 
<TagVersion>1 <time> 00.000 <message> simulationPeriodic(): 0.000004s 
<TagVersion>1 <time> 00.000 <message> teleopInit(): 0.000276s 
<TagVersion>1 <time> 00.000 <message> 2020-06-25 11:17:39 spiOpen: bad baud (2000) 
<TagVersion>1 <time> 00.000 <message> Thu Jun 25 11:17:39 2020 - WARN :  Error deactivating Resource type 9, index 0 
<TagVersion>1 <time> 00.000 <message>  (VMXIO.cpp [1214]) 
<TagVersion>1 <time> 00.000 <count> 1 <flags> 1 <Code> 1 <details> Unhandled exception: edu.wpi.first.hal.util.UncleanStatusException:  Code: -20013. Error configuring physical resource <location> io.github.pseudoresonance.pixy2api.links.SPILink.open(SPILink.java:65) <stack> at edu.wpi.first.hal.SPIJNI.spiInitialize(Native Method)
at edu.wpi.first.wpilibj.SPI.<init>(SPI.java:48)
at io.github.pseudoresonance.pixy2api.links.SPILink.open(SPILink.java:65)
at io.github.pseudoresonance.pixy2api.Pixy2.init(Pixy2.java:125)
at frc.robot.Robot.teleopPeriodic(Robot.java:52)
at edu.wpi.first.wpilibj.IterativeRobotBase.loopFunc(IterativeRobotBase.java:267)
at edu.wpi.first.wpilibj.TimedRobot.startCompetition(TimedRobot.java:86)
at edu.wpi.first.wpilibj.RobotBase.runRobot(RobotBase.java:276)
at edu.wpi.first.wpilibj.RobotBase.startRobot(RobotBase.java:348)
at frc.robot.Main.main(Main.java:27)

<TagVersion>1 <time> 00.000 <message> Error at io.github.pseudoresonance.pixy2api.links.SPILink.open(SPILink.java:65): Unhandled exception: edu.wpi.first.hal.util.UncleanStatusException:  Code: -20013. Error configuring physical resource 
<TagVersion>1 <time> 00.000 <message> at edu.wpi.first.hal.SPIJNI.spiInitialize(Native Method) 
<TagVersion>1 <time> 00.000 <message> at edu.wpi.first.wpilibj.SPI.<init>(SPI.java:48) 
<TagVersion>1 <time> 00.000 <message> at io.github.pseudoresonance.pixy2api.links.SPILink.open(SPILink.java:65) 
<TagVersion>1 <time> 00.000 <message> at io.github.pseudoresonance.pixy2api.Pixy2.init(Pixy2.java:125) 
<TagVersion>1 <time> 00.000 <message> at frc.robot.Robot.teleopPeriodic(Robot.java:52) 
<TagVersion>1 <time> 00.000 <message> at edu.wpi.first.wpilibj.IterativeRobotBase.loopFunc(IterativeRobotBase.java:267) 
<TagVersion>1 <time> 00.000 <message> at edu.wpi.first.wpilibj.TimedRobot.startCompetition(TimedRobot.java:86) 
<TagVersion>1 <time> 00.000 <message> at edu.wpi.first.wpilibj.RobotBase.runRobot(RobotBase.java:276) 
<TagVersion>1 <time> 00.000 <message> at edu.wpi.first.wpilibj.RobotBase.startRobot(RobotBase.java:348) 
<TagVersion>1 <time> 00.000 <message> at frc.robot.Main.main(Main.java:27) 
<TagVersion>1 <time> 00.000 <message>  
<TagVersion>1 <time> 00.000 <count> 1 <flags> 0 <Code> 1 <details> Robots should not quit, but yours did! <location> edu.wpi.first.wpilibj.RobotBase.runRobot(RobotBase.java:291) <stack> 
<TagVersion>1 <time> 00.000 <message> Warning at edu.wpi.first.wpilibj.RobotBase.runRobot(RobotBase.java:291): Robots should not quit, but yours did! 
<TagVersion>1 <time> 00.000 <count> 1 <flags> 1 <Code> 1 <details> The startCompetition() method (or methods called by it) should have handled the exception above. <location> edu.wpi.first.wpilibj.RobotBase.runRobot(RobotBase.java:293) <stack> 
<TagVersion>1 <time> 00.000 <message> Error at edu.wpi.first.wpilibj.RobotBase.runRobot(RobotBase.java:293): The startCompetition() method (or methods called by it) should have handled the exception above. 
<TagVersion>1 <time> 00.000 <message> # 
<TagVersion>1 <time> 00.000 <message> # A fatal error has been detected by the Java Runtime Environment: 
<TagVersion>1 <time> 00.000 <message> # 
<TagVersion>1 <time> 00.000 <message> #  SIGSEGV (0xb) at pc=0xa4218328, pid=614, tid=670 
<TagVersion>1 <time> 00.000 <message> # 
<TagVersion>1 <time> 00.000 <message> # JRE version: OpenJDK Runtime Environment (11.0.7+10) (build 11.0.7+10-post-Raspbian-3deb10u1) 
<TagVersion>1 <time> 00.000 <message> # Java VM: OpenJDK Server VM (11.0.7+10-post-Raspbian-3deb10u1, mixed mode, concurrent mark sweep gc, linux-) 
<TagVersion>1 <time> 00.000 <message> # Problematic frame: 
<TagVersion>1 <time> 00.000 <message> # C  [libvmxpi_hal_cpp.so+0xb2328]  gpioRead+0xe8 
<TagVersion>1 <time> 00.000 <message> # 
<TagVersion>1 <time> 00.000 <message> # No core dump will be written. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again 
<TagVersion>1 <time> 00.000 <message> # 
<TagVersion>1 <time> 00.000 <message> # An error report file with more information is saved as: 
<TagVersion>1 <time> 00.000 <message> # //hs_err_pid614.log 
<TagVersion>1 <time> 00.000 <message> [thread 676 also had an error] 
<TagVersion>1 <time> 00.000 <count> 1 <flags> 2 <Code> 44004 <details> FRC:  The Driver Station has lost communication with the robot. <location> Driver Station <stack> 
<TagVersion>1 <time> 00.000 <count> 1 <flags> 2 <Code> 44002 <details> Ping Results:  link-bad,  DS radio(.4)-bad,  robot radio(.1)-bad,  roboRIO(.2)-GOOD,  FMS-bad FRC:  Driver Station ping status has changed. <location> Driver Station <stack> 

Scott Libert

unread,
Jul 2, 2020, 2:39:06 PM7/2/20
to vmx-pi
Looks like this is where things go south:

11:17:34 spiOpen: bad baud (2000) 

I did see that baudrate in the code, it’s way too low for meaningful communication.

The logs indicate SPiLink is setting spi baud rate to 2000 (very very low, no idea why).  VMX-pi issues an error message and things go south from there.

I’m thinking that roborio increases the spi bitrate to some time quantum to make it reasonable, and VMX pi does not.

I will research more and let you know what some options are.

Scott Libert

unread,
Jul 2, 2020, 2:57:23 PM7/2/20
to vmx-pi
Here are the min/max baudrates available for SPI on the raspberry pi; these are the limits enforced now by the VMX-pi libraries:

#define PI_SPI_MIN_BAUD     32000
#define PI_SPI_MAX_BAUD    125000000

This issue you've reported would be resolved by increasing the baudrate in the SPILink code.

The value being used now in the SPILink code is 2000 (way too low to be useful, that translates to 200 bytes/second at best).  

The roborio docs for SPI bitrate configuration says:

"Configure the rate of the generated clock signal. The default value is 500,000 Hz. The maximum value is 4,000,000 Hz."

Perhaps RoboRIO internally increases the bitrate to something more reasonable when it sees the request for the paltry 2000 bits/second.  Or perhaps RoboRIO actually just operates at 2000 bits/second.

It's possible to modify the VMX-pi WPI HAL to transparently increase the bitrate to the minimum.  But I'm not yet convinced that's the best course to take.

My recommendation is to check w/the author of the SPILink code, and ask them to modify the bitrate they are requesting from roborio to something that reflects what is actually needed - I can't imagine 2000 bits/second is a good value.

I also think I2C should work, and as we've discussed you have control over the bitrate for that (either 100000 bps or 400000 bps).

Scott Libert

unread,
Jul 2, 2020, 3:10:55 PM7/2/20
to vmx-pi
One final followup, found this on the Pixy2 page describing SPI:

The default data rate is 2 mbits/sec

So I think the SPILink code should be changed to add three zeros to the bitrate it's requesting now, which would replace the existing 2000 with 2000000.  This would match the default SPI bitrate mentioned on the Pixy2 website.

jrothr...@hdsd.org

unread,
Jul 2, 2020, 3:25:14 PM7/2/20
to vmx-pi
Thanks for looking into this.  
I am not convinced the speed is the issue with the I2C.   I played around a bit today, and though I do not have it working, I have made some headway and with this information, I am definitely thinking the library is the issue.

I will begin with SPI.
I did grab our old NavX.  It worked perfectly over SPI.  Thank you for the suggestion. This is a cool development. We may take advantage of this in the future.

Then, I used the Pixy again (both with Slave Select, I am assuming that is what you all call CS, and without). The error was the same.

Then, I went back to the I2C after changing the Baud Rate on the Raspberry pi.

The issues with set servo are the same as before (with the I2C).  The I2C Issues are, it seems to work fine until I envoke the servos.  In that case, they move in small increments toward the chosen position, but they never get there.  Even on reboot, they still try to get to the chosen point (I am not using PID yet, I am just setting them using straight integers converted to bytes, I also tried to send them as INtegers, and the result was the same).  

I am thinking that it may be easiest to just set the servos directly with the VMXPi rather than spend the time to troubleshoot all of this.  Do you think there is any risk of frying them if I do that?

The whole point of all of this is to learn how to use PID to track objects, and that is doable without the servos.

jrothr...@hdsd.org

unread,
Jul 2, 2020, 3:26:48 PM7/2/20
to vmx-pi
I wonder if the baudrate is set by the Pixy itself (there is a setting).  I will look into that.

jrothr...@hdsd.org

unread,
Jul 2, 2020, 3:29:09 PM7/2/20
to vmx-pi
Edit: the set baudrate on the pixy is for UART.

Scott Libert

unread,
Jul 2, 2020, 3:34:19 PM7/2/20
to vmx-pi
I did grab our old NavX.  It worked perfectly over SPI.  Thank you for the suggestion. This is a cool development. We may take advantage of this in the future.

You can either access the navX-sensor that's built directly into VMX-pi, or you can access an external navX-sensor (e.g., navX-MXP over SPI/I2C/USB or navX-Micro over I2C/USB).

The issues with set servo are the same as before (with the I2C).  The I2C Issues are, it seems to work fine until I envoke the servos.  In that case, they move in small increments toward the chosen position, but they never get there.  Even on reboot, they still try to get to the chosen point (I am not using PID yet, I am just setting them using straight integers converted to bytes, I also tried to send them as INtegers, and the result was the same).  

Sounds like not enough power to the servos, either an issue w/the values used in the control algorithm, or perhaps that the servos don't have sufficient power.

> I am thinking that it may be easiest to just set the servos directly with the VMXPi rather than spend the time to troubleshoot all of this.  Do you think there is any risk of frying them if I do that?

Sound work, just keep in mind the current limits imposed by the VMX-pi (~500mA) - but you can only output 5VDC max.  You may want to consider an external servo power supply, like the REV Servo Power Module (https://www.revrobotics.com/rev-11-1144/).  Servos often want up to 6VDC, so if  you're needing more torque it'd be good review the servo power requirements.

On Tuesday, June 30, 2020 at 5:46:08 PM UTC-10, jrothr...@hdsd.org wrote:

Jacob Roth-Ritchie

unread,
Jul 2, 2020, 6:07:27 PM7/2/20
to vmx-pi
I think you are onto something there. I will explore the power piece. Since I am using a VEX drive system, I am running 7.4 Volts, not 12. There is a regulated input on the Pixy (that accepts 6-10 Volts) so I will give it a slot in the PDP and see if that is all it takes to fix the I2C issue. Otherwise, I will use that power and the signal from the VMX-Pi to control the servos directly (which is how I power the VEX motor contorllers as well). When I recieve the Studica Motor controller and jump back to 12v I will use the servo power supply. Thanks again
~Jacob

jrothr...@hdsd.org

unread,
Jul 3, 2020, 11:34:27 PM7/3/20
to vmx-pi
(-‸ლ)
Thank you so much for your help, and I am sorry for taking your time.  It was most certainly a power problem.  I plugged it directly into the pdp, and it worked perfectly with the servos.  

So, at least we now know the PseudoResonance library works perfectly with he VMX-Pi as long as we use the I2C Protocol.  I should note two things.
1) I did raise the clock rate of the Pi to 4000, and
2) You do pass Integers and not bytes to the Pixy to set the servos.

I feel it is not worth it now to investigate SPI since A, we know SPI is working on the VMX-pi, and B the Pixi seems to work fine using I2C.  

Thank you again.  
~Jacob

Scott Libert

unread,
Jul 4, 2020, 12:25:49 AM7/4/20
to vmx-pi
No problem, glad to hear it's working.

I feel it is not worth it now to investigate SPI since A, we know SPI is working on the VMX-pi, and B the Pixi seems to work fine using I2C.  

I went ahead and created a Github Issue on the  pseudorsonance repo, hopefully they'll update SPILink to use a reasonable bitrate (I recommended they use 2000000).

jrothr...@hdsd.org

unread,
Jul 4, 2020, 11:25:24 AM7/4/20
to vmx-pi
Thank you.  I was going to do that, but wanted to figure out if the I2C was going to work first.  The truth of the matter is, unless the difference between the I2C bus current and the High Current DIO power is sufficient, SPI was not going to fix the initial problem either.  Now I know what a brownout looks like from a hardware perspective (without having the driver station feedback, because since it was in the Pixy hardware, I did not see anything in the driver station log). Regardless, as intended, this process is making me a stronger mentor as I am learning much more about the underpinnings of our hardware and software as I explore.  That's is the point right?  Thanks again for helping me along the way.

Scott Libert

unread,
Jul 4, 2020, 6:43:51 PM7/4/20
to vmx-pi
FWIW, I just got a notice that psuedoresonance changed the SPI bitrate to 2000000.  So that should work now, too.

Regardless, as intended, this process is making me a stronger mentor as I am learning much more about the underpinnings of our hardware and software as I explore.  That's is the point right?  Thanks again for helping me along the way.

Agreed!  Happy to help, you're giving VMX-pi a through kire-ticking, and provide really great details and insights that quickly lead us to the answers - and I really appreciate both of those things.

jrothr...@hdsd.org

unread,
Jul 4, 2020, 6:52:55 PM7/4/20
to vmx-pi
That is excellent news.  The VMX-pi is such an incredible device, and you go well above and beyond to help us learn how to use it to reach its potential.

Charlie Peppler

unread,
Jul 23, 2020, 8:50:56 AM7/23/20
to vmx-pi
Scott,

I had the same problem as Jacob with power to the servos.  Thank you for this tip.  I ordered the power module you recommended from RevRobotics.

Scott/Jacob,

I guess my next question is related.  I also have a PixyCam2 that I have wired to the I2C port.  Does the I2C port have sufficient power to drive the PixyCam2, or
does that need a boost as well (which would require some more tricky wiring)?

Charlie

jrothr...@hdsd.org

unread,
Jul 23, 2020, 11:37:51 AM7/23/20
to vmx-pi
i2c needs a boost as well. You can run the Pixy fine, but the servos required more juice.  I think I read somewhere on the Pixy site that the servos need at least 500mA, and the VMX provides at most 500mA so, there is the problem.  I power the pixy directly from my off-brand PDP (the marine one similar to the one in the initial BOM) and the servos are plugged in to the Pixy servo ports. However, currently, I am using two 18650 batteries to power the robot because I am all vex (7-8volts) at the moment. So, I am running 7-8 Volts into the high-current input pin on the Pixy.  You should be able to power the pixy from the Titan's second output too, but I do not know this for certain (I think it is 5volts. In that event, you could use the 5v input pin).   Be careful as the high-current input on the Pixy may not be able to handle 12 volts (I think it is rated from 5-10), so the servo power module would be good if you were using 12 volts. 

If all you want is to power the Pixy and the LEDs (no Servos), the vmx i2c power (or pulling off a high-current IO power pin) works.

I cannot remember if I got SPI working with the Pixy, but i2c works well. If you are interested, here is a link to my practice repo (beware, to call it messy would be an understatement). I have a working Java program that recreates the pan/tilt demo for the vmxPi.  I used their Arduino code and the Pseudoresonance library to recreate it. I copied their PID rather than using WPILib's.

 I have not gotten the robot to follow a target yet, but am making progress. I have the 2020 PID working (drive to a specific distance) and am close to getting the NAVx turn to angle working as well. I will certainly share when I accomplish that. After that, I will put the two together to track a target.

Oh, this is for the Pixy2, not the original Pixy. They are apparently different.  If the camera is housed in white plastic, it is the two. If it is black, it is the original, and in that event, the Pseudoresonance library may not work.

Good luck,
Jacob



jrothr...@hdsd.org

unread,
Jul 24, 2020, 12:15:09 AM7/24/20
to vmx-pi
Somehow, I posted a broken link. This one should work.


~Jacob
Reply all
Reply to author
Forward
0 new messages