Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Drive Car with Mission Planner #13

Open
ebgoldstein opened this issue Oct 6, 2021 · 7 comments
Open

Drive Car with Mission Planner #13

ebgoldstein opened this issue Oct 6, 2021 · 7 comments
Assignees
Labels

Comments

@ebgoldstein
Copy link
Contributor

Drive the car with mission planner.

@ebgoldstein
Copy link
Contributor Author

the current problem is a failure of some Pre-Arm Safety checks.

@StevenTagner
Copy link
Contributor

In order to drive the rover, Mission Planner needs to understand several things about the autopilot software and vehicle type we are using. The mandatory checks and how they normally happen with my tests are as follows:

  • Frame Type
    This is page is used to load firmware from Mission Planner to the Vehicle about what type/model vehicle is being used. Since we are using Navio2 which has the firmware loaded onto it this page is not needed.

  • Accel Calibration
    This comprises the process of leveling the autopilot and calibrating the accelerometer by rotating the vehicle on its three axes. This is normally passed without incident.

  • Compass
    This is the process where the car's compass is calibrated by rotating the car around. This is normally passed without incident.

  • Radio Calibration
    This is the process of letting Mission Planner know the effective bounds of the vehicle's motors and servos using the RC Transmitter. To do this you need to have the RC Transmitter connected to the Navio via the RC Receiver, then the Navio connected to the ground control station running Mission Planner via telemetry. To calibrate, start the test and rotate the sticks and switches on the RC Transmitter to show the proper changes on Mission Planner. Any discrepancies (i.e. If a throttle appears to be in reverse) can be altered by clicking the respective boxes and settings in Mission Planner. In my tests, this has failed as only one of the channels is registered (either the ESC or servo depending on the Servo Rail configuration).
    To fix this, I intend to look more closely at how the inputs are received (in the Navios' configuration files) and failing that, looking into what the automatic inputs are registered as from the Servo Rail.

  • Servo Output
    This is less of a check and more of a way to monitor and fine-tune your controls. Since you will not be manually controlling the rover, it is important to adjust the trim and order of the servos and motors so the car does not veer off course frequently. To test your motors, go to >>Optional Hardware >>Motor Test and run each in succession and watch for any dead zones or varying relative speeds (if one wheel spins faster than the other at the same throttle percentage). A video that covers this in detail that helped me out is this one by Randy Mackay. After noting any dead zones or variations in speeds make sure to adjust your trim values accordingly then repeat the process until you are satisfied with the level of precision.

  • ESC Calibration
    This is the process of finding the maximum and minimum of the ESC (Electronic Speed Controller) and communicating that information to Mission Planner. It goes as follows:
    Turn on your RC Transmitter and set the throttle to maximum, then power up the rover. The autopilot’s red, blue and yellow LEDs will light up in a cyclical pattern. This means it’s ready to go into ESC calibration mode the next time you plug it in. With the transmitter throttle stick still high, disconnect and reconnect the battery. The autopilot is now in ESC calibration mode, the ESCs should emit a tone, the number of beeps indicating your battery’s cell count (i.e. 3 for 3S, 4 for 4S), and then an additional two beeps to indicate that the maximum throttle has been captured. Pull the transmitter’s throttle stick down to its minimum position, then the ESCs should then emit a long tone indicating that the minimum throttle has been captured and the calibration is complete. If the long tone was heard, the ESCs are “live” now and if you raise the throttle a bit they should spin. Test that the motors spin by raising the throttle a bit and then lowering it again. Set the throttle to minimum and disconnect the battery to exit ESC-calibration mode. Here is an article and video going over the process.
    I have had some random problems with this that I suspect are related to the errors I have received in Radio Calibration so I will test them in tandem and update them accordingly. If they are not related to each other, I plan to test the ESC by running it without the Navio and if it works, checking the Servo Rail configuration of the ESCs and its configuration files for any erroneous data.

  • Flight Modes
    This will allow multiple modes to be selected to swap through while the rover is running using the transmitter switches. For example, on our transmitter we have a switch with three states so we can assign one to be "Auto" to run missions, one to be "Manual" for manual control, and one to be "RTL" (Return To Launch). I have not experimented with this much as it should be tested while the rover is running missions and we are not at that point right now. I have been leaving them at their default values (in my case "Manual", but this may change machine to machine) until we get to a point where autopilot is working.

  • Failsafe
    Failsafes are certain thresholds that, when passed, force the rover to perform a pre-configured action. These actions can be specific to what we are doing and the failsafe that was triggered, so we can make a low voltage failsafe save the data and shut down while a GPS failsafe pauses the mission until a GPS lock has been re-established. Much like the Flight Modes, this is not really testable until we are driving missions but you can set values that you know you will need such as low battery thresholds. I have been leaving these at default with no known errors.

  • HW ID
    This stands for HardWare ID and can is a place to monitor how Mission Planner is registering the different parts of your rover. You cannot modify anything here but it can be useful for troubleshooting.

  • ADSB
    This may show up as required on your Mission Planner but to the extent of my knowledge is not. This stands for Automatic Dependent Surveillance-Broadcast and is used to enable aircraft to be accurately tracked by air traffic controllers and other pilots without the need for radar. Since we are driving a rover if you run into this ignore it.

That was a short summary of my experiences with all the different mandatory pre-arm checks. I will add screenshots and information as I continue to experiment with them.

@ebgoldstein
Copy link
Contributor Author

ok cool. so if i am reading correctly the big issue is the Radio Calibration test?

@StevenTagner
Copy link
Contributor

Yes, the main problem is with the Radio Calibration with a secondary problem being the ESC Calibration that is hopefully caused by the same thing as the Radio Calibration so they will both be fixed at the same time

@StevenTagner
Copy link
Contributor

Yesterday I wrote out what was needed to start driving autonomously and started working on them.
I knew that the biggest issues are the Radio Calibration and the ESC Calibration. In order to test the Radio Calibration, I wanted to make sure that:

  1. The RC Transmitter/Reciver was working properly (the servos and ESC are controllable)
    To do this, I stripped the RC Car to the base functionality (RC Transmitter sends to RC Receiver which sends to the ESC and the Servos) and controlled it with the RC Transmitter/Receiver (I thought this would take about 10-15 minutes but it took about 30 minuets to fully complete because I had to charge the battery so overall I think my prediction was accurate).

  2. Mission Planner registers all RC Transmitter channels
    This is making sure that Mission Planner can register all the required inputs from the RC Controller through the Navio. When I preformed this yesterday, I was registering the two sticks with no other switches or knobs being registered. Since this was being done at the same time as the next issue, it didn't take up any extra time. To find a way to get the other channels registered I think that will be closley related to the next point so my estimate will be lumped with it.

  3. The car is controllable through the Navio connected to Mission Planner.
    The final goal for Radio Calibration would be to control the car through the Navio that is communicating with both the RC Transmitter and Mission Planner. I did not get to test this much yesterday and only got to try a few things. I was able to control the ESC as described but without the servos working. I tested moving the servo pin up and down the Rail on the Navio without success. This process took about a half hour to test. I think this part will take a bit longer to test I will be looking though some config files on the Navio in tandam with testing pins on the Navios' Rail, so I estimate about 3 more hours. This 3 hour estimate includes getting the other channels registered properly from the second point.

This was primarily testing the Radio Calibration, my estimate for getting the whole rover to drive autonomusly is about 7 more hours total.

Time Breakdown:

  • 1 hour has been spent on Radio Calibration.
  • 3 more hours planned to work on Radio Calibration.
  • 2 hours planned to work on ESC Calibration and related bugs. (this is a smaller estimate as I think that this issue is related to the Radio Calibration Issue)
  • 1 hour for misc/non forseen issues.

@StevenTagner
Copy link
Contributor

Today while I was working on the radio calibration I ran into another problem that may be more closely related to the heart of our issues. As soon as I would turn the servo using the RC Controler the wheels would turn the slightest bit and then stop for a length of time. I attached the rover to a monitor to see what was going on and when I would turn the wheels the rover would boot up as if it had been turned on which was causing the delay. It looks like this is because the servo or new RC Receiver pulls too much power and shuts down the Navio, which then receives the proper amount of voltage which causes it to turn on and boot normally. This may be because the Navio takes around 5 Volts to run, the new RC Receiver takes 5.5(-/+ 1.5) Volts, and the battery I am using is 11.1V. I didn't have this problem earlier as the RC Receiver was not used as much since we didn't have the transmitter. I also didn't notice this in my previous session as there is no visual indication that this is occurring, the wheels simply stop turning and the lights continue to blink. I don't have a way to see the voltage requirements on this servo at the lab right now but if I see anything on the paperwork I have I'll update here.
This may be closer to the reason we have had the other errors, I think we should plan a date/time next week to meet up in person at the lab and test this with your RC Cars battery (if memory serves it was a larger battery) to test this and get the final touches done with your car since your is very close to the originals state.
Other than this new lead I did make some progress in the radio calibration by improving the placement of the wires on the servo rail which I think will help.

@StevenTagner
Copy link
Contributor

I made some progress with the rover relating to the above comment, I stopped the shutdowns by providing power through the 11.1 V Battery to the power module (that lead to the ESC and Navio) along with a 5 V USB battery pack powering the Pi. This seemed to be the best way to power everything without having the system shut down when the ESC/Servo pulls power.
Once that issue was out of the way I was able to make strides in how Mission Planner communicates with the Navio and alter those connections. On the page Setup > Servo Output you can see a table that looks like this one:

image

This is my current setup, the # tab represents Navio channels so channel 1 on the Navio takes input from channel 1 on the RC Remote (RCIN1, the left/right movement on the right stick), and channel 3 on the Navio takes input from channel 3 on the RC Remote (RCIN3, the up/down movement on the left stick). These channel values can be changed by moving the wiring on the servo rail of the Navio and in the remote's settings on the RC Remote (should be detailed in your user manual). I also worked a bit on the min/trim/max but put them back to defaults until I get them where I want them. I worked on this for about an hour after my class tonight which brings me to about 3.5 out of my 7 predicted hours used on starting autonomous missions.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants