PDA

View Full Version : Semi-Scratch Built HROS1 Inspiratron (baymax vs .001)

darkback2
09-02-2015, 03:22 PM
When I saw the HROS-5 and heard rumors about a smaller more affordable AX-12 based version I instantly knew I wanted one.

The reality is, I wanted a Darwin-OP, but that was out of the question. The thing that I loved most about the Darwin-op was how it didn't take itself too seriously. The Darwin is a pretty impressive and capable robot, but it is also cute as hell.

I run a FIRST Robotics team and robotics class at the high school where I work. One of the teams goals, and the focus of this year is inspiring others. We wanted to build a cute, fairly accessible robot that we could use at public functions in order to inspire others in engineering and robotics. It is also a dream of mine to at some point in the future field an autonomous humanoid robot soccer team. I don't have it in my school budget to afford one $12k robot let alone three, though perhaps I can swing$1600 :-)

We decided to start by converting a bioloid comprehensive into an HROS-1, we also plan to purchase an HROS-1 kit in the future.

I called over to Trossen to find out what the bottle necks would be in trying to do this. I was informed that in the future they plan to sell the arbotix pro as a stand alone, but they won't have any extra for a while. Converting a bioloid would require either an arbotix pro or a CM-730 from a Darwin-OP electronics kit. Oddly I just happened to have one of those. So off we went.

We wanted to style the robot after the robot from Big Hero 6. We felt that it would be recognizable to a wide range of younger individuals and also seen as not threatening or scary. while we originally thought of designing the head along those lines we ended up going in a different direction with the head to account for the camera. We need to mount and wire a small fan to inflate the body and will probably have to sew in elastic to trap the air in order to get it to properly inflate.

6142

6143

The students assembled the robot and ID'd all of the servos. They started sewing the body together but ran out of time at the end of the school year. I finished that and printed a few different heads to try out over the break.

I really want to see these guys run the Darwin-OP soccer ball chasing program in the near future. I think that would be a great way to demo robotics in an appealing way to young people. We also want to program it to tell jokes and play games.

We ran into a few issues during this build. First off you need the Raspberry pi 2 model B for the software to work. Trying to run it on a regular raspberry pi 2 makes the whole operation incredibly unstable.

Second, the CM-730 software is slightly different than that of the arbotix pro. I had to get help installing some changes run on the HROS-5 in order to get that to work.

Finally, the arbotix pro has a 5 volt power out to run the Raspberry Pi. The CM-730 does not. We tried using a voltage regulator, but you really need to use a Higher amperage BEC or else the Raspberry Pi will brown out and crash.

There were a few other issues, such as not having the same hole spacings on our brackets as on the real thing. All in all though the process was pretty painless.

That said, I am not sure it is worth it or feasible for anyone else to do this and still meet the price point set by Trossen, even if you already own a bioloid.

The weight difference between the metal and plastic brackets adds up, and the metal brackets are relatively expensive. Having them cut out by a place like big blue saw is even more expensive, and then you have to bend them yourself or pay to have them done.

At the school we are set up to do laser cutting and 3D printing. It isn't that easy to do those things at home.

Finally the CM-730 or Arbotix Pro are going to be hell to come by. Once the Arbotix pro is for sale my opinion on that may change.

In any case, major thanks to the good people over at Trossen and Andrew for all of their help making this project a reality.

DB

tician
09-02-2015, 04:14 PM
Converting a bioloid would require either an arbotix pro or a CM-730 from a Darwin-OP electronics kit. Oddly I just happened to have one of those. So off we went.
Glad it finally found a use.

I really want to see these guys run the Darwin-OP soccer ball chasing program in the near future. I think that would be a great way to demo robotics in an appealing way to young people. We also want to program it to tell jokes and play games.
Need to add a tether for external power during long displays of the soccer demo, and keep a fan or CO2 duster handy for when the knees start overheating. Usually fun when it starts chasing kids' shoes/socks around a room because it only tracks by color.

We ran into a few issues during this build. First off you need the Raspberry pi 2 model B for the software to work. Trying to run it on a regular raspberry pi 2 makes the whole operation incredibly unstable.
I thought there was only one model of RPi2 (the RPi2 Model B) and five versions of the RPi1: Model A, Model B, Model A+, Model B+, and the compute module. IIRC, the RPi-B+ and RPi2-B have the exact same footprint, and they share the mounting holes and basic connector locations with the RPi-A+.

Finally, the arbotix pro has a 5 volt power out to run the Raspberry Pi. The CM-730 does not. We tried using a voltage regulator, but you really need to use a Higher amperage BEC or else the Raspberry Pi will brown out and crash. The CM-730 has a 5V buck converter on board for DXL comms and feeding the 3.3V linear regulator for the STM32, but I'm thinking it can only put out about 500mA. The Arbotix-Pro uses the horizontal mounting Murata OKI-78SR (http://www.digikey.com/product-detail/en/OKI-78SR-5%2F1.5-W36H-C/811-2692-ND/3438675) in both 5V and 3.3V versions for 1.5A each at rather high efficiency. If you want overkill, you could go for the OKR-T/10-W12-C (http://www.digikey.com/product-detail/en/OKR-T%2F10-W12-C/811-2180-ND/2199630) for up to 10A at 5V (through hole package with variable output voltage via resistor) from a ~12V input, or a Vicor PI3424 (http://www.digikey.com/product-detail/en/PI3424-00-LGIZ/1102-1641-ND/3913076) for up to 15A at 5V (fixed output voltage, but uses tiny 123-BLGA SMD package; Zero-Voltage Switching is so wonderful when well implemented) from an input up to 18V.

Finally the CM-730 or Arbotix Pro are going to be hell to come by. Once the Arbotix pro is for sale my opinion on that may change.
Supposedly they should be shipping the next batch of beta HROS-1 + Arbotix-Pro very soon, unless there was another big delay in manufacturing and/or testing of the newest Arbotix-Pro revision.

r3n33
09-03-2015, 06:30 PM
This is so cool. Does it have a name?

I like the look of the nylon suit and the head model :) Really looking forward to seeing it when you get some air trapped inside!

KurtEck
09-04-2015, 10:43 AM
Cool project - Will be fun to see what you and the kids are able to do here!

Kurt

darkback2
09-05-2015, 12:28 PM
So...Small hang up. I went with 1.4 watt fans. One wan't enough to inflate the suit, so I tried two.

First test went great. I was able to keep the robot walking around for an entire battery. Then the robot started hanging up. It would take a few steps and then freeze.

I am unsure as to the exact source of the problem, and having the entire robot covered in nylon isn't helping.

I have the two fans drawing power from one of the unused dynamixel servo ports.

So theorys are...
1) drawing too much current through the port causing either some heat issues on the board
2) drawing too much current causing a brown out of the board
3) I have already damaged something.

Running the robot without the fans seemed to work and stop the hang-ups. :-(

DB

darkback2
09-05-2015, 12:47 PM
So...While lock-ups seem to happen more when the fans are running, I have gotten a lock up without the fans plugged in at all. Also, a draw of even 3 watts is nothing when compared with the draw of a stalled servo, so the ports should be fine handling the fans.

So now I have to go over all of the wires to make sure nothing is pinched or anything. I am also wondering if the problem is related to the amount of time the robot is walking.

DB

tician
09-05-2015, 02:17 PM
What exactly occurs during the hangups? Does the program on the RPi stall/crash? Does the PS3 controller disconnect? Do the servos just stop responding until a CM-730 reset then restarting the demo program on the RPi? Does the CM-730's FT233RL port suddenly disappear from the RPi's USB devices?

We had repeated issues with the CM-730 + fit-pc2i-sbc refusing to successfully enumerate the FT232RL in one of the DARwIn-OP. It was almost certainly the fit-pc2i-sbc USB port/hardware as the issue occurred with multiple CM-730 (different revisions) on the same bot. Replacing the cables twice failed to resolve it, but it was an intermittent problem where it would connect fine many times then fail then maybe start working again on the next reboot. The CM-730 you have was never actually inside any of the DARwIn-OP and was only briefly used for testing servos with experimental code on my netbook or a lab pc, so I don't think it ever experienced the fail-to-enumerate error.

darkback2
09-05-2015, 02:32 PM
So to describe the "hang-ups" and a couple of other issues.

I am running the Raspberry Pi2.

I have it set up so that on bootup it runs the PS3 controller software. I have to be at work in order to connect to the raspberry pi remotely so I can't see what else might be going on.

The robot will be walking and will just suddenly stop walking mid stride. Sometimes it comes back a few moments later and starts walking again, and other times it just stops (freezes) and doesn't move again until I power down and reboot. When it stops the servos have torque and hold their position.

With the suit on I can't even see if there are any blinking lights suggesting the raspberry pi is still sending information.

Thanks for the help

DB

tician
09-05-2015, 04:19 PM
There are several possible causes that come to mind, but not sure which applies without more information.

Are you using the crappy USB to 4-pin molex/dynamixel cable that I cobbled together, or the nicer USB to molex PCB from trossen with a stock 4-pin dynamixel cable? The crappy cable will probably not survive very much movement before the wires break at the molex connector because of crap wire, over-crimped pins, and no strain-relief.
A bad USB cable could cause the FT232RL to disconnect and re-enumerate as a differently numbered '/dev/ttyUSBn' device if the demo program is still trying to access the original port/device (name/number cannot be reclaimed until released by demo program and then the FT232RL disconnected and reconnected). A bad cable might possibly be able to disconnect the FT232RL for a sufficiently short period of time that it briefly stops responding long enough to cause a short timeout error in the demo program without requiring it to re-enumerate and get a new '/dev/ttyUSBn' number/name.

Not sure how the demo program is supposed to react to a lost connection to the PS3 controller, but maintaining the pose from 'last valid controller input' would probably be the safest. The fact that the servos do not lose power means it is unlikely to be a brown-out issue involving the CM-730, but whatever 5V regulator you are using for the RPi2 might be more sensitive to input voltage fluctuations and/or produces a generally unstable output voltage under variable loading.

r3n33
09-05-2015, 10:15 PM
So...While lock-ups seem to happen more when the fans are running, I have gotten a lock up without the fans plugged in at all. Also, a draw of even 3 watts is nothing when compared with the draw of a stalled servo, so the ports should be fine handling the fans.

I agree. On my hexapod I have 6x 1watt fans running off the 12V supplied on the dynamixel bus.

The robot will be walking and will just suddenly stop walking mid stride. Sometimes it comes back a few moments later and starts walking again, and other times it just stops (freezes) and doesn't move again until I power down and reboot. When it stops the servos have torque and hold their position.

From this description it does not sound like the pi is rebooting because you do not have to reconnect the PS3 controller to continue use.

Oh there is a bug with PS3 demo where it uses 100% cpu due to a while loop with no delay in processing. Just before line 206 in ps3_demo/main.cpp add

usleep( 10000 );

Hopefully that helps. The other thing I'm thinking it sounds like is a lack of comms between the RPi2 and the CM730.

darkback2
09-06-2015, 01:26 AM
Wow! Thanks man. I'll try that first thing tomorrow!

KurtEck
09-06-2015, 09:04 AM
Oh there is a bug with PS3 demo where it uses 100% cpu due to a while loop with no delay in processing. Just before line 206 in ps3_demo/main.cpp add

usleep( 10000 );

Hopefully that helps. The other thing I'm thinking it sounds like is a lack of comms between the RPi2 and the CM730.
Yah - I forgot about that one. Earlier when I rewrote the PS3 code base as to not require running as the root, I put the delay into the check controller code instead of in main, but same difference.

If you want to take it look, it is up in my Use-my-joystick-controller branch of my fork... My code also works like the ROS joystick code that if it loses the joystick object it will try to reopen it. Likewise it does not require the object to be created before the program runs... I also like I can simply rerun the test program and not have to kill and restart the controller code. Warning - I have not yet tested it on the Edison.

darkback2
09-06-2015, 01:09 PM
so I want to edit the CPP file but I'm not really sure what I am doing... so what I tried was from the command line going into the project folder and typing edit main.cpp. so then a whole bunch of code comes up and that is about where I am lost. Really I need a code editing program or to copy the files off of the robot to edit them on my pc. I could do that in about 10 seconds using the code editing software I use on my computer, but in Linux I am completely lost. Think of me as the end user from hell. :-)

KurtEck
09-06-2015, 01:29 PM
A couple of options here:
1) Setup to use Putty (or now I am using Kitty) and WinSCP. You can connect up to your RPI with WinSCP, double click on the file which will upload it to your pc into a text editor (you can setup which one), where you can make the changes and when you do a save, winscp will download it back to the RPI2...

2) Use a text editor on the RPi2. I often use the old vi program (or vim), but this is not the most obvious editor to figure out how to use. But can be done by: entering commands like:

:206
which will move you to line 206.
You can then use the arrow keys to move around. To insert or append text hit either the i or the a key. You can then still move around using arrow keys and also type in new text, delete old text...
Once you are done entering the text, hit the Esc key which gets you out of text insert mode.
Then to save the stuff back out enter

:w
To exit, type:

:x
...

There is also another editor often built in, which is a little easier to use called nano
Don't know if it comes pre installed or not, but if not can install using: sudo apt-get install nano

There are other graphic editors as well, for example I have used geany before likewise gedit.

Kurt

darkback2
09-06-2015, 02:02 PM
Ok...so now I am using winSCP. I can navigate to the file, open it, and edit it...but when I try to save it I get an error code 3 insufficient permissions... I can't see a way to sudo save the file, and I don't want to screw anything up.

KurtEck
09-06-2015, 05:02 PM
It may depend on which user id you are using to login to the PI and if you enter a password... When I winscp to an RPI, I will log in with userid pi and the password (raspberry), I will often login with the check box that says something like keep me loged in, or the like. Otherwise when you do a save, it will then put up another prompt that asks for password.

But this depends on things like who is the owner of the files... For example on my Pi, if you do an ls -l you will see:

[email protected] ~/HROS1-Framework/Linux/project/ps3_demo $ls -l total 940 drwxr-xr-x 2 pi pi 4096 May 20 06:19 action_scripts -rwxr-xr-x 1 pi pi 734565 Apr 28 11:14 demo -rw-r--r-- 1 pi pi 9194 Apr 21 09:53 main.cpp -rw-r--r-- 1 pi pi 78128 Apr 28 11:14 main.o -rw-r--r-- 1 pi pi 921 Apr 21 09:53 Makefile -rwxr-xr-x 1 pi pi 439 Apr 25 08:22 rc.local drwxr-xr-x 2 pi pi 4096 Aug 6 19:49 sixpair -rwxr-xr-x 1 pi pi 87 May 20 06:19 start_edison -rwxr-xr-x 1 pi pi 107 May 20 06:19 start_rpi -rw-r--r-- 1 pi pi 17654 May 20 06:19 StatusCheck.cpp -rw-r--r-- 1 pi pi 1607 May 20 06:19 StatusCheck.h -rw-r--r-- 1 pi pi 79560 Apr 28 11:14 StatusCheck.o So I know that the user pi is the owner of the files. If this is not the case on your robot and you are logging in as user pi, you might try changing the file owner using a putty window. something like: sudo chown pi:pi * I am assuming that the error is on that side and not that your text editor does not have the ability to save the actual files on the PC. By default it saves the files somewhere in your temp directories, example I just ran the editor on my PC to my RPI2 in the HROS1 and the file is saved in: C:\Users\Kurt\AppData\Local\Temp\scp00900\home\pi\ HROS1-Framework-Kurte\Linux\project\ps3_demo There are many people up here who are much better at Linux than I am, so if I missed something obvious, hopefully others can give better suggestions. Kurt darkback2 09-06-2015, 05:27 PM Not sure if this is the problem and definitely not sure what to do about it. :-( [email protected] ~/HROS1-Framework/Linux/project/ps3_demo$ ls -l
total 880
drwxr-xr-x 2 root root 4096 Aug 6 12:57 action_scripts
-rwxr-xr-x 1 root root 682224 Aug 6 17:29 demo
-rw-r--r-- 1 root root 9194 Aug 6 12:57 main.cpp
-rw-r--r-- 1 root root 78220 Aug 6 17:26 main.o
-rw-r--r-- 1 root root 921 Aug 6 12:57 Makefile
-rwxr-xr-x 1 root root 439 Aug 6 12:57 rc.local
drwxr-xr-x 2 root root 4096 Aug 6 12:57 sixpair
-rwxr-xr-x 1 root root 87 Aug 6 12:57 start_edison
-rwxr-xr-x 1 root root 107 Aug 13 18:15 start_rpi
-rw-r--r-- 1 root root 17654 Aug 6 12:57 StatusCheck.cpp
-rw-r--r-- 1 root root 1607 Aug 6 12:57 StatusCheck.h
-rw-r--r-- 1 root root 71508 Aug 6 17:26 StatusCheck.o
[email protected] ~/HROS1-Framework/Linux/project/ps3_demo \$

darkback2
09-06-2015, 05:39 PM
Ok...thank you all for the help. I got logged in as root, I had to change a few things in order to do that, but then I was able to edit the files no problem using winSCP. Cool little program BTW.

After restarting it still seamed to hang up, but not nearly as fast. I guess this is progress.

DB

KurtEck
09-06-2015, 06:18 PM
If it were me, I would probably change the ownership of all of the files to pi (or other user if you created something other than pi).
Something like:

cd ~
chown -R pi:pi HROS1-Framework

r3n33
09-06-2015, 06:55 PM
After restarting it still seamed to hang up, but not nearly as fast. I guess this is progress.

Darn! Sorry that wasn't the fix you are most in need of at the moment. If I were you I'd check my wiring at this point. Also I'd ensure there aren't any other processes running on my Pi consuming needed resources ( with a program like top or htop ).

Edit: Also you mentioned after restarting. Does that mean you edited the main.cpp file and restarted without running the make command?

darkback2
09-06-2015, 08:30 PM
should I run the sudo make all command? Duh...guess so.

darkback2
09-06-2015, 08:43 PM
OK...so sudo make all made it so that ps3_demo stopped working...

I commented out the line and it works again, so I think I probably inserted it wrong. below is what I commented out to get things working again. :-(

{
Action::GetInstance()->Start(15);
while(Action::GetInstance()->IsRunning()) usleep(8*1000);
}
while(1)
{
// usleep( 10000 );
StatusCheck::Check(cm730);
if(StatusCheck::m_is_started == 0)
continue;
}
return 0;
}
int GetCurrentPosition(CM730 &cm730)

darkback2
09-06-2015, 10:44 PM
In other news...Inflatable suit inflating

KurtEck
09-08-2015, 11:06 AM
OK...so sudo make all made it so that ps3_demo stopped working...

I commented out the line and it works again, so I think I probably inserted it wrong. below is what I commented out to get things working again. :-(

{
Action::GetInstance()->Start(15);
while(Action::GetInstance()->IsRunning()) usleep(8*1000);
}
while(1)
{
// usleep( 10000 );
StatusCheck::Check(cm730);
if(StatusCheck::m_is_started == 0)
continue;
}
return 0;
}
int GetCurrentPosition(CM730 &cm730)

Any updates on this? It looked like you inserted it at the right spot, which should not stop stuff from working. As I mentioned I added the delay in the StatusCheck::Check code. But I also updated the PS3 code completely... You might reduce the delay time from 10000 to maybe 1000, it will still drop the CPU usage down to almost nothing.

I keep meaning to take another pass through this code and clean up some stuff. For example, there is no purpose to the code:

if(StatusCheck::m_is_started == 0)
continue;

The continue will take you to the end of the while statement which is where it is at anyway...

Kurt

darkback2
09-08-2015, 04:57 PM
Thanks for the help Kurt. I will delete the commenting out part and change it to 1000.

DB

darkback2
09-09-2015, 07:41 PM
So I finally got to edit the code again removing the comment lines and got this warning...

It seemed to work, but it is still freezing after walking for a little bit...When it freezes is random and it needs to be reset in order to work again.

main.cpp: In function ‘int main(int, char**)’:
main.cpp:50:7: warning: unused variable ‘trackerSel’ [-Wunused-variable]
g++ StatusCheck.o main.o ../../lib/darwin.a -o demo -g -lpthread -ljpeg -lrt -lbluetooth
chmod 755 demo

darkback2
09-09-2015, 10:33 PM
Now I am wondering...the lock up thing only seems to happen when the robot is walking.

Could this be an issue with the IK?

Does this suggest that it is really a bad wire somewhere?

Unfortunately walking around with a puffy suit on makes looking for things like servos turning on or off really difficult. On the flip, the legs seem to stay nice and cool with those fans blowing on them. :-)

DB

KurtEck
09-10-2015, 09:26 AM
My guess is it could be lots of things.

Could be electrical: like a brownout of one of the components or a bad connection...

Could be firmware: Some issue with the Cm... controller?

Or could be code issue with the code running on RPI: For example it could be spinning in a loop waiting for some event that does not happen or already did happen...

Sounds like time to start debugging. I would probably try a few different approaches, including:

a) Look over the code and sprinkle some output printf statements at key locations, to get an idea if the code is getting to some location to try to localize down where it is hanging and potentially what values it is seeing...

b) Cheat: I have WinGDB installed on my PC, which allows me to do some source level debugging of the stuff running on the RPI2. If it hangs, you can tell the window to break into all threads and see where the code actually is. I was also thinking that when I try running this code base using an Edison instead of RPI, I may setup an Eclipse workspace for all of the HROS1 code and the Eclipse setup also is setup to do remote debugging.

c) Check out some of the other HROS1 users and see if they have their own forks of the code that may have some fixes in it. However you may need to distinguish those changes made are they actual fixes for the code base or are they fixes to work specifically with the Beta 1 HR-OS1.

Also sounds like a potential for a group debug session, like with Hangout.

darkback2
09-13-2015, 10:25 AM
So...To that end, Me...

I have a strange background for a high school robotics teacher. While I have always had an interest in electronics and computers, I didn't really get into this stuff until graduate school. In college I was a music major. I concentrated in Electronic and post modern music. I thought I was going to be a recording engineer or composer. Then I went to Calarts where I majored in composition with new media. Basically computer music and interactive design. That was when I really got my start in robotics.

Over the past five years I have been working on my "flagship" robot Hikari. She is really a better example of my capabilities.

My struggle with the HROS-1 in part stems from the fact that I am really jumping into this project near its end. I don't know enough to know where to start looking to figure out what I am looking at.

I've decided to start by annotating the code. The question is, where would make the most sense as a good starting point. Looking at the PS3_demo Main program it looks like a lot of calls to other programs. Is there a diagram showing the overarching software layout?

DB

KurtEck
09-13-2015, 11:52 AM
Sounds like a very interesting path!

I have not seen anything here that fully documents the code. I think there are bits and pieces out there. For example a lot (most? ) comes from Robotis and there is probably some documentation on it up somewhere on their sites. For me I mostly figure out by reviewing the code.

As to how/where to annotate the code.

Could start off with some simple thing at the start of StatusCheck::Check. Could be a simple printf statement, or if you are setup with something like a logic analyzer, could be something like toggling an one of the external IO pins. So if then run your program and it hangs walking, are you still seeing events? If not, you know it may be hung in some inner loop. If yes, well...

Note: My version of these files have changed a reasonable amount as I replaced the PS3 code with my own and also updated the indention...

I would probably go into statuscheck file where it says PS3 RC Control Code and uncomment some of the printfs here to again see the data, especially when it then hangs.

Depending on what you find, I would then maybe start instrumenting the MotionManager including walking... Have not gone done much in here yet, so not sure where.

Some other things I do include: Run a 2nd terminal window and run something like htop in it. (May have apt-get install it). This shows you how busy each of the processor threads are. So if something hangs in a hard loop, it should show a thread completely utilizing a processor core.

Kurt