it’s the same guide, I don’t see anything about installing pymavlink with pip2.
It recommended the first option using Cygwin, so I should have probably linked that instead:
http://ardupilot.org/dev/docs/building-setup-windows-cygwin.html#building-setup-windows-cygwin
The pip2 commands are the very last section:
As I was looking today at how to interface with the L298N driver, I realized that the Arduino code they implement is not a similar implementation to that of the ArduSub code (or is it?). Our motor is 2 cables (brushed?) while the ESC provided by BlueRobotics is brushless and features 3 cables. How do we go about this?
I know Willian said all we’d need is a brushed ESC, is this true?
Or do we need the L298N driver, and if we do need it, how should we be communicating to it from the pixhawk? Are changes to the code required or is it just a matter of making the right connections from Pixhawk to the L298N driver?
I have also successfully installed CentOS and am currently following the guide. Which one of these should I be grabbing?
Yes, you need a brushed esc. The L298N will need firmware modifications, and more trouble than it’s worth.
You should use gcc 4.9 for the ArduSub-stable version (recommended), gcc6 for master/development working (I don’t recommend).
Ok thanks!
Looking at the following ESC, which seems to have for/rev features, but I am uncertain of the voltage rating, and some of these ESC’s have switches, probably to switch between forward/reverse, although we are looking for a solution that doesn’t require manual switching:
Edit: (12V but has a switch) https://www.amazon.com/TOOGOO-6-12V-Brushed-Speed-Controller/dp/B0734KFGTW/ref=cm_cr_arp_d_product_top?ie=UTF8
In other news,
We’re progressing pretty well; due to present the product on the 25th and should be able to meet the deadline. No issues when we tried to get a single thruster to run, hopefully that translates to the 4 thruster build. Our thruster positioning isn’t ideal for yaw, although our movements are mainly x-y for the most part so the team doesn’t seem too worried about that. Ideally, a configuration like the Vectored ROV would’ve been great, but due to the length of two of the thruster cables given to us, we are limited to where we can place two of the thrusters (have to be close to the control box).
Our custom configuration is then as follows (using same numbering system as Vectored ROV):
roll pitch yaw throt for lat
add_motor_raw_6dof(AP_MOTORS_MOT_1, 0, 0, 1.0f, 0, -1.0f, 1.0f, 1);
add_motor_raw_6dof(AP_MOTORS_MOT_2, 0, 0, -1.0f, 0, -1.0f, -1.0f, 2);
add_motor_raw_6dof(AP_MOTORS_MOT_3, 0, 0, -1.0f, 0, 1.0f, 1.0f, 3);
add_motor_raw_6dof(AP_MOTORS_MOT_4, 0, 0, 1.0f, 0, 1.0f, -1.0f, 4);
I’m unable to run git checkout ArduSub-stable (or at least don’t know how to force it because I already made copies of the files I changed).
Edit: I think I figured out how to force the checkout, also found how to commit, etc.
I also tried the following waf commands but got an error on the third one:
1) ./waf configure --board px4-v2
Try ./waf build sub after that told me to simply do 2) ./waf configure, so I did that (image below)
3) Then I ran ./waf build sub and got the error (image below)
Edit: After getting the git commands to all run, I tried the 3 ./waf commands again, but this time ./waf configure --board px4-v2 cannot find ‘arm-none-eabi-ar’:
You need to install the arm compiler according to the instructions. Remember to export the PATH variable.
What sort of motors are you using? How will go you ascend/descend?
I think that’s what I did on the window to the right?
export PATH=$PATH:Downloads/gcc-arm-none-eabi-4_9-2015q3/bin
ardupilot is in the /home/dan directory while the gcc-arm cross-compiler is in a separate directory (/home/dan/Downloads), should they be in the same directory?
These are the motors: https://www.vexrobotics.com/217-2000.html#Other_Info
I didn’t understand your second question but the plan is that when we press custom1, both motors will spin forward (it might be that the direction to go down is actually reverse but we will find out later) and lower the belt. custom2 will raise the belt.
since the platform will be conducting inspections in the reactor pool, the operator is to be at a remote location with the companion computer + xbox controller, so not expecting this person to have to go in and manually switch the servo to reverse.
So after a bit of cd into some places I found that I was editing the /home and /home/dan .bashrc instead of the one in /root (~), my latest error is now this:
I followed JotMyNotes: Updating CMake from 2.8.11 to 3.6.2 or Newer Version on CentOS Linux after trying ‘yum install cmake’ which resulted in a version that was not recent enough apparently…
my root can do cmake --version now but not my normal user
so after all this I tried the ./waf again and…
apparently cd ~ takes you to different places depending on whether you’re root or normal user so… this is all really fun lol, even after editing ~/.bashrc as a normal user the ./waf command still can’t find arm-none-eabi-ar
Edit: wait, i’m a genius, I went back into ~/.bashrc and made the path /home/dan/Downloads instead and that seemed to fix it:
Does this look good?
Edit: guess not
And with root
Edit: sorry for so many edits, this is all new to me and right when I think all hope is lost, google saves the day. Anyway, I figured it was a permission issue with the normal user, so i tried “./waf build sub” but using sudo this time, now it’s a mavlink error that I can’t really figure out from the error message:
Edit: I was focusing on the red text, but the traceback + google actually led me to “apt install python python-pip python-future”. So after that I went ahead and tried the ./waf commands again:
So finally I think I have no idea what to do to fix this. Apparently it can’t find arm-none-eabi-gcc (even though the configure said it found it?)
We’re currently wiring up 4 thrusters; half the team is on spring break but my spring break will consist of soldering and Linux troubleshooting 
Any idea how I can get around this latest error on the build attempt?
Edit: maybe I misunderstood what the switch on most of the esc’s that I found was for, but looking at a YouTube video, it appears that the switch is not actually for changing between forward and reverse, but to switch between different modes such as for/rev or for/rev/brk ,etc… so we might be selecting one to buy soon.
So I tried to build as root, and suddenly it was able to find the compiler, but not ‘genromfs’. There was a random forum post somewhere suggesting to download "genromfs-0.5.2-7el6.lux.1.x86_64.rpm’ which I did, and tried to build again with what appears to be good results so far. There were some python libraries still missing but the error itself told me what commands to run so I was able to fix that too!
Latest failure:
Doesn’t seem to be much that I can go by? A task in AP_Motors failed, then I see that ‘AP_Motors6DOF.cpp’ is mentioned, which happens to be one of the files we modified for our custom configuration so I am checking for syntax errors.
Edit: maybe I should un-comment this break, lol 
Ok!
So, after removing the break comment, I was getting an error in joystick.cpp, and since I couldn’t find any syntax errors, I grabbed a completely new, stable version of the code without any of the custom implementations and tried to build it. It worked, with a cmake message at the end, not sure if it’s significant:
So now, I am going to add the custom motor configuration and try to build it again. Then I will re-do the joystick.cpp implementation and build again. If it goes wrong in either one, it will be a problem with the code rather than something else, correct? I’ll just edit in my findings to this post.
Steps I take:
- change code
- git add & commit
- ./waf clean
- ./waf configure --board px4-v2
- ./waf build sub
Edit 1: Build successful with custom motor configuration. Trying joystick.cpp now.
Edit 2: Yep, something is wrong with the joystick.cpp code we cleared earlier:
Oh, wait, there are error messages indicating the problem! I did not even notice this:
I know what to do now to fix this, I think. Will be back with an edit on how things go.
1 Like
Ok so this is where I think we’re at right now:
1) New fixed code for joystick.cpp compiles/builds fine, all that’s left is to test it after we upload it:
This is the build result:
2) I just ordered two of the following ESC yesterday, due to arrive Monday. Do you think these will work for our application? https://www.amazon.com/gp/product/B01LZHBJ85/ref=ppx_yo_dt_b_asin_title_o00_s00?ie=UTF8&psc=1
As a reminder, these are our motors: CIM Motor - VEX Robotics
3) I have no idea if my virtualbox machine will communicate properly with the pixhawk, but I plan to try to do the upload remotely:
4) I think that’ll be it in terms of software/code? We’ll just be finishing up wiring/soldering, cable management, make the platform look presentable and more mechanical stuff for the platform and arm supports. Hopefully we can test the servo functions on Tuesday or Wednesday. I will try to flash the pixhawk and test all 4 thrusters today if we make it that far with the soldering.
Here are some images:
Today we:
- Successfully flashed the pixhawk locally via direct USB connection. Uploading remotely was not working because apparently it didn’t have pyserial. I installed that and then I couldn’t get it to find the directory, so I just went with local instead.
I think as long as it works locally, we don’t need to worry about a remote upload.
- We tested 3 thrusters simultanesouly and are confident that it will work for 4 as well.
Final to-do’s:
- Will try changing the FRAME_CONFIG parameter next week.
- Test the servo functions w/ the aforementioned ESC’s on Tuesday or Wednesday
Fantastic @adaniel1, I’m happy to see that you’ve worked it out. Let us know if you have any more questions.
Can you share any information about what this thing is supposed to do?
We’re about ready to mount the thrusters, but once again, the whole small cable issue really limits the position of two of our thrusters at the bottom of the images (bottom left is wired to test the short cable range, top two thrusters feature much longer cables so we have more options there.)
So I would like to get your opinion on which configuration would work best as it turns out the configuration in earlier posts in reality was not able to achieve the ideal 45 degree angles.
Goal:
- Primarily x-y movement, although some yaw would be great if possible.
Group Votes:
- 2 for A or E and 4 for F.
- G was a last minute concept similar to the original; a good contender as well based on group opinions.
- Configuration Settings for F:
Options:
A)
B)
C)
D)
E)
F)
G)
H) (This is the original setup that we’re not sure of due to the angles…)