Library Error --> " 'TwoServoAdapter' does not name a type ".

Hi Everyone,

I’ve been getting the error as stated in the title and have tried everything like moving the .h files to the sub directory (after which I did so, it kept asking for different .h files).

Anayways, I’ve attached an image of what my error looks like, as well as my code below. I am using the “BackSeatDriver: Autonomous Vehicle Library for Arduino” (deets here https://github.com/kigster/BackSeatDriver ).

I dont how to display images right here so you can see the attachment at the bottom of this post named “ARDY SERVO Lib Problem”.

Code starts here:

#include <BackSeatDriver.h>

TwoServoAdapter adapter = TwoServoAdapter(11, 3);
BackSeatDriver robot = BackSeatDriver(&adapter);
 
int irvalue = 0;

void setup() {
 robot.attach();
 Serial.begin(9600);
}

void stoppage(){
  robot.stop();
}

void loop() {
  
  irvalue = analogRead(A0);
  Serial.print("irvalue: ");
  Serial.print(irvalue);
  Serial.println();
  
  if (irvalue > 900) {
    robot.goForward(100);
  }
  
  if (irvalue < 900) {
    robot.stop();
    delay(1000);
    robot.turn(90, &stoppage);
    delay(500);
  }
     
}

I would IMMENSELY appreciate any help, as this has been holding back my project for quite some time now.

Thank You! :slight_smile:

It means that the compiler can’t find the include file or the library.

You can download a zip file of the library and install the zip file from the menu of the Arduino IDE.

The imported library files should be in the “libraries” folder. That folder is in same folder as your projects. You can see that folder in the settings in the Arduino IDE.

Can you verify that you have a folder “libraries” next to your projects folders and that the library is in the “libraries” folder ?

When you include an imported library, use : #include <BackSeatDriver.h>
When you add those files of the library to your local project files, use : #include “BackSeatDriver.h”
You can add files to your project with the drop-down menu on the right.

Did you notice that the library was updated a few hours ago ? That library is only a day old, perhaps there are some bugs in it.

Ha! I am glad you are using the library! I am too! I am driving a

And yes – it’s totally under constant development/hacking and can at times be unstable. For that I am sorry :slight_smile: BUT! I am happy to help and figure this out.

The Adapter classes are not automatically loaded by “BackSeatDriver.h” – you need to load them individually. I just updated the docs to reflect that.

Add this at the top:

#include <BackSeatDriver_TwoServoAdapter.h>

For further questions please feel free to email me at kigster AT gmail.com or log issue on github.

Thanks for using it!

Just to follow up – I’ve been trying to figure out how to have a single library support multiple adapters, without needing to depend on external libraries from adapters not in use.

Unfortunately that’s not easy/possible without setting global compile/linking flags (which is possible in Eclipse, but I am not even sure how to do it in Arduino IDE – may not be possible at all). The idea is that if you are not using DCMotorAdapter, you should not be compiling/linking it, and definitely not depending on it’s dependency – Adafruit Motor Shield Library.

The only way this ended up working is when I split off the adapters into their own libraries. So now you have to always add at least two libraries:

#include <BackSeatDriver_TwoServoAdapter.h>
#include <BackSeatDriver.h>

Then you can initialize them as follows:

// initialize the adapter with two pins assigned to the two servos
BackSeatDriver_TwoServoAdapter adapter(13, 12);

// intialize BackSeatDriver itself, passing it the driver.
BackSeatDriver robot(&adapter);

// now we can ask our robot to move...
robot.goForward(100); // move forward at 100% speed

Thanks for pointing out the issue, and hope it works for you. I am continually making improvements and adding sensors and features :slight_smile: It should be a fun project :stuck_out_tongue_winking_eye:

Hi Guys,

Thank you so much for the help and the rectification, especially kigster :D. Here is my code now, which verifies perfectly:

#include <BackSeatDriver_TwoServoAdapter.h>
#include <BackSeatDriver.h>
#include <Servo.h>


BackSeatDriver_TwoServoAdapter adapter(11,3);

BackSeatDriver robot(&adapter);
 
int irvalue = 0;

void setup() {
 robot.attach();
 Serial.begin(9600);
}

void stoppage(){
  robot.stop();
}

void loop() {
  
  irvalue = analogRead(A0);
  Serial.print("irvalue: ");
  Serial.print(irvalue);
  Serial.println();
  
  if (irvalue > 900) {
    robot.goForward(100);
  }
  
  if (irvalue < 900) {
    robot.stop();
    delay(1000);
    robot.turn(90, &stoppage);
    delay(500);
  }
     
}

What I noticed however is that if I didnt include the standard servo library (#include <servo.h> shown right at the top), then I would get this error:

Arduino: nightly (Mac OS X), Board: “Arduino Uno”

In file included from Auto_IR_ROBOT_NAV_2.ino:1:0:
/Users/*****/Documents/Arduino/libraries/BackSeatDriver_TwoServoAdapter/BackSeatDriver_TwoServoAdapter.h:35:19: fatal error: Servo.h: No such file or directory
#include <Servo.h>
^
compilation terminated.

So all I did to fix that was include the standard servo library and voila. Perfect. Thanks kigster!

Yep, exactly!

The comment at the top of the example included in the library lists all the dependencies, but maybe I should add it to readme.

Keep in mind this library is under active development, so feel free to suggest things, and also don't be alarmed if things break :)

Hey guys, new discovery:

When I attach both my servos to a single power source, the first command my UNO gives it works well, but when tasked with another command after a delay or whatever, the servos go haywire and just keep spinning in the same direction they were in, sometimes even moving the servo that isnt even connected to the UNO!

FIX: I plugged one servo to the auxillary power source and one to the UNO's, and they worked fine. Im assuming that if you want to power both servos from one power source, your going to have to implement soem sort of hard wall that splits the current after which they can interefer --> DIODE?.

Azobe:
Hey guys, new discovery:

When I attach both my servos to a single power source, the first command my UNO gives it works well, but when tasked with another command after a delay or whatever, the servos go haywire and just keep spinning in the same direction they were in, sometimes even moving the servo that isnt even connected to the UNO!

FIX: I plugged one servo to the auxillary power source and one to the UNO’s, and they worked fine. Im assuming that if you want to power both servos from one power source, your going to have to implement soem sort of hard wall that splits the current after which they can interefer → DIODE?.

The behaviour that you describe is bizarre. The only reason why a servo should move is if its signal wire receives a signal that is interpreted by the servo as a command. Beyond needing a common GND, correct voltage and sufficient current it does not matter how they are powered. Instead of “fixing” the problem in the way that you suggest you should track down and fix the real problem. Firstly, what type of servos are you using and are they actually servos or bastardised versions modified to run continuously ?

You mention using the UNO’s power source for one of the servos. Do you mean an external power source or the 5V and GND pins on the UNO ?

I am using two servos - SpringRC S3317SR that were manufactured to be continuously run, I don't think they would be modified. I totally agree something is not right, but by powering one servo with a pair of 1.5V AA batteries connected to a voltage regulator, and the other servo straight from the GND and 5V from the Arduino, it seems to fix the problem. Could you suggest any possible issues?

Could you suggest any possible issues?

Yes, the current drawn by the servo may exceed the rating of the voltage regulator on the Arduino. This could potentially damage the regulator and/or cause brownouts of the supply to the Arduino as the servo draws current. This is particularly the case when the sevo first starts running as it will draw its stall current which is somewhere between 415 and 700 mA according to the servo data sheet. This is way over what the Arduino regulator is rated to provide.

Powering a servo with 3V is also not a good idea, particularly as the servo is rated to run on 4.8V. The batteries will not even maintain 3V for very long which will make things even worse. What is the actual voltage supplied by the voltage regulator ?

The voltage regulator that I had initially set up to power both servos from the AA batteries was variable, set at 5V. Now when I hooked up both these servos power supply to Only the AA batteries, they weren't behaving properly at all. It's like the control of the servos got screwed up when they had to share a singular power source (I'm guessing something to do with the parallel nature of the servos and their AA batts having to split current in half). That's why setting up two separate power sources for each servo allowed everything to work smoothly, and since I had not other battery holder, to test the hypothesis, I hooked up a servo to the Arduino (hypothesis then proved). Now my issue is why on earth do these servos not behave at all like the way they should when they're sharing a power source? (I've adding tried capacitors in parallel to each servo -- didn't work -- would putting the capacitors in series help?)

Again, help would be Immensely appreciated.

What sort of voltage regulator are you using to get 5V from 2 AA batteries at up to 1400 mA ?

Oh, you need 1400mA? I'm using this variable regulator http://www.pololu.com/product/2118

Oh, you need 1400mA?

The stall current of each servo is up to 700 mA according to the data in the link to them that you gave. It would be simpler to user 4 AA batteries and remove the voltage regulator.

I will surely try that, but is it definitely the lack of current that is making the servos not listen to commands from the signal wire properly though?

Yes. Both the servos and the arduino will be grossly underpowered from 2 AA batteries.

The arduino is being powered by a seperate square 9V battery. The two AA batteries are just for the servos, also, I have no idea what the current output is of my AA batteries as it isn't written anywhere. (Forgive me I am bad with batteries)

Just for the record, the robot I was running when I wrote the library is the Parallax for Arduino bot:

http://www.makershed.com/products/arduino-shield-robot-kit

This includes Board of Education shield that receives power from 5 x AA batteries and powers both Arduino and the motors. I've never had any issues with the power on these, and recommend that you control the two servos via some kind of shield (like Adafruit Motor Shield) that's designed to receive more power.

On my DC Motor bot (with Adafruit Motor Shield) I was able to run off 9 x AA batteries, as well as 5 x AA batteries. It runs a lot faster with 9, but I also burned a wire while the motors were stalled (whoops!) so I went down to 5 batteries after that ;)

When motors receive inconsistent power my bots go totally haywire: they seem to cycle through some strange semi-arbitrary loop of movements. Whenever I see this, I now know the batteries need to be replaced ;)

Here please read this page:

https://learn.adafruit.com/adafruit-motor-shield/power-requirements

It's got very detailed requirement on power, and really spells out configurations that are grossly underpowered.

Azobe: The arduino is being powered by a seperate square 9V battery. The two AA batteries are just for the servos, also, I have no idea what the current output is of my AA batteries as it isn't written anywhere. (Forgive me I am bad with batteries)

If the 9V battery is what I know as a PP3 then don't expect it to last long before the voltage drops too low. If you compound this by powering one of the servos from the Arduino 5V pin then expect it to last only a matter of minutes.

Please consider powering the whole thing from 4 AA batteries with the servos powered directly from them and not via the Arduino.