Biped robot with PixyCam

[adafruit_support_bill]

That is a nice looking biped. Is that based on the Lynxmotion hardware? And congratulations on adapting the Pixy Pet code for it. Some people like their projects to be 'plug & play', but you have taken it to the next level.

Here's one small simplification for your code: You really don't need the last 'if'. You can simply use 'else'.

Code: Select all

  else
  {
    Walk(10);
  }

[Scott_Callahan]

Thank you Bill. Yes, it is the Lynxmotion BRAT using a Botboarduino. Thank you for the tip on the use of "else" and "if" as well. Using the robot went fairly well last night. The only issue is the pan servo doesn't continuously center the object anymore while the robot is moving. The pan servo stays still while the robot moves until the object is out of the field of view then it scans again. The robot will move either left, right or straight respectively and continue those movements until the object is out of the field of view, then it scans and restarts the process. More fun tweaking on it later tonight.

[adafruit_support_bill]

The only issue is the pan servo doesn't continuously center the object anymore while the robot is moving. The pan servo stays still while the robot moves until the object is out of the field of view then it scans again.

That is because your 'turnLeft" and "turnRight" calls are 'blocking' calls, so the tracking and following code does not get called until they complete.

The solution to that will involve some re-structuring of the code. I have a series of tutorials on the subject. The first one shows how to perform servo movements concurrently with other tasks:

https://learn.adafruit.com/multi-taskin ... 1/overview
https://learn.adafruit.com/multi-taskin ... 2/overview
https://learn.adafruit.com/multi-taskin ... 3/overview

[Scott_Callahan]

Oh perfect! I will go over those tonight. I even wondered why when I had the IR sensor the pan servo wouldn't pan when the robot was walking. Thanks again.

[Scott_Callahan]

After reading the tutorials I understand why multiple tasks can't be performed at once. However, I don't know how to apply them since as far as I know I'm not using a delay during the movement of the robot. However, I did come up with an idea.

The robots movements are all group moves. I don't need and maybe don't even want the pan servo to update continuously throughout the group move since the top of the robot shifts around a lot during it's steps and if it's in-between either walking straight or turning it may get confused. What I'm working on now is having the camera to move to center of the object after each group move, then the robot makes the next appropriate movement. I'll post updates as I work on it.

[adafruit_support_bill]

It's hard to say without seeing the rest of your code. But if you have mastered group moves of servos, you are probably halfway there already.

[Scott_Callahan]

So pumped! All it took was the adjusting of the pan servo speed. I noticed the pan servo was moving in-between steps, it just wasn't fast enough to center the camera before the next step. I adjusted the numbers in the servo loop and that sped the pan servo up so it centers after each group move. I don't know what the 2 numbers correlate to? But it works.

Code: Select all

ServoLoop panLoop(700, 700);  // Servo loop for pan

It originally was (200, 200).

Now I can start to fine tune the code again. Thanks!

[adafruit_support_bill]

I don't know what the 2 numbers correlate to? But it works.

The first number is the proportional gain. That controls how much the error value is amplified in calculating the servo output. Higher numbers mean faster correction of the error, but may result in overshoot.

The second number is the derivative gain. That controls how much the derivative (change in the error value) is amplified in calculating the servo output. Higher numbers tend to inhibit the speed of movement near the setpoint and reduces the overshoot.

[Scott_Callahan]

Perfect. Thank you again for all your help.
I've got a few more adjustments to make on the code (make the pan servo pan all the way from max to min or min to max before the robot moves in the scan loop). Then I'll put back on the analog IR sensor which I imagine will open up another can of worms. I'm guessing I'll need to use interrupts for that? This has been a fun project though. I've learned a lot.

[adafruit_support_bill]

Not sure if interrupts would be make sense for the IR rangefinder. Control loops tend to be synchronous:
- Read the inputs.
- Calculate the Error,
- Compute the outputs.

If the IR distance will be an input to the control loop, you can poll it when you poll the camera.

Interrupts are best reserved for handling asynchronous events that require immediate action.

[Scott_Callahan]

In that case implementing the IR sensor again may be easier than I expected. I'll post updates as I work on it.

[Scott_Callahan]

My real job has been very busy so I haven't had much time to work on the robot but I did put the IR sensor back on. I tried playing around with implementing the IR sensor back into the code with no luck. I took the robot to my job so I could work on it at night during down time. But the servos acted very erratic, like the robot was having a seizure. It would still move, but very jerky. I thought maybe with the addition of the IR sensor and Pixy cam the 6 volt battery (which was charged) is getting tapped during it's movements. I ordered a 7.2 volt battery to try next week. Today I came home for a few hours and the robots movements are smooth and flawless again. I did a brief google search of Arduino and stray RF interference with no luck. I work at a large fire station and in the station we have commercial refrigerators, coffee pot, etc. and a 100 watt radio. My only guesses is either it's stray RF interference or maybe all the stainless steel is causing some kind of chaos to it, or the battery is right on the cusp of being overdrawn. Either way here is a picture of it with the IR sensor. Oh I also posted a short video of it on Twitter to Adafruit and Charmed Labs!

IMG_4812.jpg (652.26 KiB) Viewed 596 times

[Scott_Callahan]

One more update tonight. Something at my fire station is definitely causing the issue, not the battery. I've let the robot roam around for an hour with no issues at my house. So that rules out the battery. The odd thing is the robot worked great at the fire station before I added the Pixy cam and even worked fine after. It was only recently it acted messed up. In fact here is a link to my Twitter post with a short video that was taken when I got the camera to work. https://mobile.twitter.com/scally1998/s ... 8606931968

[adafruit_support_bill]

Thats a great looking robot! Thanks for the photos & video!

I suspect that the problem you are seeing at the fire station may be the lights. I've noticed that the color recognition has difficulty under some types of florescent lights. I'm not sure if it is due to the discontinuous spectrum of the phosphors, or the 60 Hz flicker. But even with re-calibration, the camera had difficulty locking on target. You can see this real-time if you view the camera output via PixyMon.

[Scott_Callahan]

Thank you again for the compliments.

When I first brought the robots to work I had to re calibrate the cameras, then go back home and find a happy medium where they work at both places. At work it is much harder to get a good signature on PixyMon than it is at home. Another thing I remembered but didn't put together until I was thinking about this is the Pixy Pet has acted weird too. Sometimes it will have a fit and go into the scan loop, but much faster and more erratic movements than normal. It moves very fast in circles and the pan tilt servos mover very fast as well. But that doesn't happen often. I'm at a newer fire station tonight. All the same electronic equipment is here but different lighting. I'll try using them both here to rule some culprits out. If they do act weird I'll film it and post it again.

Thanks!