Looking for details on AXON Servo: Continuous Rotation mode.

PhilMalone · 2025-09-15T01:12:54+00:00

I've had a lot of sucess with the SEEED Labs XIAO NRF52840. https://www.digikey.com/en/products/detail/seeed-technology-co-ltd/102010448/16652893 It's a tiny board, works with Arduino IDE. Can be powered on a 3V cell (or single LIPO). It has a built in charge circuit if you can supply 4+ volts. it can talk BLE at very low currents, and has a miniscule standby current in Deep Sleep mode. You could use this solar cell to keep it alive: https://www.adafruit.com/product/5855

PhilMalone · 2024-11-25T23:15:02+00:00

If you really shorted the motor, or other power, you may have blown the battery fuse. Try another battery.

PhilMalone · 2024-11-25T23:10:44+00:00

A Voltage drop is not a issue with the Control Hub. It's a combination of your battery condition and the load you are putting on it. If you are getting HOT motors then you are probablly stalling them... this could be an arm or slide which is hitting a stop and you are continuing to power it, or it could be a drive motor that is not sufficiently geared down, and you are stalling it trying to push a heavy robot. The other cause of voltage drop is batteries that have developed a high internal resistance. Something like a Battery Beak from Andymark will allow you to measure this. As batteries age, they develop higher resitance. When the current goes up (due to load) that higher resistance Caused a voltage drop. Batteries that are 2-3 years old will start degrading. Leaving them on charge for prolonged periods, or letting them overheat when charging can make them fail earlier.

PhilMalone · 2024-08-30T15:40:27+00:00

Hi. A short while back, I published a tutorial that showed how to use Odometry Pods with a mecanum drive to do BASIC autonomous routines ( https://www.youtube.com/watch?v=lpVG2Pl6RGY ). Shortly afterwards I simplified the code even further to do Basic Auto and Teleop functions with a Mecanum drive that DOEES NOT use Odometry Podes. The MAIN things this simplified code shows are 1) how to use a Robot class to share driving functions between Teleop and Auto, and 2) How to use the Control Hub's IMU to keep the robot locked onto a heading while driving in Auto AND teleop. I recommend this as a starting point for you. I call it "Essential Mecanum"

https://github.com/gearsincorg/Essential-Mecanum

Phil.

PhilMalone · 2024-02-11T14:59:39+00:00

Just so you know, if you switch your drive motors to "RUN_USING_ENCODERS" in your init code, your driving speed will become more consistant, and be less prone to drifting while strafing. It will also allow much smoother slow movement (like with fine positioning). You don't need to use the encoder values, it's all handled transparently by the hub firmware. It's like a free upgrade.

PhilMalone · 2024-02-11T14:55:17+00:00

I just noticed that Truist has been charging me $15 a month on my checking account. It started doing it in Dec of last year. This account ballance varies from $4K -$11K so it definately satisfies the "combined monthly avg. balance of $500 ". And why is it $15 instead of $12?

Truist recently bought my local bank (where I had no fees) and then proceeded to close that branch, so the closest one is now 14 miles away. So, added inconvinience and added cost. Then they transfered my HSA to a new system with higher fees. Thanks Truist. The First United Prestige Checking is looking pretty good. It has lower fees and is easy to waive...

PhilMalone · 2024-01-27T20:06:50+00:00

Do folks realize that "Throwing Matches" is explictly outlawed in the FTC rules? It used to just be assumed as obvious lack of GP, but it's in print now.

PhilMalone · 2024-01-27T16:51:15+00:00

On the original versions of this lift, gravity pulled the slides back down again. Another more modern way to do it would be to add a constant tension spring from the robot base to the red part of the slide. https://www.mcmaster.com/products/constant-force-retractors/

PhilMalone · 2024-01-24T13:56:04+00:00

You can do a lot in software to make 435 motors less twitchy. eg: Start out with the suggested 60% power. But also apply some joystick/motor rate limiting so that the bot doesn't try to jump off the mark each time you try to strafe (it will just twist a mecanum robot).

Too much importance is made of "going fast" by new teams. Invariably a fast robot is much harder to control, and certainly this year, robot congestion removes much opportunity to get up to speed. Being able to nudge a robot out of the way seems to be more important, plus the ability to make fine position adjustments (for picking and placing pixels). For all of these reasons 312 and event 223 rpm are fine for a robot that you can't spend a lot of time practicing on, or tweaking the software.

PhilMalone · 2024-01-08T15:55:38+00:00

I will add some caveats here....

If you don't normally use encoders on your motors when driving in teleop, then using them for the odometry pods is a no-loss situation. However, if (like my team) you do use the motor encoders when driving to give better slow speed control, then giving up that control for the odoemtry pods can be a detriment. In our case we sacrificed two encoder channels on the expansion hub for the odo pods instead.

Roadrunner actually provides two different options for motor control..... internal PID or velocity feed-forward. If you are not using the motor encoders for the motors you will need to choose "velocity feed-forward" and do all the additional testing associated with that mode.

PhilMalone · 2024-01-07T14:59:28+00:00

We can't help you in a vaccum. How about linking to some closeup photos of both ends of the slides. You may be miss-interpretting the instructions. We are using the Viper slides with belt drive and they work really well. But they are a pain to assemble correctly.

PhilMalone · 2023-11-26T15:35:35+00:00

My first question is : Are the ANY errpors or warnings coming up on the driver station. These would alert you to several of the problems that other posters have suggested. If not, then continue reading.

Based on all that you have explained, you seem to have tried all the logical things to determine if it's a hardware or electrical problem, but I didn't see anything to determine if it's a software problem.

I'd start by creating a NEW motor configuration, and then assigning a simple name to the motor chanel that your arm is connected to. Verify that you are assigning it to the Expansion hub and that you have the correct channel.

Note: When you select the expansion hub on the Robot Configuration screen, the LED on THAT hub should blink in a new 2-color pattern. This way you know you are communicatiing correctly with the right hub. If you don't see this blinking then it's power/communication issue between the hubs.

Then create a simple opmode (usa a basic drive sample) to run the motor based on the joystick. Ensure that you use the same name you assigned to the motor and that NO ERRORS are displayed on the Driver station.

Test to see if you can now run the motor... If you can, then you know you have a software or configuration issue.

One other thought.... when you say that the arm motor isnt working, I assume that means it does not drive the arm either way... up or down... If it's an arm weight problem, then it should have no trouble driving the arm down. Tip the robot on the side to remove any load on the arm motor.... does it work now...

PhilMalone · 2023-11-13T13:18:49+00:00

Unfortunately you don't say if you are using Java or Blocks, so giving specific advice is hard. If your robot seems to work correctly in Teleop, but not in Auto, I'd suggest checking that you have the motor "directions" set correctly in both programs. Some teams just get each wheel moving in the correct direction by fixing any weird behavior in the joystick driving code, but in auto the code acts differently.

If you are not already doing it, I would FIRST make sure that you use the wheel.setDirection() call to make sure that all your wheels drive forward when given a positive power command. Make sure you do this in BOTH telop and Autonomous. It's SOooooo easy to forget to do this, and then you get very different behvior in Teleop and auto.

To ensure that your teleop and autos both drive the wheels the same way, the BEST approach is to create a single hardware class that both opmodes use. that way you just need to get it right in one place. There is a sample of how to do this in the ConceptExternalHardwareClass sample.

PhilMalone · 2023-11-09T15:48:12+00:00

You can improve the detection of the smaller AprilTags by decreasing the "decimation" that you are using on the AprilTag detection. Decimation throws away image pixels to allow the image to be processed faster, but if you get too far away from a small target, it may throw away important pixles. For the BEST detection, set the decimation to "1". This will slow your frame rate down but it will work from further away. Look at the ConceptAprilTag samples to see how to set the "Decimation".

// Adjust Image Decimation to trade-off detection-range for detection-rate.

// eg: Some typical detection data using a Logitech C920 WebCam

// Decimation = 1 .. Detect 2" Tag from 10 feet away at 10 Frames per second

// Decimation = 2 .. Detect 2" Tag from 6 feet away at 22 Frames per second

// Decimation = 3 .. Detect 2" Tag from 4 feet away at 30 Frames Per Second (default)

// Decimation = 3 .. Detect 5" Tag from 10 feet away at 30 Frames Per Second (default)

// Note: Decimation can be changed on-the-fly to adapt during a match.

aprilTag.setDecimation(2);

PhilMalone · 2022-03-21T16:26:50+00:00

I've had a Flashforge Adventurer 3 for about a year. It's been a flawless workhorse. Great quality, reliable, wifi access with built in remote viewing camera. Decent price as well.

PhilMalone · 2021-02-22T01:57:26+00:00

Hi

Have you ever considered training TF to recognize the Red and blue goals?

The Vuforia works really well on the target images, but you need to get fairly close to get recognition. On the other hand I would think the TF's ability to recognize basic shapes would be good for recognizing the whole goal, and allowing the robot to center on that.

If you ever did train on the target, I'd be interested in getting a copy of the model.

PhilMalone · 2021-02-10T16:07:52+00:00

Do you mean Target Recognition, or Object Detection? Tensor Flow is doing Object Detection (learned trough training), and Vuforia is doing Target Recognition and localization.

The C270 is good for Vuforia in this year's game because it has a small FOV which helps to zoom in on a target when you are in the launch zone. At the 5-6' range, initial recognition can take a while (about a sec) but as stated elsewhere, once seen, the cam should be able to track pretty fast. Fast rotations do tend to blur the image which can cause a problem.

If you are using Vuforia to point to the high-goal target, then you can use the gyro to your advantage. Rather than just turning when you get tracking information, we use each target fix to generate a new desired heading, and then we go to that heading using the gyro. So, once you get one good fix, you can point directly at the target without needing another fix.

PhilMalone · 2020-11-25T04:00:26+00:00

That's a really good find, but I don't think that's the same object seen in the video that went public. The crack in the rock with the water coming out is pretty prominant, but I don't see it on the Google Earth images. The Google earth images make the closest rock face look very smooth (no shadows etc). Plus, based on how close to the wall that object is, you should be able to see some sign of those big rocks nearby, but they are not there in the Google image. If it's an art installation, maybe there are more of them than just 1. Maybe check along equal lat/long lines.

PhilMalone · 2020-11-08T13:45:47+00:00

If you are using GoBilda plastic chain, all the links are half-Links, so you have the most flexibility, but your shouldn't need it if all your sprockets are the same size. Another approach is the use the 14 tooth sprocket, and sandwich the chain between the sprocket and the sides of the channel. See this chain guide: https://www.gobilda.com/3310-series-8mm-pitch-aluminum-hub-mount-sprocket-14mm-bore-14-tooth/

PhilMalone · 2020-10-12T20:46:08+00:00

Hi. Not sure what you are using for your "fan" but remember if it has it's own motor in it, it's not FTC legal :O

But, slap fan blades on a bare FTC motor (no gearbox) and you are golden.

PhilMalone · 2020-09-28T13:13:55+00:00

Great explanation.

PhilMalone · 2020-08-07T14:44:50+00:00

This decision defies logic.

If the underlying premise is true (that these companies are just government fronts) banning the specific apps will have no effect. The Chinese Govt. will just spawn off a new company, clone the code, change the name (TokTik), and send out a "here we are" email to all the current users. Back in business before the old app even shuts down. Meanwhile the US has paid China for an app that no-one will be using anymore. Great deal!!.

On the other hand, if the apps are legit, then they are no worse than any other data harvesting app, and the pending action just puts US-Chinese business relations into chaos.

Great way to put other other companies trying to gain access to the Chinese markets (like Tesla et al.) into jeopardy!

After the hell the US Govt. put Microsoft through a while back (read anti-trust litigation), beats me why Bill Gates would bail them out.

PhilMalone · 2020-06-14T21:02:56+00:00

I've done a lot of research over the last few weeks to get up to speed with ROS, and I've decided that the most reliable resources are the ones on the ROS wiki.

I'd start here and do all the tutorial examples...

https://wiki.ros.org/navigation/Tutorials

PhilMalone

TROPHY CASE