Using one gyro sensor as two viritual gyros in code

[lollypop2020]

For our code, we need to have the equavalent of two gyros. One of them is used by the driver and by the aiming software and is reset quite frequently. The other one is for the robot's true heading (with error of course), and should not ever be reset. I tried opening two gyro references using the same AI channel, and using each reference respectively where it was needed but I got errors on the DS for trying to use an already allocated AI channel. Is there a way to get around this without keeping track of the angle of the gyro manually? I know I could probably write my own code to have two independant counters that could be used seperately, but I would rather not have to do that, however I will if it's the only option. Could I use a PWM splitter cable and plug one gyro into two AI ports? Or is there anything else I could do?

[Bongle]

You could make a class of your own that holds a pointer to your original gyro class. It could have a reset function that takes note of the current absolute heading, and a getangle function which returns your difference since the last time you reset.

class RelativeGyro
{
public:
  RelativeGyro(Gyro* pAbsoluteGyro) : m_pGyro(pAbsoluteGyro), m_dBaseAngle(0.0)
  {
  }

  void Reset()
  {
    m_dBaseAngle = m_pGyro->GetAngle();
  }
  double GetAngle()
  {
    return m_pGyro->GetAngle() - m_dBaseAngle;
  }
private:
  double m_dBaseAngle;
  Gyro* m_pGyro;
}

An advantage of this design is that you could actually create multiple RelativeGyro classes within your robot, if that is what you want. You could have one for shooting, one for target-finding, etc.

If you're not using C++, you'll have to adapt my idea to LabView or Java if you like it.

[DavidGitz]

That's a good idea about using a PWM Y Cable. That would be by far the easiest option I think.

[Russ Beavis]

There's no reason why your program can't store the data that you need in separate variables. Aren't there "user data" parameters that can be sent to the Driver Station in addition to the "direct" low-level analog and digital input readings? You should not need to resort to a hardware solution for what is essentially storing a single analog reading in 2 memory locations.

Russ

[DavidGitz]

Originally Posted by Russ Beavis

There's no reason why your program can't store the data that you need in separate variables. Aren't there "user data" parameters that can be sent to the Driver Station in addition to the "direct" low-level analog and digital input readings? You should not need to resort to a hardware solution for what is essentially storing a single analog reading in 2 memory locations.

Russ

I agree with this statement, generally. However, due to the time limitations through the FRC competition and (probably) lack of a testing environment right now, and not much time available at the regionals, and coupled with the errors they've already recieved, unless a very simple programming approach could be used (i.e. open up 2 references to the same device) I would go through the hardware branch. I'm sure the right way of doing this would be fairly easy, but with lack of a testing environment I would rather have *definitely* be right the first time than have to debug code. Like most things, it is a tradeoff. It wouldn't be the best solution, but might be the most reliable.

[AmoryG]

Originally Posted by DavidGitz

I agree with this statement, generally. However, due to the time limitations through the FRC competition and (probably) lack of a testing environment right now, and not much time available at the regionals, and coupled with the errors they've already recieved, unless a very simple programming approach could be used (i.e. open up 2 references to the same device) I would go through the hardware branch. I'm sure the right way of doing this would be fairly easy, but with lack of a testing environment I would rather have *definitely* be right the first time than have to debug code. Like most things, it is a tradeoff. It wouldn't be the best solution, but might be the most reliable.

Originally Posted by Bongle

You could make a class of your own that holds a pointer to your original gyro class. It could have a reset function that takes note of the current absolute heading, and a getangle function which returns your difference since the last time you reset.

class RelativeGyro
{
public:
  RelativeGyro(Gyro* pAbsoluteGyro) : m_pGyro(pAbsoluteGyro), m_dBaseAngle(0.0)
  {
  }

  void Reset()
  {
    m_dBaseAngle = m_pGyro->GetAngle();
  }
  double GetAngle()
  {
    return m_pGyro->GetAngle() - m_dBaseAngle;
  }
private:
  double m_dBaseAngle;
  Gyro* m_pGyro;
}

An advantage of this design is that you could actually create multiple RelativeGyro classes within your robot, if that is what you want. You could have one for shooting, one for target-finding, etc.

If you're not using C++, you'll have to adapt my idea to LabView or Java if you like it.

The above code really is as simple as it gets (that is, if you understand what the code does). If you were to use something like this, all you would need to do is create a RelativeGyro and feed its constructor a pointer or reference to a gyro object:

Gyro gyro(1);

RelativeGyro relativegyro(&gyro);

Then use Reset and GetAngle as you would with any gyro.

[lollypop2020]

Thanks for all the help! I think I'll probably go with the hardware approach and try to make a PWM splitter before our first match tomorrow. If it doesn't work for some reason, that code doesn't look too bad. I must agree with DavidGitz though, time for debugging is something we do not have, and at the moment, this just seems easier.

[virtuald]

Originally Posted by lollypop2020

Thanks for all the help! I think I'll probably go with the hardware approach and try to make a PWM splitter before our first match tomorrow. If it doesn't work for some reason, that code doesn't look too bad. I must agree with DavidGitz though, time for debugging is something we do not have, and at the moment, this just seems easier.

I wouldn't recommend doing it the hardware way. One thing to keep in mind is that the gyro requires the use of an accumulator channel, so you have to use channels that support that (I think the first two channels support it, on the first analog module only). Additionally, you might get some odd effects by connecting two channels together that way. If they accumulate different values, then each of your gyros is going to be offset from the other, and that could cause issues as well.

The software is trivial, do it that way. The code by Bongle looks like it should work as is without any debugging.

[EricVanWyk]

Originally Posted by virtuald

...

I wish to join the dead horse beaters in this thread. The Y-cable is the cheap fix that will almost definitely bite you later. Spend the extra 10 minutes and do it right.

[ideasrule]

Originally Posted by EricVanWyk

I wish to join the dead horse beaters in this thread. The Y-cable is the cheap fix that will almost definitely bite you later. Spend the extra 10 minutes and do it right.

That horse never listened to me, so I'll join the club. This code is so simple that it shouldn't require any testing to get right. The people who made the gyro weren't expecting the analog module to draw twice as much current as necessary from the gyro, so if you use the Y-cable approach, you'd be going against what the engineers designed the gyro for. Not a good idea!